Check an SPF record for syntax, lookups and coverage

What a valid SPF record looks like

An SPF record is a TXT record at the domain apex beginning with v=spf1, followed by mechanisms evaluated left to right. The first mechanism that matches the connecting address decides the result, and the qualifier in front of it decides what that result is: a plus for pass, a tilde for softfail, a minus for fail and a question mark for neutral.

The include mechanism delegates a decision to another domain's SPF record, which is how a hosted sending platform publishes its own addresses without you having to track them.

example.com.  3600  IN  TXT  "v=spf1 ip4:203.0.113.0/24 include:_spf.example.net -all"

The ten-lookup limit, and the records it breaks

RFC 7208 caps an SPF evaluation at ten DNS-querying terms. The mechanisms include, a, mx, ptr and exists count, and so does redirect; ip4 and ip6 do not, because they need no query. The count is cumulative: every include is expanded, and the terms inside it count against the same total.

Exceeding the ten-lookup limit produces an SPF permerror, and most receivers treat an SPF permerror the same way they treat a domain with no record at all. The record does not gradually degrade — it stops working, usually on the day a provider adds an include of its own inside a record you have not edited in a year.

The same section also asks evaluators to treat more than two void lookups — terms that resolve to nothing at all — as a permanent error, so an include pointing at a domain that has been retired costs more than the one lookup it consumes.

v=spf1 include:_spf.example.net include:mail.example.org a mx -all

What -all, ~all and ?all actually do

The final mechanism decides what a receiver is told about every host you did not list. A hard fail, written -all, says the message is not from you. A softfail, ~all, says it probably is not, and asks the receiver to accept it anyway with a mark against it. Neutral, ?all, says nothing at all and is worth no more than publishing no record.

The choice matters less on its own than it does under DMARC, where an SPF result of fail or softfail is treated identically: neither authenticates the message. The reason to move to -all is not to change the DMARC outcome but to stop authorising hosts you did not intend to.

Why SPF fails when it should pass

SPF authenticates the envelope sender, the address given in MAIL FROM, and not the From header a reader sees. A message can pass SPF for a domain that has nothing to do with the name in the From line, which is exactly the gap DMARC alignment was written to close.

It also breaks on forwarding. When a mailbox forwards a message, the forwarding host connects from its own address while the envelope sender is unchanged, so the receiver checks an address that was never in your record. SRS rewrites the envelope sender to fix this; a DKIM signature survives the hop without needing to.

One record, never two

RFC 7208 allows exactly one v=spf1 record per name. Publishing a second — commonly by adding a provider's record beside an existing one rather than merging the mechanisms into it — makes the evaluation a permanent error, and receivers that follow the specification stop there. Merge the terms into a single record instead.

The older SPF resource record type is obsolete and should not be published; the TXT record is the only form receivers read.

What the SPF record checker reports

• The record as published, with every mechanism parsed and explained.
• The cumulative lookup count, including the terms inside each include.
• Void lookups, duplicate records and syntax that produces a permerror.
• The all mechanism and its qualifier, and roughly how many addresses the record authorises.
• Terms that appear after all, which no receiver ever reaches.