Email authentication
SPF checker
Check an SPF record for the faults that silently break it, and count every DNS lookup it costs.
Free, no accountLive check
Result
RFC 7208 §4.6.4 caps the whole chain at 10.
The verdict, the record and the lookup count appear here once you press Check SPF record.
What this is
This SPF checker reads the SPF record a domain publishes and follows it the way a receiving mail server does - every "include" and "redirect" opens another record of its own, and each one spends part of a fixed budget of ten DNS lookups before the whole thing stops working.
SPF (Sender Policy Framework) is a single TXT record that lists the servers allowed to send mail for a domain. A receiving server reads it, works through the mechanisms in order, and the first one that matches decides the result: Pass, Fail, SoftFail or Neutral depending on the qualifier in front of it.
An "include" mechanism does not count the servers it lists against the record itself - it points at another domain's own SPF record and asks the receiver to go and read that one too. A provider's include can itself include others, so one line in your record can hide several more DNS lookups once the chain is followed all the way down.
How to read the result
The include chain below shows every step that chain took, in order, each one marked with what it cost. A step in amber found nothing where something was expected - a void lookup - and a step in red is a fault that stops the mechanism working at all.
The total at the top of the chain is what matters most: RFC 7208 §4.6.4 caps the lookups an "include", "a", "mx", "ptr" or "exists" mechanism (or a "redirect") can cause at ten in total. Go over that and a checking receiver returns PermError and ignores the record completely - which looks, to every sender you listed, exactly like having no SPF record at all.
Common mistakes
What goes wrong most often, and how to tell.
- Adding one provider’s include after another without counting the costEvery provider you add - your mailbox host, your marketing platform, your helpdesk - adds at least one lookup, and some of their own records include others of their own. A record that looks like four lines can easily cost eight or more lookups once every nested include is followed.
- Publishing "+all" to stop a mail client complainingA "+all" mechanism passes every sender, listed or not, which defeats the purpose of every mechanism before it. It is sometimes added to silence a warning without understanding what it does; the fix is almost always "~all" or "-all" instead.
- Leaving a record with no terminal "all"Without "all" (or a "redirect" to a record that has one), anything not explicitly listed gets the default Neutral result under RFC 7208 §4.7 - the same as no SPF record, for every sender you did not think to list.
- Publishing a second SPF record instead of editing the firstA domain gets exactly one "v=spf1" TXT record. Adding a second one rather than merging into the first makes the whole thing a PermError under RFC 7208 §4.5, which is worse than either record on its own.
Questions
What people ask about this tool.
- Each "include", "a", "mx", "ptr" and "exists" mechanism, and each "redirect" modifier, counts as one DNS lookup against a limit of ten set by RFC 7208 §4.6.4, and an include can itself include others. Four providers can easily add up to more than ten once their own chains are followed.
- A checking receiver returns PermError and is required to treat the record as if it did not exist. Every server you listed as allowed to send then looks exactly the same as one you never mentioned.
- It is a lookup that found nothing - no record at all, or the domain does not exist. RFC 7208 §4.6.4 allows at most two before the chain is a PermError on its own, separately from the ten-lookup budget.
- "-all" hard-fails any server not listed, which is what a finished record should use. "~all" soft-fails instead, which is the safer choice while you are still confirming the list is complete, since it tells receivers to be suspicious rather than reject outright.
Use it from the API
The same check, as one request.
This example uses a name RFC 2606 reserves for documentation, ending in .example, .test, .invalid or .localhost. None of them is a real domain, and nobody can register one.