SPF records, explained with real examples (and the 10-lookup trap)

An SPF record is a guest list. It’s a single line of DNS that tells the world: these are the only servers allowed to send email as my domain. When a receiving server gets a message claiming to be from you, it checks the connecting IP against that list. On the list → pass. Not on the list → suspicion, spam folder, or rejection.

Simple idea. Then the syntax shows up.

What SPF actually checks (it’s not the From line)

SPF validates the envelope sender — the Return-Path address used in the SMTP conversation — not the From: your recipient sees in their inbox. That distinction matters later for DMARC alignment, but the practical takeaway is: SPF protects the domain doing the sending, and a passing SPF on a lookalike domain proves nothing. That’s why SPF alone never earned anyone inbox placement.

How to read a record, mechanism by mechanism

Here’s a real-world record:

v=spf1 include:_spf.google.com ip4:203.0.113.40 -all

• v=spf1 — the version tag. Every record starts with it, exactly once.
• include:_spf.google.com — “also trust everything in that domain’s SPF record.” This is how you authorize Google Workspace, your marketing platform, your CRM — each provider publishes its own list and you include it.
• ip4: / ip6: — trust this exact IP or CIDR range. The cheapest mechanism there is (more on cost below).
• a / mx — trust the IPs behind the domain’s A or MX records. Convenient, rarely necessary, each costs a DNS lookup.
• -all — the verdict for everyone not on the list. -all says “fail them,” ~all says “soft-fail them” (mark, don’t reject). Anything ending in +all says “actually, everyone is allowed” — which is the same as having no SPF at all, except it also advertises that you don’t know what you’re doing.

Copy-paste examples for common stacks

Google Workspace only:

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

Workspace plus a transactional provider:

v=spf1 include:_spf.google.com include:spf.yourprovider.com ~all

The rule when adding a provider: edit the one record you have. Two SPF records on the same domain is an automatic permerror — receivers treat it as broken and your authentication silently dies. If you want to build your record interactively, with each provider’s include filled in for you, use our free SPF Record Generator.

The 10-lookup trap

This is the part that quietly breaks mature domains. RFC 7208 caps SPF evaluation at 10 DNS lookups per check. Every include:, a, mx, redirect and exists costs one — including the nested ones inside the records you include. One marketing platform’s include can hide three or four lookups inside it.

Cross the limit and the result is permerror: not a warning, a hard authentication failure on every email you send. And since Google, Yahoo and Microsoft started enforcing authentication for bulk senders, a permerror behaves like a fail.

The fixes, in order of preference:

1. Remove includes you no longer use. That tool you trialed in 2024 is still spending your lookup budget.
2. Use ip4: for anything static — direct IPs cost zero lookups.
3. Split providers across subdomains. Each subdomain gets its own SPF record and its own fresh budget of 10.
4. Flattening (replacing includes with their resolved IPs) as a last resort — it works until a provider rotates IPs, and they all rotate IPs.

You don’t have to count by hand: our SPF Checker resolves your entire include tree and shows every lookup against the limit of 10, nested includes and all.

Why the 10-lookup limit exists at all

It’s worth understanding why RFC 7208 imposes a hard cap instead of just letting SPF records resolve however many nested includes they need. Every mechanism that requires a DNS lookup — include, a, mx, redirect, exists — means the receiving mail server has to make its own outbound DNS query just to evaluate one incoming message’s authentication. Without a ceiling, a maliciously or carelessly constructed SPF record could force a receiving server into dozens or hundreds of nested lookups per message, effectively turning ordinary mail delivery into a way to generate large amounts of DNS traffic against arbitrary third-party name servers. The 10-lookup cap exists specifically to bound that cost — it protects the receiving infrastructure and the DNS ecosystem generally, not just the sender’s own deliverability.

That’s also why the limit applies to the total lookup count across the entire resolved chain, not just the mechanisms written directly in your own record. An include:_spf.google.com might itself contain another include, which contains another, each one counted against your budget even though none of those nested records are ones you wrote or control. This is precisely what makes the limit sneak up on domains that feel like they’re only using two or three providers: two providers can easily hide six or seven lookups between them once their own nested includes are counted, especially if either provider’s SPF setup has grown more complex since you first added it. A record that passed cleanly at setup can silently cross the limit months later purely because a vendor changed their own infrastructure — with no notification to you, because SPF resolution happens entirely on the receiving side at send time, not at the moment you publish or edit your record.

How SPF, DKIM, and DMARC divide the work

None of the three authentication mechanisms does the whole job alone, which is worth laying out plainly since they’re so often mentioned together without explaining who checks what:

Mechanism	What it verifies	What breaks it
SPF	Which servers are allowed to send as this domain, checked against the envelope sender	Forwarding (the forwarder’s IP isn’t on the list); exceeding the 10-lookup limit
DKIM	A cryptographic signature proving the message content wasn’t altered in transit	A relay that modifies the message body or headers after signing; a missing or revoked key
DMARC	Whether SPF or DKIM (or both) actually align with the visible From: address	Neither SPF nor DKIM aligning with the From: domain, even if one passes on its own

The practical implication: a domain can have a perfectly valid SPF record and still fail DMARC, because SPF validates the envelope sender, not the address a recipient actually sees. That gap is exactly why DMARC exists as a third layer rather than SPF and DKIM simply being considered sufficient on their own.

Mistakes that void the whole record

• Two SPF records — permerror, see above.
• +all — a guest list that admits everyone.
• ptr — deprecated in the RFC, ignored or penalized by receivers.
• Typos in includes — a void lookup; more than two of those is also a permerror.

SPF alone won’t save you

Forwarding breaks SPF — the forwarder’s IP isn’t on your list, so a perfectly legitimate email fails. That’s why SPF was never meant to stand alone: DKIM survives forwarding, and DMARC ties both to the From address your recipient actually sees. To see all three on your domain in one pass, run the free Domain Health Checker — it reads SPF, DKIM, DMARC and MX together and explains each fix in plain language.

Set the record once, check it after every new provider, and SPF becomes the boring infrastructure it was always meant to be. Boring is the goal.

Common questions

Can a subdomain have its own SPF record separate from the root domain? Yes, and it’s one of the standard fixes for a domain running short on lookup budget. SPF evaluation is scoped to whatever domain appears in the envelope sender, so mail.example.com and example.com can each publish their own record with its own independent 10-lookup allowance, as long as mail is actually routed through the matching subdomain.

Does SPF need to be updated when switching email providers? Yes — this is one of the most common ways a record breaks. Removing the old provider’s include and adding the new one is required; simply adding the new provider on top of the old without removing anything both wastes lookup budget on a provider you no longer use and, if left long enough, contributes to crossing the 10-lookup limit for no functional benefit.

What happens if SPF passes but DKIM fails, or the other way around? DMARC only requires one of the two to pass and align, not both — a message with valid, aligned DKIM can still pass DMARC even if SPF fails (which happens routinely with forwarded mail), and vice versa. That’s part of why running both, rather than relying on just one, meaningfully improves deliverability: each one covers failure cases the other doesn’t.

Is there a downside to setting SPF to ~all instead of -all once authentication is fully set up? ~all (soft fail) tells receivers to accept but flag mail from unlisted sources, while -all (hard fail) tells them to reject it outright. Once every legitimate sending source is confirmed correct and included, -all is the stronger setting — it closes the door SPF is meant to close. ~all is mainly useful as a transitional setting while confirming a new record doesn’t accidentally block legitimate mail.