SPF checker: what do
inboxes actually see?
Enter a domain — we fetch its TXT records, isolate the v=spf1, expand every include recursively, and count the number that decides everything: the 10-DNS-lookup budget. Exceed it and SPF silently returns permerror — protection off, no bounce, no warning.
Four ways SPF breaks without warning
SPF fails politely: mail keeps flowing while the protection quietly turns off. Each of these four is invisible from your outbox — and obvious in a full parse.
The 10-lookup cliff
Every include, a, mx costs one DNS lookup — nested includes too. The budget is 10. Lookup #11 doesn’t degrade anything: the whole record returns permerror and SPF is off.
RFC 7208 §4.6.4The second record
Two TXT records starting v=spf1 don’t merge — both become invalid, instantly. The classic cause: a plugin or an agency “added” SPF instead of editing the record that was already there.
multiple = permerrorThe open door: +all
+all means “and everyone else passes too.” It authorizes the entire internet to send as you — every spammer included. One character separates it from -all, which means the opposite.
worse than no recordThe stale include
The vendor you left in 2023 is still in your record. If their domain went dark, that’s void lookups and permerror. If it’s alive, their current customers can still send mail that passes as you.
audit yearlySix things your record can say
The last mechanism decides what happens to mail from an IP you didn’t list. A few special cases decide the rest.
“Not on my list? Reject it.” The strict, correct ending — if the list in front of it is complete and the record parses. Strictness only counts when the rest is right.
“Not on my list? Accept it, but mark it.” Designed as a rollout stage, then kept forever. With DMARC on top it still fails unauthorized mail — without DMARC it’s a shrug.
“Not on my list? No opinion.” Cryptographically equivalent to not publishing SPF at all — receivers learn nothing. Usually a leftover from a copy-pasted template.
“Not on my list? They pass anyway.” The entire internet is now authorized to send as your domain — and mail that should look forged gets an SPF pass instead.
Reverse-DNS matching: slow, unreliable, and formally “SHOULD NOT be used” since 2014. It burns a lookup, can silently mismatch, and some receivers skip it entirely.
Too many lookups, two records, a syntax slip, a dead include — the result is the same: receivers treat your domain as having no valid SPF. Mail still flows. Nobody tells you.
How the 10-lookup budget works
RFC 7208 caps the DNS lookups a receiver will spend evaluating your record. The cap is the whole game — and most of your budget is spent by other people’s records:
- What burns budget: include, a, mx, ptr, exists, redirect — one each, nested ones included.
- What’s free: ip4, ip6 and all — literal values, no DNS needed. This is why “flattening” works.
- One include is rarely one lookup: Mailgun’s is 5, Salesforce’s is 2. A record that “only has five includes” can be at 11 without anyone touching it.
- Two lookups may return nothing — the void-lookup limit. Dead includes and typos burn it fast, and the result is the same permerror.
Where the budget actually goes
per vendor · re-verified Jul 2026What you can check yourself
The raw material is one dig away. The tree hiding behind it is not.
Common SPF questions
Type your domain above. We fetch its TXT records, confirm exactly one begins with v=spf1 (two is an instant fail — they don’t merge, they both die), then parse every mechanism against RFC 7208: each include is expanded recursively into a tree, every DNS lookup is counted against the budget of 10, the final all policy is graded, and every IP range your record authorizes is summed into one list. Free, no signup.
Receivers evaluating SPF will perform at most 10 DNS-querying mechanisms per check (RFC 7208 §4.6.4). include, a, mx, ptr, exists and redirect all count, including the ones hiding inside your vendors’ includes. At lookup #11 evaluation aborts with permerror. Nothing bounces on your side; DMARC simply treats your domain as publishing no SPF. The break arrives gradually, one signup at a time, and announces itself never.
-all is the destination: reject what isn’t yours. ~all is the journey: “mark it, don’t bounce it”. It’s the right setting while you’re still discovering senders — that invoicing tool nobody mentioned. It’s also the safe one if a lost legitimate email costs you more than a spoofed one. Two caveats: with DMARC in place the practical difference shrinks, because DMARC fails unauthorized mail under either. And -all at the end of a record that’s over the lookup limit is strictness attached to a corpse — the permerror wins.
No — and the failure mode is vicious. RFC 7208 says multiple v=spf1 records make the check return permerror: not “the first one wins”, not “they merge” — both become invalid. It usually happens innocently: a website plugin, an ESP wizard or a second admin “adds SPF” without noticing the existing record. The fix is one minute of work: merge all mechanisms into a single record, delete the rest. This tool counts your records first, before anything else, for exactly this reason.
It ends your record with “…and everyone else passes too.” Every IP on the internet becomes an authorized sender for your domain: a spammer forging your address gets an SPF pass, and if your DMARC policy relies on SPF alignment, that forged mail can pass DMARC as well — your authentication now vouches for the attacker. It’s genuinely worse than publishing no SPF at all, because “no record” makes receivers suspicious while “+all” makes them confident. It appears in the wild as a misguided deliverability “fix”. If this tool finds one, it will not be subtle about it.
Alone, no. SPF validates the envelope sender (the address used in the SMTP conversation), not the From: your reader sees. A forger can pass SPF on their own domain while displaying yours. Closing that gap is DMARC’s job: it demands the visible From aligns with what SPF or DKIM validated. It also tells receivers what to do when it doesn’t. The full stack is SPF + DKIM + DMARC, and this tool makes sure the SPF leg is standing, because a permerror here quietly kneecaps the other two.
In order of pain: remove what sends nothing — a and mx are free wins if your web server and MX never send outbound mail. ptr is always removable. Drop dead vendors — every include should map to a service you still pay. Split by subdomain — let newsletters send as news.yourdomain.com with its own record and its own budget. Last resort, flattening: replacing includes with their literal ip4/ip6 ranges costs zero lookups. But it freezes a copy of your vendors’ networks — when they renumber, your record silently rots. Flatten only with tooling or monitoring that re-checks it.
Free tools are just the start.
Uptimia keeps your sites healthy.
Uptime, SSL, domain expiry, page speed, transactions — monitored from 171+ locations worldwide. Free for 30 days.