SPF Checker

What this tool does

It looks up a domain’s SPF record and analyses it against what RFC 7208 requires: that there is exactly one, how it ends (-all, ~all, ?all or +all) and how many DNS lookups it spends, with the limit of 10 that, once exceeded, invalidates the whole authentication. It shows you the raw record and a list of findings by severity.

SPF is the list of servers allowed to send email with your domain as the sender. It is published as a TXT record at the domain apex, and the receiving server queries it to decide whether the message is legitimate.

How to use it

1. Type the domain without https:// or www: example.com.
2. Click Check SPF.
3. Read the record and the findings. Red ones break delivery or protection; orange ones weaken it; green ones confirm that part is fine.

The three failures the tool catches

Two SPF records

The most common one when a new service is signed up for (a newsletter platform, a CRM, a shop) and “another SPF” is added instead of extending the existing one. The RFC is blunt: if more than one record starts with v=spf1, the result is permerror, a permanent error. In practice receivers treat the domain as having no SPF at all, and some penalise it more than the absence. The fix is to merge both sets of include into a single record; the SPF and DMARC record generator does it from the providers you use.

The trailing qualifier

The all mechanism goes last and says what to do with servers not on the list:

With DMARC in place, ~all and -all behave almost the same, because DMARC looks at alignment rather than the shade of failure. Without DMARC, -all is the only thing that makes a receiver reject a forged message.

More than 10 DNS lookups

Every include, a, mx, exists and redirect forces the receiver to make one more DNS query, and the limit is 10 in total, nested ones included: Google’s include spends 4 on its own, Microsoft 365’s several more. Past 10, the result is permerror and SPF stops counting, even if everything else is perfect. It is the silent breakdown par excellence: nobody sees it until mail starts landing in spam.

The tool counts the real lookups, following nested include records, not the mechanisms written. If it comes out above 10, the usual ways out are removing providers no longer in use, replacing a and mx with ip4: when the IPs are fixed, or moving bulk sending to a subdomain with its own SPF.

What SPF does not do

SPF only checks the envelope sender (Return-Path), not the address the user sees in “From”. An attacker can use their own domain in the envelope, pass SPF, and put yours in “From”. What closes that gap is DMARC, which requires the authenticated domain to match the visible one. That is why SPF is only the first third: the other two are DKIM and DMARC, and the email auditor reviews all three at once.

It does not survive forwarding either: when a server forwards your message, the envelope sender becomes the forwarder and your SPF fails at the destination. That is expected, and another reason to have DKIM, whose signature travels inside the message.

Questions it answers

• Does my domain have SPF? → if there is no record, the first finding is red.
• Why does my mail land in spam since I signed up for X? → look for “multiple records” or “over the limit of 10”.
• ~all or -all? → -all once every server is listed; ~all in the meantime, and DMARC either way.
• How many lookups does each provider spend? → the record generator adds them up as you pick them.