Defaults.Exposed › Pembaikan › Guides
"SPF Record Not Found" — But You Have One? The 5 Real Causes (2026)
Diterbitkan 2026-07-08
Figures as of 2026-06-29 · methodology v7. Aggregate census data across 261 million graded domains. See how we grade.
If a checker says “SPF record not found” but you’re sure you published one, the record is usually invisible rather than missing: 1,013,416 domains — about one in 138 of those that attempt SPF — publish two or more SPF records, a PermError (RFC 7208 §3.2) that many checkers report as not-found, according to the Defaults.Exposed census of 261 million domains.
There are five real causes, all fixable in one sitting: wrong host, duplicate record, wrong DNS type or mangled quoting, inconsistent nameservers, or a length/CNAME collision. Below: the 60-second test for each, in the order to check them, then the fix steps.
Are you sure the record actually exists?
Start with the unflattering possibility, because it is the most common one by far: of the 261,086,232 domains graded in the Defaults.Exposed census, 121,145,609 — 46.4% — have no SPF record at all. Plenty of “but I set this up” cases turn out to be a record added to a staging zone or an old DNS provider that is no longer authoritative. Check the DNS provider your nameservers actually point at (often not your registrar) for a TXT record starting v=spf1. If it genuinely isn’t there, skip the detective work and go straight to fix your SPF record.
How do you check an SPF record properly?
Web checkers query DNS through their own caching resolver. To see the truth, ask your domain’s authoritative nameserver directly:
# find the authoritative nameservers
dig NS yourdomain.com +short
# ask one of them directly for TXT records
dig TXT yourdomain.com @ns1.yourdnshost.com +short
On Windows: nslookup -type=TXT yourdomain.com ns1.yourdnshost.com.
Two rules of interpretation. First, count the lines starting v=spf1 — the count matters as much as the content. Second, check you queried the right name: receivers evaluate SPF against the domain in the Return-Path (RFC5321.MailFrom, the “envelope from”) — not the From address recipients see. If your newsletter tool bounces mail via bounce.yourdomain.com, a perfect record at the apex isn’t the record receivers look up.
What are the five real causes?
| # | Cause | The 60-second test | The fix |
|---|---|---|---|
| 1 | Record at the wrong host (subdomain vs apex) | dig TXT the exact domain in your Return-Path | Publish at the name that actually sends |
| 2 | Two or more v=spf1 records = PermError | dig TXT returns 2+ v=spf1 lines | Merge into exactly one record |
| 3 | Published as record type 99, or mangled quoting | Check the record type and stray quote marks | Republish as one clean TXT record |
| 4 | Stale caches / inconsistent nameservers | Query each NS directly; compare answers | Fix the lagging nameserver, wait out the old TTL |
| 5 | >255-character splitting or a CNAME conflict | Look for broken string chunks or a CNAME at the same name | Let the provider split strings correctly; move the record off the CNAME’d name |
Data as of 2026-06-29.
1. Is the record at the wrong host?
The classic: SPF added at mail.yourdomain.com when mail claims to come from yourdomain.com, or vice versa. SPF does not inherit downwards — a record at the apex says nothing about subdomains, and vice versa. Publish at exactly the name in your Return-Path. A vendor sending from its own bounce subdomain needs a record on that subdomain — usually a CNAME or TXT the vendor supplies (the GoDaddy SPF setup guide shows where these fields live).
2. Do you have two SPF records?
The headline cause, and the most misleading error message in email authentication. RFC 7208 §3.2 is blunt: a domain must have exactly one SPF record. Two or more is a PermError — receivers treat your SPF as void. Some checkers report that state accurately (“multiple records found”); others report the net effect: no valid SPF record found. You see a record in your panel and conclude the checker is broken. It isn’t — you have one record too many.
The census found 1,013,416 domains carrying two or more SPF records — about one in 138 of the domains that attempt SPF — every one with SPF effectively switched off. It usually happens during a provider change: the new provider’s wizard adds a fresh record instead of editing the old one. The fix is a merge, never a second record: combine everything into a single v=spf1 … ~all line and delete the rest. Our data report two SPF records equals none breaks down how a million domains got here; if it started after a migration, see SPF stopped working after switching provider. While merging, don’t blindly concatenate every include: — each costs DNS lookups against SPF’s hard limit of 10, trading not-found for a PermError: too many DNS lookups.
3. Did you publish the wrong record type — or did the UI mangle it?
Early SPF had its own DNS record type (type 99, literally named “SPF”). It was deprecated: RFC 7208 requires TXT, and receivers do not query type 99. Some DNS panels still offer “SPF” in the record-type dropdown; choose it and your record is real, well-formed, and invisible. Check the type column and republish as TXT.
The subtler sibling is quoting. Pasting a value wrapped in quotes into a field that adds its own quotes produces ""v=spf1 …"" — which no longer starts with v=spf1, so to a verifier it doesn’t exist. Your dig output shows the truth; the DNS panel often cosmetically hides it.
4. Is it really “still propagating”?
“Give it 24–48 hours to propagate” is the most over-prescribed advice in DNS. Propagation is just caches expiring: once the record’s TTL has elapsed (typically 1 hour, rarely more than 24), every resolver can see the new answer. Still not-found after 24 hours? Propagation is not the cause.
The two real culprits: negative caching — a resolver that looked you up before you added the record caches the “no such record” answer until the negative TTL expires — and inconsistent nameservers after a migration, where the domain still lists the old provider’s nameservers alongside the new ones and half the world reads a zone you no longer edit. Query each listed nameserver directly; if the answers differ, you’ve found it. Fix the registrar’s NS delegation so only the provider you actually edit is authoritative.
5. Is the record too long, or blocked by a CNAME?
A single string in a TXT record maxes out at 255 characters. Longer SPF records are legal but must be split into multiple quoted strings within one record — and DNS provider interfaces regularly botch the split, truncating the value or breaking it mid-mechanism so it no longer parses. If your record is long, check the dig output for a value that ends abruptly.
Separately, DNS forbids a TXT record at a name that already has a CNAME. If mail.yourdomain.com is a CNAME to your provider, you cannot also put SPF there — some panels accept it and then serve only the CNAME. Put the record where the CNAME points (if you control it), or restructure so the sending name isn’t CNAME’d. Providers with clean TXT handling make both easier — see the Cloudflare SPF setup guide.
How do you fix it, step by step?
- Run the free scan at defaults.exposed — it reads your live DNS and tells you which of the five states you’re in before you touch anything.
- Confirm which nameservers are authoritative (
dig NS) and that they all agree. - Query TXT at the authoritative nameserver for the exact Return-Path domain.
- Count the
v=spf1lines: zero → publish one; two or more → merge to one. - Verify the type is TXT, the value starts exactly with
v=spf1, and no stray quotes or truncation crept in. - Wait out one TTL, then re-scan to confirm it resolves cleanly everywhere.
Frequently asked questions
Why does the checker say “not found” when I can see the record in my DNS panel?
Usually cause 2 or 4: a second v=spf1 record makes both void — a PermError some tools report as not-found, the state 1,013,416 domains are in as of 2026-06-29 — or your panel isn’t the DNS that’s actually authoritative.
How long until checkers see my fix? One TTL — typically an hour, at most 24. Beyond that, “propagation” is not the explanation; recheck the five causes, starting with nameserver consistency.
Should I use the “SPF” record type my DNS panel offers? No. Type 99 is deprecated; RFC 7208 requires TXT only. A type-99 record is invisible to modern receivers.
The record is found now — why does my mail still fail SPF? Because SPF is checked against the Return-Path domain, not the From header, and the record must actually list the servers that send for you. Found is step one; the fix your SPF record guide covers passing.
Is having no SPF record really that common? Yes — 121,145,609 domains, 46.4% of the 261,086,232 graded in the Defaults.Exposed census (as of 2026-06-29), publish no SPF at all. Not-found is the internet’s default state.
Send the owner the report
Once the record resolves cleanly, re-run the scan and forward the graded report to the business owner or client whose domain this is. It shows, in plain English, what was broken, what you fixed, and where the domain now stands — exactly the evidence they’ll be asked for on cyber-insurance renewals and supplier security questionnaires. The report is the receipt for the work.
Check your SPF record free
See which of the five not-found states your domain is in — privately and owner-only.
Check your domain → · Fix SPF → · SPF broke after switching provider → · How we grade → · Aggregate data only. Data stored and processed in the EU.