SPF (Sender Policy Framework) is an email authentication standard, defined in RFC 7208, that lets a domain owner specify which IP addresses and servers are authorized to send mail on its behalf. The list lives as a TXT record in the domain's DNS. When a receiving mail server gets an inbound message, it checks the sender's IP against the SPF record; if the IP is not listed, the message fails SPF and is typically treated as suspicious. SPF is one of the three pillars of modern email authentication, alongside DKIM and DMARC.
How is an SPF record structured?
An SPF record is a TXT record at the root of the domain (e.g., yourdomain.com). It starts with v=spf1 and lists authorized senders using mechanisms like include: (delegate to another domain's SPF, e.g., include:_spf.google.com), ip4: (specific IP), a: (the domain's A record), and mx: (the domain's MX hosts). It ends with a qualifier: ~all (soft fail, mark suspicious) or -all (hard fail, reject). Example: v=spf1 include:_spf.google.com include:sendgrid.net ~all.
The SPF record has two important limits. First, it cannot exceed 10 DNS lookups when evaluated. If you stack too many include: mechanisms, the record fails with permerror. Second, only one SPF record per domain; multiple records are a misconfiguration. SPF flattening tools rewrite long chains into a single record that stays under the 10-lookup ceiling.
What are the common SPF mistakes?
Three patterns trip up most teams. First, exceeding the 10-lookup limit by adding every SaaS sender (Google, Mailchimp, HubSpot, SendGrid, Salesforce) as a separate include. Second, having two SPF records (some teams add a second by accident; this breaks authentication entirely). Third, ending with ?all (neutral) instead of ~all or -all, which makes the SPF record useless because no sender ever fails. Run a free SPF check tool after every DNS change. ReachIQ Email Health validates SPF on every sender domain before send and alerts when the record drifts.
Related questions
Does SPF alone protect against spoofing?
No. SPF authenticates the envelope-from (the bounce address), not the visible From header that the recipient sees. Spoofers can pass SPF while showing a different From. DMARC is what aligns the visible From with SPF or DKIM authentication, closing that gap.
What's the difference between ~all and -all?
~all is soft-fail: receivers can accept the mail but mark it suspicious. -all is hard-fail: receivers should reject unauthorized mail. Most teams start with ~all while testing, then move to -all once they're confident no legitimate sender is missing from the record.
Should I publish an SPF record on my sender domain even if no one sends from it?
Yes. A "null SPF" (v=spf1 -all) on any domain that doesn't send mail prevents spoofers from using it. Apply this to every domain you own that isn't used for sending, including parked domains and lookalike defensive registrations.