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.

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=spf1 record. When it does, the check returns permerror and 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, exists and the redirect modifier 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. +all authorises the entire internet to send as your domain. ?all makes no assertion at all. ~all asks receivers to mark unauthorised mail; -all asks 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.

Scan your domain

Ruleset 2026.09.14, sources verified 2026-09-14. Methodology.