SPF (Sender Policy Framework, RFC 7208) lets a domain declare which servers may send mail using that domain in the envelope sender. A receiving server looks up the SPF record, compares the connecting IP with the list and returns pass, fail, softfail, neutral or an error.
The record is short, but it breaks easily. Every new tool you connect adds an include, includes contain more includes, and one day you cross the 10-lookup limit and SPF fails for all of your mail. This checker catches that before your recipients do.
What the checker does
It fetches the TXT records for your domain and then:
- Confirms there is exactly one record starting with
v=spf1. - Parses every mechanism and qualifier.
- Follows each
includeandredirectrecursively and builds an include tree. - Counts DNS lookups against the limit of 10, including nested ones.
- Flags risky or broken settings:
+all,?all, a missingall, theptrmechanism and includes that do not resolve. - Detects which known services are authorised (Google Workspace, Microsoft 365, major ESPs and help desks).
Anatomy of an SPF record
v=spf1 ip4:203.0.113.10 include:_spf.google.com include:sendgrid.net mx ~all| Part | What it does | Lookups |
|---|---|---|
v=spf1 |
Declares an SPF record. Must come first | 0 |
ip4: / ip6: |
Authorises a single IP or CIDR range | 0 |
include: |
Authorises whatever the other domain’s SPF record allows | 1, plus any nested |
a / mx |
Authorises the IPs behind your A or MX records | 1 each |
exists: |
Advanced macro-based check | 1 |
redirect= |
Uses another domain’s record entirely | 1 |
ptr |
Reverse DNS match. Deprecated, avoid | 1 or more |
~all / -all |
Result for any IP not matched above | 0 |
Qualifiers change the result of a match: + pass (default), - fail, ~ softfail, ? neutral.
Reading your results
Lookup count. The headline number. 0 to 7 is comfortable. 8 or 9 means you have little room for the next tool. 10 is the maximum. 11 or more is a PermError.
Include tree. Shows each include and what it expands to, with its own lookup cost. Google Workspace alone uses several lookups because _spf.google.com pulls in further records. This view tells you where your budget is going.
Detected services. A list of recognised senders. If you see a platform you no longer use, remove it and reclaim its lookups.
Warnings. Each issue is listed with a severity. Fix errors first, then warnings.
Common SPF errors and fixes
| Problem | Why it matters | Fix |
|---|---|---|
| Multiple SPF records | PermError, SPF fails everywhere | Merge into one v=spf1 record |
| More than 10 lookups | PermError, SPF fails everywhere | Remove unused includes, replace a/mx with ip4 where stable |
+all |
Authorises every server on the internet | Change to ~all or -all |
?all |
Neutral result gives no protection | Change to ~all or -all |
No all mechanism |
Unmatched IPs default to neutral | End the record with ~all or -all |
ptr mechanism |
Slow, unreliable, discouraged by RFC 7208 | Replace with ip4/ip6 ranges |
| Broken include | Counts as a void lookup, may cause PermError | Remove the include or fix the domain |
| Record over 255 characters in one string | Some DNS panels truncate it | Split into quoted strings, which receivers join |
A receiving server that hits an SPF permanent error may bounce the message with a code like 550 5.7.23, or treat SPF as failed during DMARC evaluation.
Staying under 10 lookups
When the count creeps up, work through these in order:
- Remove what you do not use. Old CRMs, retired newsletter tools and trial accounts linger for years.
- Replace
aandmxwith explicit IPs if your servers have fixed addresses. - Move senders to subdomains. Put marketing on
news.example.comwith its own SPF record, which has its own budget of 10. - Check whether you need the include at all. Many ESPs send with their own Return-Path domain by default, so their include in your root SPF does nothing for alignment. Mailchimp and Amazon SES (without a custom MAIL FROM domain) work this way.
- Flatten only as a last resort. Replacing an include with the IPs it resolves to saves lookups, but the record goes stale when the provider changes IPs.
Example records
Google Workspace only:
v=spf1 include:_spf.google.com ~allMicrosoft 365 plus a transactional ESP:
v=spf1 include:spf.protection.outlook.com include:sendgrid.net ~allOwn server plus Google Workspace, strict ending:
v=spf1 ip4:203.0.113.10 include:_spf.google.com -allA domain that sends no mail at all (protects parked domains from spoofing):
v=spf1 -allIf you would rather not write the record by hand, the SPF generator builds one from a list of services and counts lookups as you go.
SPF is only one third of the job
SPF checks the envelope sender, not the From address people see, and it breaks when mail is forwarded. That is why it works together with DKIM and DMARC. Once SPF is clean, check your signing with the DKIM checker and your policy with the DMARC checker. The email authentication guide explains how the three fit together, and DNS records for email covers where each one lives.