Skip to content
← Blog Deliverability

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

What an SPF record actually says, how to read every mechanism, copy-paste examples for common stacks — and the DNS lookup limit that silently voids it.

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.

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.