Free SPF record checker.
Type a domain and get its SPF record back with every mechanism explained, the DNS-lookup count against the limit of 10, and the exact problem if there is one. Built for people sending cold email from dedicated domains, where a broken SPF record is the difference between the inbox and the spam folder.
Privacy: this tool runs entirely in your browser. When you click Check, one DNS query for the domain you typed goes to Cloudflare's public DNS resolver (Google's as fallback). Nothing is stored, logged or sent to GrowthPal.
SPF at a glance
| Item | Value |
|---|---|
| Record type | One DNS TXT record at the domain root, starting v=spf1 |
| Records per domain | Exactly one. A second record does not extend the first, it invalidates both |
| DNS lookup limit | 10 lookup-causing terms per evaluation, plus a limit of 2 void lookups |
| What it authenticates | The envelope sender in the Return-Path, not the From address your recipient sees |
| Specification | RFC 7208, published April 2014, which obsoleted RFC 4408 |
What is an SPF record?
An SPF record is a DNS TXT record that lists the servers allowed to send email on behalf of your domain. Receiving servers read it on every message: they take the domain in the envelope sender, look up its SPF record, and check whether the connecting IP address is authorised by it.
That check happens before anything about your content matters. If the record is missing, receivers have nothing to verify against. If it is broken, they get a permanent error and treat it much the same way. Neither outcome bounces your mail by itself, but both remove a reason to trust it, and cold email has few reasons to spare.
For outbound specifically, SPF belongs on your dedicated sending domains and never on the primary domain your team uses for customer mail. That separation is the first rule of the infrastructure playbook, and it is why a sending domain's record is usually short: a small, known set of senders.
How to read your SPF check result
The checker returns four things, in the order they matter.
The record itself, exactly as published. If nothing comes back, no SPF record exists on that domain. If two or more come back, that is a permanent error on its own, and the tool says so before checking anything else.
The lookup count, shown as "n of 10 DNS lookups used". The terms that cost a lookup are include, a, mx, ptr, exists and redirect. ip4, ip6 and all cost nothing. Eight or above is flagged as close to the limit.
One honest limit worth knowing: that count covers the terms in your own record. It does not expand what those includes pull in behind them. A record showing 4 of 10 here can still fail in real evaluation, because a single provider include can carry three or four more lookups inside it. If you are anywhere near the limit, expand the includes before you trust the number.
The all mechanism, which is what receivers apply to any sender your record does not list. The table below covers what each one means.
The includes, listed so you can see which providers can currently send as you. A name you do not recognize is a name to remove.
What each SPF result means
| Result | What it means | What to do |
|---|---|---|
| pass | The connecting server is authorised by your record. | Nothing. This is the goal. |
| fail | Your record explicitly denies this sender. Produced by -all. | If it is your own mail failing, the sender is missing from the record. Add it. |
| softfail | Your record suspects but does not deny. Produced by ~all. | Fine as a transitional state. Move to -all once the sender list is complete. |
| neutral | Your record explicitly makes no assertion. Produced by ?all. | Replace it with ~all or -all. Neutral tells the receiver nothing. |
| none | No SPF record exists, or the domain does not resolve. | Publish a record. This is the weakest position available. |
| permerror | The record exists but cannot be evaluated: too many lookups, two records, or a syntax error. | Treat as urgent. Receivers behave much as they would with no record at all. Causes below. |
| temperror | A transient DNS failure during evaluation. | Usually not yours to fix. Re-check later; if it persists, look at your DNS provider. |
What causes a permerror
| Cause | Why it breaks | Fix |
|---|---|---|
| More than 10 lookup-causing terms | RFC 7208 caps DNS-querying terms at 10 per evaluation. Receivers stop and return permerror. | Delegate or flatten. Steps below. |
Two or more records starting v=spf1 | A domain must publish exactly one. Receivers cannot choose between them, so they fail. | Merge every sender into one record with a single all at the end. |
| More than two void lookups | A void lookup returns no records or NXDOMAIN. The spec limits these to two. | Remove includes for services that no longer exist. |
An mx term resolving to more than 10 address records | Each mx evaluation is capped at 10 address lookups of its own. | Replace mx with explicit ip4 terms, or shrink the MX set. |
| An unknown or malformed term | Anything the parser cannot recognize invalidates the whole record. | Look for stray characters, smart quotes from a copy-paste, or a missing colon. |
A record not starting with v=spf1 | Without the version tag it is not an SPF record at all, so the domain reads as having none. | Make v=spf1 the first token, with no leading space. |
One more worth knowing: the ptr mechanism is still valid but RFC 7208 says it SHOULD NOT be used. It is slow, it is unreliable, and some receivers skip it entirely.
How to fix an SPF record that is over the 10-lookup limit
Flattening means replacing an include with the IP addresses it currently resolves to. It works, and it carries a maintenance cost: when the provider changes its addresses, your record is wrong and nobody tells you. Do it deliberately, and in this order.
- Count what you actually spend. Expand every include, not just the top level. A record with five includes routinely costs more than ten lookups once the nesting is resolved.
- Delete what no longer sends. The fastest win, every time. Old CRMs, retired help desks and trial accounts from two years ago are usually still sitting in there.
- Delegate a sender to a subdomain. Move a lookup-hungry provider onto its own subdomain with its own record, and the parent domain stops paying for it. This is the cleanest fix and it needs no ongoing maintenance.
- Flatten what is left, one provider at a time. Replace an include with the
ip4andip6terms it resolves to today: before: v=spf1 include:_spf.example-provider.com include:_spf.google.com ~all after: v=spf1 ip4:192.0.2.0/24 ip4:198.51.100.16/28 include:_spf.google.com ~all Those addresses are documentation ranges from RFC 5737, used here so nobody copies a real block by accident. Use whatever your provider actually publishes. - Put a reminder in the calendar. A flattened record needs re-checking quarterly. That is the running cost of step 4, and the reason step 3 is better wherever it is available.
- Re-check. Run the domain through this tool again and confirm the count is back inside 10.
Common questions about SPF
Why does my SPF record fail when it has more than 10 DNS lookups?
SPF allows ten DNS-querying mechanisms per evaluation. include, a, mx, ptr, exists and redirect each spend one; ip4, ip6 and all spend none. Go past ten and receivers return permerror and treat the record as if it were not there. Nested includes are the usual cause: one provider include can pull in three or four more behind it.
Does SPF check the address my prospect actually sees?
No. SPF validates the envelope sender in the Return-Path, which your sending platform sets. The From address your prospect reads is a different field and SPF never looks at it. Closing that gap is what DMARC alignment is for, and it is why passing SPF alone is not enough.
Should my sending domains end in ~all or -all?
Use -all once you are certain every legitimate sender is listed. ~all is the safer default while you are still finding strays. On a dedicated cold email sending domain the list of senders is short and known, so -all is usually right from the first day.
Does SPF stop someone spoofing my domain?
Not on its own. SPF authenticates the envelope sender, which your recipient never sees, so a forger can pass SPF on a domain they control while displaying yours in the From line. DMARC is the part that requires the visible domain to align with an authenticated one, which is why the three records are published together.
How long does an SPF change take to take effect?
As long as your record's TTL, usually somewhere between five minutes and an hour. Receivers cache the old value until it expires, so a fix is not live the moment you save it in your DNS panel. Lower the TTL ahead of a planned change if the timing matters.
My SPF passes but mail still lands in spam. What now?
SPF is a pass/fail gate, not a reputation score. Clearing it means you are allowed to send, not that you are trusted. Check DKIM and DMARC next, then look at domain age, warmup pace, bounce rate and reply engagement. Authentication is the floor, never the ceiling.
Tools check the plumbing. The message is what your market answers. Get your TAM mapped, your ICP broken down and 5 angles written for your buyers, free.