Sender Policy Framework (SPF)

Sender Policy Framework (SPF) is an email authentication standard that lets a domain owner publish, as a TXT record in DNS, the list of mail servers allowed to send email for that domain. When a message arrives, the receiving server checks whether the server that delivered it is on the list for the domain in the message’s envelope sender address. SPF is one of the two checks, with DKIM, that DMARC relies on.

At a glance

• SPF is a single TXT record beginning v=spf1, listing authorized IP addresses and other domains’ SPF records to include.
• It checks the envelope sender (return-path) domain, not the From address people see; DMARC links the two.
• SPF typically fails when mail is forwarded, because the forwarding server isn’t on your list.
• Evaluating a record may trigger at most 10 DNS lookups; records that exceed that limit return an error.
• Services that rely on SPF, rather than DKIM, to pass DMARC need to be covered, and the record needs updating as services change.

What problem it solves

Without SPF, receivers have no published way to tell whether a server is allowed to send mail for your domain. SPF gives them that list. It helps receivers spot mail sent from unauthorized servers and is one of the authentication signals mailbox providers use when deciding whether mail reaches the inbox.

On its own SPF is a limited anti-spoofing control: it checks a domain recipients don’t see, and an attacker can pass SPF for a domain they control while displaying yours in the From line. Its main value today is as one of the two paths to passing DMARC, which does check the visible From domain.

How it works

1. You publish a record. For example, v=spf1 ip4:203.0.113.10 include:spf.example-mail-provider.com -all. Mechanisms such as ip4, ip6, a, mx and include list what is allowed; the final all sets the result for anything else.
2. A message arrives. The receiving server takes the domain from the envelope sender (the MAIL FROM address used during delivery). For bounce messages, which have an empty envelope sender, it checks the domain the server gave when it connected (the HELO name).
3. It evaluates the record. The receiver works through the mechanisms in order, following include and similar references, until one matches the connecting IP address.
4. It returns a result. Common results are pass, fail (-all), softfail (~all), neutral, none (no record) and permerror (a broken record, such as one needing too many lookups).
5. It feeds DMARC. If the result is pass and the envelope domain aligns with the From domain, SPF counts toward DMARC.

The 10-lookup limit. Mechanisms that need a DNS lookup, including include, a, mx, ptr, exists and redirect, count toward a limit of 10 per evaluation, including lookups nested inside included records. Organizations using many email platforms reach it quickly. Common fixes are removing unused includes, using ip4/ip6 entries where addresses are stable, and moving some senders to subdomains with their own records. “Flattening” includes into IP lists also works but needs monitoring, because providers change their addresses.

When it matters for buyers

• When adding or removing an email-sending platform. Each change may need an SPF update; a forgotten include can cause failures, and stale ones waste lookups.
• When moving to enforced DMARC. Senders that rely on SPF for alignment need return-path domains that match yours, which some platforms only offer through a custom return-path or subdomain setting.
• When deliverability drops. SPF errors such as permerror from too many lookups are a common cause.
• When mailbox providers’ bulk sender rules apply. High-volume senders are generally expected to have SPF in place; see bulk sender requirements.
• When migrating mail platforms. The old platform’s entries should come out once mail has moved.

Questions to ask vendors

These apply to any platform that sends email in your name.

• What SPF include or IP ranges do we need to add, and how many DNS lookups does your include use?
• Can you use a return-path on our domain or a subdomain, so SPF aligns for DMARC?
• Do you also sign with DKIM as our domain?
• How will you notify us if your sending IP addresses change?
• Can we put your service on a dedicated subdomain with its own SPF record?

How it differs from DKIM

DKIM attaches a cryptographic signature to each message and checks it against a public key in DNS, so the result doesn’t depend on which server delivered the message. SPF checks the delivering server’s IP address against a published list. That makes DKIM the more dependable check when mail is forwarded, while SPF is simpler to set up. Neither checks the visible From address by itself; DMARC does, and a DMARC policy at enforcement is also a prerequisite for BIMI logos. For filtering and protecting inbound mail, see our secure email gateway overview.

Problems this helps with

• Our emails failing authentication or landing in spam
• Adding a new marketing or billing platform broke our email delivery
• SPF record errors such as too many DNS lookups