SPF record checker
Parses your record, expands every include the way a receiving server does, and counts the DNS lookups that count against your limit of ten.
Free. No signup. A full scan runs every check, not just this one.
- Checking domain…
- Checking mail provider…
- Checking SPF…
- Checking DMARC…
- Checking DKIM evidence…
- Checking security configuration…
- Evaluating provider requirements…
What this checks
Most SPF checkers read the record as a string. A receiving mail server does something considerably more involved, and the difference is where real failures live.
- One record, or more than one. RFC 7208 says a domain must not publish more than one
v=spf1record. When it does, the check returnspermerrorand SPF neither passes nor fails cleanly — it stops working. This is easily the most common serious SPF fault, and it usually happens because two people each added one. - The ten-lookup budget.
include,a,mx,ptr,existsand theredirectmodifier each spend one of ten permitted DNS lookups. Critically, lookups inside your providers' records count against your budget. Your record can cross the limit because a provider changed theirs, with no change from you. - Void lookups. RFC 7208 advises a limit of two lookups that return NXDOMAIN or an empty
answer. Exceeding it produces
permerror. Void lookups almost always mean an include pointing at a service you stopped using. - Cycles and dead includes. A failed include is not skipped; it makes the whole
evaluation a
permerror. - The terminator.
+allauthorises the entire internet to send as your domain.?allmakes no assertion at all.~allasks receivers to mark unauthorised mail;-allasks them to reject it.
Why the lookup limit matters more than it sounds
Going over ten does not degrade SPF gracefully. Evaluation returns permerror, which means SPF
cannot pass for anyone, which means SPF-based DMARC alignment cannot pass either. Every include in the record
may be individually correct and the record still fails completely.
The fix is not a flattening service that expands includes into IP ranges. That trades a lookup problem for a staleness problem: providers change their ranges, your flattened record does not, and mail starts failing with nothing visibly wrong. The fix is removing includes for systems that no longer send your mail — which means knowing which ones those are.
What the scan shows you
The full record, the expanded include tree with each level's contribution, the lookup count against the limit, every syntax error with the term that caused it, and which sending platforms your includes map to.
Common questions
Can I have two SPF records if one is for a different provider?
No. RFC 7208 is explicit that a domain must not publish multiple records that would cause more than one to be selected, and receivers return permerror when they find two. Every sender goes into one record.
Does ~all or -all matter for Gmail and Outlook?
Both satisfy the published requirement to have SPF. ~all asks receivers to mark unauthorised mail rather than reject it, which is the safer setting until you are confident your sender list is complete.
My record is under ten lookups today. Is that safe?
It is correct today. Because lookups inside your providers’ own records count against your budget, a provider adding one include to their record can push you over without you touching yours. Anything at eight or above is worth reducing.
Find, explain, repair, verify
The scan is free and complete. If it finds something wrong, the £19 Repair Pack gives you the exact records to publish for your domain and your providers, the order to publish them in, and the previous values so you can undo anything.
Ruleset 2026.09.14, sources verified 2026-09-14. Methodology.