What this checker actually tests
Most SPF tools tell you whether a record exists. The two faults that break real mail are subtler than that, and both are checked here.
The ten lookup limit
SPF evaluation is capped at 10 DNS-querying mechanisms by RFC 7208 §4.6.4. The mechanisms that count are include, a, mx, ptr, exists and redirect — and they count recursively. A single include: for a large mail provider can spend four or five of your ten on its own.
This is why the limit catches people out: your record looks short, but the includes inside your includes push you over. We resolve the whole tree and count it the way a receiver does.
Over the limit, receivers return permerror and most treat it as an outright SPF failure — so mail that used to authenticate silently stops. Adding one more vendor is usually what tips it.
Duplicate records
A domain may publish exactly one SPF record. Two is not additive, it's a permanent error — and it's a common outcome when a second team adds a vendor without checking for an existing record. The fix is to merge the mechanisms into a single v=spf1 string.
The all qualifier
v=spf1 include:_spf.google.com include:sendgrid.net ~allThe final term says what to do with everything unlisted. ~all is softfail — accept, but mark it. -all is hardfail — reject. +all authorises the entire internet to send as you, and is always a mistake.
Under DMARC the difference between ~all and -all matters less than people assume, because it's your DMARC policy that decides what happens to mail that fails. Getting to p=reject matters more than the SPF qualifier.
SPF alone does not stop spoofing
Worth knowing before you spend a day perfecting this record. SPF authenticates the envelope sender — the address used during the SMTP conversation, which the recipient never sees. Someone can pass SPF for a domain they own while displaying your domain in the From header.
SPF also breaks whenever mail is forwarded: the forwarding server isn't in your record, so the check fails through no fault of yours. That's the problem ARC exists to solve.
Closing the visible-spoofing gap needs DMARC, which ties the authenticated domain back to the From address your recipients actually read. If you only fix one thing, fix that.
Common questions
Why does my record fail when it looks fine?
Almost always the lookup count. Run the check above — if it reports more than 10, that's your answer, and the fix is to flatten or remove an include rather than to rewrite the record.
How do I reduce SPF lookups?
Drop vendors you no longer use (start there — most domains are carrying at least one), replace an include with the specific ip4/ip6 ranges where the vendor publishes stable ones, and never use ptr, which is deprecated.
Be careful with automated "SPF flattening" that expands includes into raw IPs: it fixes the count and then quietly breaks the day your provider changes their addresses without telling you.
Do I need SPF if I have DKIM?
Publish both. DMARC passes if either aligns, so two mechanisms means two chances — and DKIM survives forwarding where SPF doesn't. Read the details on how SPF works and how DKIM works.