SPF Record Check
Expand the full SPF chain and check the 10 DNS-lookup limit and policy errors.
Enter a target
e.g. example.com — press ⏎ / ⌘⏎
What is SPF Record Check?
SPF Record Check doesn't just read your record — it expands the include and redirect chain to the end and shows how close you are to the 10 DNS lookup limit in RFC 7208 §4.6.4.
That limit is the most commonly missed mail failure: once exceeded, receivers return PermError and treat SPF as absent. Because the record still looks perfect, the problem usually isn't noticed until delivery drops. A flat text check can't see it; only recursive expansion can.
The analysis also reports multiple SPF records, include loops, void lookups, the discouraged ptr mechanism, and record-killing mistakes like +all.
Frequently Asked Questions
11 questionsWhat exactly is the 10 DNS lookup limit?
RFC 7208 §4.6.4 caps the include, a, mx, ptr and exists mechanisms plus the redirect= modifier at 10 DNS queries total during evaluation. Nested includes count too: three includes in your own record can still exceed 10 once their own includes are expanded.
What happens when the limit is exceeded?
Receivers return PermError, which is treated as "could not evaluate" rather than "failed". In practice your SPF record is ignored entirely — mail isn't SPF-authenticated even though the record looks perfect, and DMARC can't align via SPF.
How do I reduce the lookup count?
Three effective moves: (1) delete includes for providers you no longer use — usually the biggest win; (2) replace includes with literal ip4:/ip6: ranges where you can, since IP mechanisms cost nothing; (3) drop a and mx if they aren't genuinely needed.
Do ip4 and ip6 count toward the limit?
No. ip4:, ip6: and all require no DNS query, so you can add as many as you like. The only constraint is total record length — records over 255 characters get split into multiple strings in DNS.
What's the difference between -all and ~all?
-all (hardfail) asks receivers to reject unlisted senders; ~all (softfail) only asks them to mark it. Start with ~all, confirm via DMARC reports that every legitimate sender appears, then move to -all.
I have two SPF records — is that a problem?
Yes, a serious one. Per RFC 7208 §4.5, multiple v=spf1 records produce PermError and disable SPF completely. Merge every mechanism into a single record.
Do subdomains inherit SPF?
No. Every sending subdomain needs its own record. For subdomains that never send, publish v=spf1 -all to shut the door.
Is SPF enough on its own?
No. SPF validates only the envelope (Return-Path) domain, not the From header users see, and it breaks by design when mail is forwarded. Use it with DKIM and DMARC.
Why does forwarding break SPF?
The forwarder re-sends from its own IP while the Return-Path stays on the original domain, so SPF can't match. That's an inherent limit; SRS was designed to work around it, and DKIM usually survives forwarding.
What are the exists and macro mechanisms for?
exists: matches on whether a DNS query resolves, and macros like %{i} embed the sender's IP into the queried name, allowing dynamic policies. You'll see it in large mail infrastructures; small setups don't need it.
Can I mix ip4 and include?
Yes, in any order. A good practice is to put the most frequently matching mechanisms first — evaluation is left to right and stops at the first match, avoiding unnecessary DNS queries.