Check an SPF record against RFC 7208: the ten DNS lookup limit that silently disables it, mechanisms after all that are never reached, a qualifier that authorises the whole internet, and the deprecated ones.
Or drop a file anywhere on this panel. Nothing is uploaded: the analysis runs in this tab.
The answer appears here
Paste on the left and press Check the record. Nothing leaves this tab.
Nothing else to flag.
No formatting problems, and nothing the rules object to. Worth remembering what that covers: this reads the file you pasted, not the account or cluster it will be applied to.
No finding matches that filter.
Real input you can load into the tool above. Each one shows a different thing going wrong, because that is what the tool is for.
Over the ten lookup cap. Receivers return a permerror, which means SPF is not evaluated at all: this record stops authorising your own senders as well as blocking anyone else.
v=spf1 include:_spf.google.com include:sendgrid.net include:mailgun.org include:servers.mcsv.net include:spf.protection.outlook.com include:amazonses.com include:_spf.salesforce.com include:spf.mandrillapp.com include:helpscoutemail.com mx a ptr ~all
Mechanisms are evaluated left to right and all matches everything, so the include appended at the end is never reached and that sender is not authorised.
v=spf1 include:_spf.google.com -all include:sendgrid.net
A plus qualifier on all. Every host anywhere passes SPF for this domain, and it hands DMARC alignment to anyone who wants it.
v=spf1 include:_spf.google.com +all
RFC 7208 permits exactly one. Two is a permerror, so both stop working, and this usually appears when a second vendor adds its own TXT record.
v=spf1 include:_spf.google.com ~all v=spf1 include:sendgrid.net ~all
These are the ones that fail silently. The config is accepted, nothing raises an error, and the consequence arrives later.
Ten DNS lookups is a hard cap counted recursively through every `include`. Over it is a permerror, and a permerror means receivers ignore SPF completely, so your own mail stops being authorised too.
Instead:Flatten the stable includes to `ip4` and `ip6`, which cost nothing, and leave headroom for vendors adding lookups of their own.
`~all` asks receivers to accept the message and mark it. On its own it blocks nothing at all.
Instead:Use it while you are still finding senders, then move to `-all`, and publish DMARC so a failure becomes a decision.
RFC 7208 permits exactly one per domain. Two is a permerror, so both records stop working and the mail that breaks is the mail that was already working.
Instead:Merge into one record with an `include:` per sender.
Mechanisms are evaluated left to right and `all` matches everything, so nothing after it is ever reached. The new sender is simply not authorised.
Instead:Add it before the `all` mechanism.
RFC 7208 says it should not be published. It is slow, several large receivers ignore it, and it still costs one of your ten lookups.
Instead:Replace it with `ip4`, `ip6` or an `include` for that sender.
SPF is one line of text with a hard limit hidden inside it. Exceed ten DNS lookups and receivers return a permerror, and a permerror means the record is ignored: it stops authorising your own mail as well as blocking anyone else's.
include, a, mx, ptr, exists and redirect each cost one lookup. So does everything inside an include, and everything inside that. A record showing five mechanisms can already be at eleven once the vendors expand, and the vendors change their own records without telling you. That is why an SPF setup that worked for two years breaks on a Tuesday with no change on your side.
v=spf1 include:_spf.google.com include:sendgrid.net mx a -all
costs 1 costs 1 1 1
plus every lookup inside each include, recursively,
which is the part you cannot see from the record itselfThey resolve nothing, so they cost nothing against the limit. Flattening a stable include into its addresses is the standard fix, and the standard cost is that you now own keeping those addresses current. Flatten the vendors that rarely change and keep includes for the ones that do.
Softfail asks the receiver to accept the message and mark it. Without DMARC on top, that is the whole effect: mail from anywhere is still delivered. It is the right setting while you are still finding senders, and it is not protection. DMARC is what turns an SPF failure into a decision.
RFC 7208 permits exactly one SPF record per domain. Publishing two is a permerror, so both stop working. It happens when a second vendor is onboarded and adds its own TXT record rather than an include, and the mail that breaks is the mail that was working before.
Mechanisms are evaluated left to right, and all matches everything, so anything after all is never reached. A sender appended to the end of a record is simply not authorised. Separately, RFC 7208 says ptr should not be published at all: it is slow, several large receivers ignore it, and it still costs one of your ten.
It makes no DNS queries, because nothing on this site does. That means the lookup count here is a FLOOR: it counts the mechanisms in the record you paste and cannot expand what is inside each include. A record showing eight visible lookups may well be over the limit already. Use a resolver that expands includes for the true total, and use this to understand the record and find the structural problems.