What is SPF (Sender Policy Framework)?
Definition
SPF (Sender Policy Framework) is an email authentication method, defined in RFC 7208, in which a domain publishes a DNS TXT record listing the servers allowed to send mail on its behalf. Receiving servers check the connecting IP against that list. SPF validates the envelope sender (MAIL FROM), not the visible From address, so it is meaningful mainly in combination with DKIM and DMARC.
Also known as: Sender Policy Framework, SPF record, v=spf1, SPF policy
Reading an SPF record
An SPF policy is a single TXT record on the domain, evaluated left to right:
example.com. IN TXT "v=spf1 ip4:203.0.113.10 include:_spf.mail-example.net include:newsletter-example.com -all"v=spf1marks the record as SPF; there is no other version.ip4andip6authorise an address or a range.aandmxauthorise the hosts in the domain's own A or MX records.includepulls in another domain's policy, which is how mailbox providers and newsletter tools are added.allmatches anything left over, so it always comes last.
A qualifier in front of each mechanism sets the result: + pass (the default), - fail, ~ softfail, ? neutral.
What SPF does and does not verify
Receivers apply SPF during the SMTP conversation to the domain of the envelope sender, the MAIL FROM (and to the HELO/EHLO name). The From: header that people see in their mail client is not part of the check. A spoofer can use their own domain as the envelope sender, put your address in From:, and still pass SPF. Closing that gap is the job of DMARC, which requires the domains to align.
SPF also breaks on forwarding: once an intermediary relays a message, the connecting IP is the forwarder's and the check fails. DKIM signatures survive plain forwarding, which is why the two are deployed together.
The ten-lookup ceiling
RFC 7208 caps the number of DNS-querying terms per evaluation at 10. include, a, mx, ptr, exists and redirect all count, including those nested inside included policies. Going over yields permerror, and receivers may treat the domain as having no usable SPF at all. It is easy to hit without noticing as every new SaaS tool asks for its own include. Ways out:
- Delete includes for services you no longer use.
- Avoid
ptr, which is slow and discouraged by the RFC. - Send bulk mail from a dedicated subdomain, which gets its own SPF record and its own budget of ten.
“SPF flattening” replaces includes with literal IP ranges. It works until the provider changes its addresses, so it is only safe when something regenerates the list automatically.
One record, and choosing -all
A domain may publish exactly one v=spf1 record; two of them produce a permerror. Extend the existing policy instead of adding another. Whether to end with ~all or -all depends on how confident you are in your sender inventory. Once every legitimate source is listed, -all is the clearer statement, though in practice most receivers make the final call in combination with DMARC.
What major mailbox providers expect
Since February 2024, Google and Yahoo have enforced stricter sender requirements. Per their documentation, every sender needs at least SPF or DKIM. Bulk senders, which Google defines as those sending more than 5,000 messages a day to personal Gmail accounts, need both SPF and DKIM, plus a DMARC record and alignment with the From domain. Meeting these rules affects deliverability, but a valid SPF record alone does not guarantee inbox placement.