Free SPF Record Checker
Enter a domain above and the SPF checker fetches its TXT records, finds the one that starts with v=spf1, expands every include: it points at, and reports whether the result is valid. Below is how to read what it gives back, what the common failures actually mean, and how to run the same check yourself from a terminal.
How to Read Your SPF Record
An SPF record is a single line of DNS text. Here is a live one, the record google.com publishes for itself:
v=spf1 include:_spf.google.com ~all
Three parts, and every SPF record has the same shape. v=spf1 is the version tag and must be first. In the middle come the mechanisms that say who is allowed to send. At the end comes the all mechanism, which decides what happens to everyone else. That last token is the one people get wrong.
| Token | What it does |
|---|---|
v=spf1 | Version tag. Must be the first token, and a record without it is not an SPF record. |
ip4: / ip6: | Authorises a literal address or CIDR range. Costs no DNS lookup. |
include: | Pulls in another domain’s SPF record. Costs one DNS lookup each, and so does everything inside it. |
a / mx | Authorises the domain’s own A or MX hosts. One lookup each. |
~all | Softfail. Everyone else is unauthorised, but deliver anyway and mark it. The common choice. |
-all | Hardfail. Everyone else is unauthorised, reject. Correct only once you are certain the record is complete. |
?all | Neutral. Says nothing, which is close to publishing no record at all. |
+all | Authorises the entire internet. Almost always a mistake, and worse than having no SPF record. |
The difference between the two safe endings is visible in the wild. Google ends its own record with ~all. Microsoft’s shared include, spf.protection.outlook.com, ends with -all:
v=spf1 ip4:40.92.0.0/15 ip4:40.107.0.0/16 ip4:52.100.0.0/15 ip4:52.102.0.0/16
ip4:52.103.0.0/17 ip4:104.47.0.0/17 ip6:2a01:111:f400::/48
ip6:2a01:111:f403::/49 ip6:2a01:111:f403:8000::/51
ip6:2a01:111:f403:c000::/51 ip6:2a01:111:f403:f000::/52 -allNeither is wrong. A hardfail is stricter and only safe when nothing sends on your behalf that is missing from the record. Full syntax, with every mechanism and modifier, is in the SPF record reference with syntax and examples.
The Ten Lookup Limit, Which Is What Usually Breaks
SPF evaluation is capped at ten DNS lookups. Exceed it and the result is permerror, which receivers treat as a failure even though your record looks perfectly correct. This is the single most common reason a domain that “has SPF” still fails SPF, and it is the failure a checker exists to catch, because you cannot see it by reading your own record.
The cap counts lookups across the whole expansion, not just the ones you typed. include:, a, mx, ptr and exists each cost one, and every include: inherits the cost of whatever is inside it. ip4: and ip6: cost nothing, which is why flattened records survive.
Follow one real chain to see how fast it adds up. google.com publishes a single include:, which looks like one lookup:
$ dig +short TXT google.com
v=spf1 include:_spf.google.com ~all
$ dig +short TXT _spf.google.com
v=spf1 ip4:74.125.0.0/16 ip4:209.85.128.0/17 ip6:2001:4860:4864::/56
ip6:2404:6800:4864::/56 ip6:2607:f8b0:4864::/56 ip6:2800:3f0:4864::/56
ip6:2a00:1450:4864::/56 ip6:2c0f:fb50:4864::/56 ~allThat one resolves in two lookups because the second record is all literal addresses and stops there. Many vendor includes do not: they chain into two or three more includes of their own. Add a marketing platform, a helpdesk, an invoicing tool and a transactional sender, each with a nested include, and a record with five entries in it can cost twelve lookups. The fix is to stop adding and start restructuring, which is covered in when to flatten an SPF record and when to restructure instead. Flattening trades a maintenance problem for a lookup problem, so it is worth reading before doing.
What the Checker Flags, and What Each Result Means
| Result | What it means | What to do |
|---|---|---|
| No SPF record | The domain publishes no v=spf1 TXT record. | Publish one. Until you do, receivers have nothing to check and DMARC cannot pass on SPF. |
| Two or more SPF records | A second v=spf1 record exists, usually added when a new sender was onboarded. | Merge them into one. Two records is a permerror: receivers do not pick the better one, they fail both. |
| Too many DNS lookups | Expansion exceeded ten. The record is syntactically fine and still fails. | Remove senders you no longer use, then restructure or flatten. |
| permerror | A permanent error: bad syntax, the lookup cap, or duplicate records. | Treat as a hard failure. Nothing improves until it is resolved. |
| temperror | A transient DNS failure during evaluation. | Re-run. If it persists, the problem is in DNS rather than in the record. |
Record ends in +all | Every host on the internet is authorised to send as you. | Change it today. This is worse than publishing nothing. |
| Record longer than 255 characters in one string | A single TXT string cannot exceed 255 characters; longer records must be split into multiple strings that get concatenated. | Most DNS hosts handle the split. If yours does not, the record will not parse. |
When a real message is rejected rather than merely marked, the bounce usually names the cause. Two of the common ones are documented here: 550 SPF sender invalid, envelope rejected and 451 grey bounce on SPF failure or no record.
How to Check SPF Without a Tool
An SPF record is a TXT record, so any DNS client will show it. This is worth knowing because it is the only way to see exactly what your resolver sees, with no vendor interpretation in between.
$ dig +short TXT smtpedia.com v=spf1 include:spf.privateemail.com ~all $ nslookup -type=txt smtpedia.com $ host -t TXT smtpedia.com
Domains publish several TXT records, so filter for the line beginning v=spf1 and ignore the verification strings from Google, Microsoft and everyone else. If you see two lines starting v=spf1, you have found your problem without needing any tool at all.
What the command line will not do is count the expansion for you. That is the part worth using the checker above for, and the reason a manual read of your own record is not sufficient. The same commands applied to MX records are in the MX record lookup guide.
What an SPF Check Cannot Tell You
A passing SPF check is a narrower statement than it looks, and reading too much into it is how domains end up thinking they are protected when they are not.
SPF validates the Return-Path domain. The address your recipient actually sees is the header From, and SPF never looks at it. That gap is what DMARC alignment exists to close.
A forwarded message arrives from the forwarder’s server, which your record does not list, so SPF fails legitimately. This is why DKIM matters and why aliases and forwarding behave differently.
An attacker who registers a look-alike domain publishes their own SPF and passes cleanly. SPF answers who sent this, never whether it is safe.
The three standards are meant to be read together: SPF authorises the sending host, DKIM signs the message itself, and DMARC ties either one back to the visible From domain and tells receivers what to do on failure. The last point in the panel above is expanded in why most phishing now authenticates cleanly.
Checking SPF for Google Workspace and Microsoft 365
Both platforms hand you an include: rather than a list of addresses, which keeps your record short and keeps the addresses current without your involvement. What you are checking is that the include is present, spelled correctly, and sitting in a single record alongside your other senders rather than in a second record of its own.
A frequent mistake on both: adding the platform’s include while an older host’s include is still in place, then adding a marketing tool, and crossing the lookup cap without any single step looking unreasonable. Run the check after every sender you add, not once at setup. Client-side settings for the two platforms are in the Google Workspace mail server reference and the Microsoft 365 mail server reference.
SPF Checker FAQ
How do I check my SPF record?
Enter your domain in the checker at the top of this page. It reads the TXT records, isolates the one starting v=spf1, expands every include and counts the DNS lookups against the limit of ten. To do it manually, run dig +short TXT yourdomain.com and read the line beginning v=spf1. The manual route shows you the record; it does not count the expansion.
How can I tell whether an SPF record is valid?
A valid record starts with v=spf1, appears exactly once on the domain, ends with an all mechanism, and expands within ten DNS lookups. Any one of those four failing produces a permerror, and receivers treat a permerror as a failure. A record can read perfectly and still be invalid because of the lookup count, which is the case a checker catches and a manual read does not.
Is there a free tool that can flatten SPF records?
Flattening replaces your include: entries with the literal ip4: and ip6: ranges behind them, which removes the lookups. It also freezes those addresses: when your provider changes an IP range, your record no longer matches and mail starts failing silently. That is why flattening is a maintenance commitment rather than a one-time fix, and why the sequence matters. When to flatten and when to restructure instead sets out both paths before you commit to either.
Can I have two SPF records on one domain?
No. RFC 7208 permits exactly one. Two records is a permanent error, and receivers do not choose the more permissive one, they fail the evaluation. If you need to authorise an additional sender, merge its include: into the record you already have. This is the most common error the checker reports, because publishing a second record is what most setup guides implicitly tell you to do.
Should my record end in ~all or -all?
Start with ~all. Move to -all only once DMARC reports have shown you every source that sends on your behalf and you have confirmed each one is in the record. A hardfail on an incomplete record rejects your own legitimate mail. Google ends its own record with ~all; Microsoft’s shared include ends with -all. Both are defensible, and the difference is confidence in completeness rather than security posture.
My SPF passes but mail still lands in spam. Why?
SPF is one input among many, and passing it is the baseline rather than the goal. Reputation, content, list quality, DKIM and DMARC alignment all weigh in. Start with the common reasons mail is filtered, and check that your DMARC alignment is passing rather than only your raw SPF result.
Related Free Tools
SPF Record Generator to build a record from scratch · DKIM Record Checker · DMARC Record Checker · DKIM Record Generator · DMARC Record Generator
