SPF Record Checker

What the SPF Checker looks at

SPF (Sender Policy Framework, RFC 7208) is a TXT record that lists the servers allowed to send mail using your domain in the envelope sender (the bounce address). The checker:

• Finds every TXT record starting with v=spf1 on the domain.
• Parses each mechanism and modifier and flags syntax errors.
• Follows every include, redirect, a, mx and exists and counts DNS lookups against the limit of 10.
• Counts void lookups: lookups that return no answer or a domain that doesn't exist.
• Checks the final all qualifier.
• Shows the full include tree so you can see where your lookups are spent.

How to read the results

• Pass. One valid SPF record, within the lookup limit, ending in -all or ~all.
• Warning. Valid but risky. Examples: close to 10 lookups (one more vendor could break it), ?all (neutral, which protects nothing), a ptr mechanism (RFC 7208 says not to use it), or one void lookup.
• Fail. Receivers will get an error or the record is unsafe. Examples: more than 10 lookups, more than two void lookups, two SPF records, a syntax error, a redirect to a domain without SPF, or +all.
• Not tested. DNS didn't answer in time. Try again.
• Not applicable. The check doesn't apply to this domain. Even a domain that sends no mail should still publish v=spf1 -all, so this status is rare.

What counts toward the limit

RFC 7208 section 4.6.4 lists the terms that cause DNS lookups: include, a, mx, ptr, exists and the redirect modifier. The total across the whole tree must not exceed 10, or the result is PermError. ip4, ip6 and all don't count.

Each mx mechanism can also look up at most 10 address records. A domain with more than 10 MX hosts will make mx return PermError.

How redirect works

redirect=_spf.example.com hands evaluation to another domain's SPF record. Two rules catch people out:

• redirect is ignored if the record contains an all mechanism anywhere.
• If the target has no SPF record, the result is PermError, not "none".

Common problems and fixes

Two SPF records. This often happens when a new service tells you to "add a TXT record". Merge them:

Wrong:
example.com.  TXT  "v=spf1 include:spf.protection.outlook.com -all"
example.com.  TXT  "v=spf1 include:mailer.example.net ~all"

Right:
example.com.  TXT  "v=spf1 include:spf.protection.outlook.com include:mailer.example.net -all"

Too many lookups. Remove services you no longer use, drop a and mx if those hosts don't send mail, and move bulk senders such as newsletters to a subdomain with its own SPF record. Our guide on fixing SPF PermError from too many DNS lookups walks through it.

Void lookups. An include pointing to a retired service often returns nothing. Delete it.

Using +all. This authorizes every server on the internet. Replace it with -all or ~all.

Domain that sends no mail. Publish:

example.com.  TXT  "v=spf1 -all"

Behind a filtering gateway

When inbound mail passes through a filtering service, the SPF check that matters is done by the filter, on the original sender. Your own SPF record only needs to list servers that send your outgoing mail. If you use an outbound relay, add the include value your relay provider gives you. iBlockSpam customers find theirs in the setup wizard.

Limitations

• SPF checks the envelope sender, not the From address people see. It's DMARC that ties SPF to the visible From domain.
• SPF usually breaks when mail is forwarded, because the forwarding server isn't in your record. That's expected; DKIM survives forwarding more often.
• We count lookups using today's DNS. Vendors change their own SPF records, so a record that passes today can go over the limit later without you touching it. Re-check after adding any sender.
• A Pass means your record is well formed. It doesn't prove that every server sending your mail is listed. Your DMARC reports show that.

Related

See SPF records by email provider for the exact include each service documents. Read SPF vs DKIM vs DMARC for how SPF fits with the other two, or run the full Email Health Check.