SPF tells receiving mail servers which hosts may send mail for your domain. To check it, read the domain TXT records, find the one that starts with v=spf1, and confirm it lists the right senders and stays under the 10-lookup limit. The SPF checker does the lookup and the counting for you, but it helps to know what it is looking at.
Where SPF lives
SPF is not a record type of its own. It is an ordinary TXT record published at the root of your domain, and it always begins with the version token v=spf1. A typical record looks like this:
v=spf1 include:_spf.google.com include:servers.mcsv.net ip4:198.51.100.4 ~allEverything after the version is a list of mechanisms. Each one either authorizes a set of senders or, in the case of all, sets the default for anything that did not match.
Reading the mechanisms
A few mechanisms cover almost every record you will see:
- include pulls in another domain SPF record, which is how you authorize a provider like Google or a marketing platform.
- ip4 and ip6 authorize specific addresses or ranges directly.
- a and mx authorize whatever the domain A or MX records point to.
- all is the catch-all at the end.
Each mechanism can carry a qualifier: + for pass (the default), - for fail, ~ for softfail, and ? for neutral. You mostly see these on all.
The number that breaks records: DNS lookups
This is the fault that catches people out, so it is worth dwelling on. When a receiver evaluates your SPF record, some mechanisms force it to make further DNS queries. include, a, mx, ptr, exists and redirect each cost one lookup. The flat ones — ip4, ip6 and all — cost nothing.
RFC 7208 caps the total at 10. Go over it and the receiver is required to return a PermError, at which point your carefully built record does nothing. The trap is that each include can expand into its own record with its own lookups, so a record that looks short on paper can blow the budget once it is followed through. Three or four include statements from busy providers is often enough.
The SPF checker counts these terms and shows the running total against the limit, so you can see whether you are at 4 of 10 or dangerously at 11. If you are over, the usual fix is to drop providers you no longer use, swap an include for the specific ip4 ranges it covers, or flatten the record.
The faults to look for
When you check a record, three problems account for most failures:
Too many lookups. Covered above. If the checker reports more than 10, the record is invalid for any receiver that enforces the rule, which is most of them.
More than one SPF record. A domain may publish only one v=spf1 TXT record. If a second one creeps in — often when a new vendor is added without removing the old line — receivers cannot choose between them and return a PermError. The fix is to merge everything into a single record.
A weak or missing all policy. The record should end in -all (fail) or ~all (softfail) once you are confident it lists every legitimate sender. A record with no all has no default, and +all passes everything, which defeats the point. Start with ~all while you watch reports, then tighten to -all.
A sensible order to check things
- Confirm there is exactly one record and it starts with
v=spf1. - Read the
include,aandmxmechanisms and make sure every current sender is covered. - Count the DNS lookups and confirm the total is 10 or fewer.
- Check the
allqualifier is-allor~all, not+allor absent.
Checking it in one step
You can do all of this by hand with a DNS tool, but the lookup counting is tedious and easy to get wrong, because it means following every include into its own record. Enter a domain into the SPF checker and it fetches the record live over secure DNS, lists each mechanism, marks which ones cost a lookup, totals them against the limit, and flags a missing record, a duplicate, or a weak all. Nothing you type is stored. Once the record is clean, the SPF record generator helps you publish or rebuild it.