SPF Records Explained: How Sender Authorization Works

SPF gets set up the same way almost everywhere: your mail provider hands you a string, you paste it into a TXT record, and it works. That's a reasonable way to get it running, but it leaves the mechanics as a black box, which makes it hard to debug when a legitimate message starts failing or a new sending source needs to be added correctly.

What SPF checks

SPF (Sender Policy Framework) is a TXT record listing the mail servers authorized to send email for a domain. When a receiving server gets a message, it checks the envelope sender, the MAIL FROM address used during the SMTP handshake, which is often invisible to the recipient and can differ from the From: header they see. It looks up the SPF record on that envelope sender's domain and checks whether the connecting server's IP address is on the authorized list.

That's the whole mechanism: one DNS lookup, one IP address, one list to check it against.

How evaluation actually works

A receiving server evaluates an SPF record as an ordered list, left to right, stopping at the first mechanism that matches:

v=spf1 ip4:203.0.113.10 include:_spf.google.com ~all

1. Start after v=spf1, which just marks the record's version and is required to be first.
2. Check ip4:203.0.113.10. If the connecting IP matches, evaluation stops here with a pass.
3. If it doesn't match, move to include:_spf.google.com. This fetches Google's own SPF record and checks the connecting IP against it. If it matches there, evaluation stops with a pass.
4. If nothing matched by the end, fall through to ~all, the catch-all for anything not explicitly listed above.

Order matters because evaluation stops at the first match. A broad include: placed before a narrower ip4: would never let the more specific mechanism get evaluated for an IP that also happens to satisfy the broader one.

The mechanisms

Each term in an SPF record is a mechanism, checked against the connecting IP in order:

• ip4: / ip6: matches a specific IP address or CIDR range directly. No extra DNS lookup required.
• a matches if the connecting IP matches the A (or AAAA) record of the domain itself. Rare on its own, since most mail doesn't send from the same server that hosts the website.
• mx matches if the connecting IP matches any of the domain's MX hosts. Useful if your mail server also sends outbound mail, uncommon with hosted providers.
• include: delegates to another domain's SPF record and checks the connecting IP against it. This is how mail providers let you authorize their infrastructure without listing raw IP addresses yourself, and it's the mechanism you'll use most.
• exists: matches if a DNS query for the given domain returns any A record at all. Used for more elaborate setups, like matching against a lookup that encodes the sending IP into the queried hostname.
• ptr matches based on reverse DNS. RFC 7208 discourages it: it's slow, unreliable, and can consume most of the lookup budget described below on its own. Avoid it in new records.
• all always matches. Placed last as the catch-all for anything not covered by an earlier mechanism.

A separate redirect= modifier (not a mechanism) can point evaluation at another domain's entire SPF record instead of just checking one list within it, effectively substituting an inherited policy for this one. It's less common than include: and mostly seen when a domain wants to fully mirror another domain's SPF policy rather than add to it.

Qualifiers: what a match decides

Each mechanism can be prefixed with a qualifier that determines what a match means. include:_spf.google.com is shorthand for +include:_spf.google.com, since + is the default when no qualifier is written:

• + (Pass, default): the sender is authorized.
• - (Fail): explicitly not authorized. Receiving servers are permitted to reject the message outright.
• ~ (SoftFail): probably not authorized, but treat it as suspicious rather than reject it. This is what almost every record ends with, as ~all, because a hard fail on the catch-all is unforgiving toward edge cases like a message forwarded through an unlisted relay.
• ? (Neutral): explicitly no opinion either way. Functionally similar to having no SPF record at all for that portion of the check.

The qualifier only applies to whichever mechanism matched first. A message can match +ip4: early in the record and pass, even if the record ends in -all, because evaluation already stopped.

The lookup limit, precisely

RFC 7208 caps SPF evaluation at 10 DNS lookups. Every include:, a, mx, ptr, and exists term counts as one against that budget, whether it's written directly in your record or pulled in through a nested include: chain. A record with four include: entries, each of which itself includes another provider's record, can burn through the limit faster than it looks from the raw text.

A stricter, less-known sub-limit also applies: no more than two of those lookups are allowed to come back empty or NXDOMAIN, called void lookups. This exists specifically to prevent SPF from being used to generate large amounts of DNS traffic pointed at a third party's nameservers. A record referencing a provider that's since deprecated a domain, or a typo'd include:, can trip this limit even while comfortably under 10 total lookups.

Either limit being exceeded returns a permerror, and most receiving servers treat a permerror as a failure, not as "skip SPF and move on." MyDMARC's SPF checker counts both the lookup total and the void-lookup count for an existing record and flags whether either is close to the limit.

Why forwarded mail breaks SPF

When a message is forwarded rather than sent directly, the forwarding server is what connects to the final destination, but the envelope sender usually stays the domain that originally sent it. The receiving server checks that original domain's SPF record against the forwarder's IP, which was never listed there, so SPF fails, even though the message genuinely did come from an authorized source further back in the chain.

This is exactly the failure mode DKIM is built to survive: its signature travels with the message itself and doesn't depend on which server relayed it along the way, so a forwarded message can still authenticate on DKIM alone even after failing SPF outright.

Checking an SPF record

dig TXT example.com

Look for the entry starting with v=spf1. There should be exactly one; a domain with two SPF records is itself a permerror regardless of what either one says.

How this connects to DKIM and DMARC

SPF is one input into DMARC's alignment check, not the whole picture. DMARC Explained covers how alignment between SPF, DKIM, and the visible From: address gets evaluated. If you don't have an SPF record yet, Your Domain Has No SPF Record walks through adding one for your specific setup. For how all three email authentication records fit together as TXT records, see DNS TXT Records: SPF, DKIM, and DMARC All Live Here.

How DNS monitoring fits in

An SPF record is easy to change without fully thinking through the consequences: someone adds an include: for a new tool, tightens ~all to -all, or removes an entry for a service that's still sending mail. Each of those is a one-line DNS edit with real deliverability consequences, and none of them announce themselves outside of bounce reports days later.

OneDollarDNS monitors your SPF TXT record alongside every other record on your domain and alerts you the moment its value changes, so a bad edit gets caught before it costs you legitimate mail.