No SPF record found: what the checker means and what to publish

Whether that red box is urgent depends on something the checker didn’t tell you: does your domain accept mail? If it has MX records and no SPF record, then any host putting your domain in the Return-Path of a message is a host nobody has authorised, and that’s true today, before you touch anything. If the domain has no MX, you’re looking at a parked-domain problem, which has its own page.

The words “No SPF record found” also cover two different states, a record that doesn’t exist and a record that’s published and invisible, and the fix paths don’t overlap. Settle those two facts first, because they decide what you publish.

Two states behind one message

A checker prints No SPF record found when its lookup came back with nothing that starts v=spf1. That happens when nothing is published at the name it queried, and it also happens when a record exists and evaluates to nothing: two records where there should be one, the wrong DNS type, mangled quotes, a stale nameserver. Both states produce the same red box, and the second one is why people who are sure they set SPF up last week end up on this page.

The onboarding screens of email tools say the same thing in their own words. If your screen read “your SPF records is currently set to nothing”, grammar and all, you’re in the same place: the tool asked DNS for a record at your domain and got nothing usable back.

The first state is the common one. Of the 316,600,902 domains carrying a grade in the September 2026 census, 166,497,698 (52.6%) publish no v=spf1 record at all. So before you go hunting for an invisible record, take the plain possibility seriously: the record you remember adding went into a staging zone, an old DNS provider that no longer answers for the domain, or a subdomain no mail is sent from.

Urgency turns on MX

SPF’s job is to name the hosts allowed to send mail with your domain in the Return-Path. With no record published, a receiver has no list to check against, and a message carrying your domain in its envelope from gets neither a pass nor a fail on SPF. If the domain is a working mailbox, that’s a state you want to leave quickly, because the same domain people reply to is the one a receiver has no way to vouch for.

Of the 316,600,902 domains carrying a grade in the September 2026 census, 173,282,307 (54.7%) publish MX records, meaning they accept mail. The census doesn’t break out how many of those also publish no SPF, so there’s no figure to quote for the overlap. What the two numbers together say is that neither state is rare, and you need to know which side of the split your domain sits on.

If the domain has no MX, mail sent to it goes nowhere, and the exposure is a different one: a web-only or parked name that anyone can put in a Return-Path with no owner watching. That case is worked through in parked domains get spoofed too, and the record it needs is different from the one below.

The other thing that decides the branch is a count. Ask DNS for TXT records at your domain and count the lines beginning v=spf1. Zero means you publish one. One means the record is present and the checker’s problem is elsewhere, usually the name it queried. Two or more means the records cancel each other and you merge them into one. The free scan reads your MX and your SPF from live DNS and tells you which of these you’re holding, the shortest way to know which branch to work.

Ask the authoritative nameserver directly

Web checkers query DNS through their own caching resolver, which may be holding an answer from before you made a change. The nameserver that holds your zone has the current value, so ask it directly:

dig NS yourdomain.com +short
dig TXT yourdomain.com @ns1.yourdnshost.com +short

On Windows, nslookup -type=TXT yourdomain.com ns1.yourdnshost.com does the same job. Replace the nameserver with one of the names the first command returned.

Then check that you asked about the right name. Receivers evaluate SPF against the domain in the Return-Path (RFC5321.MailFrom, the envelope from), and that is often a different name from the From address a recipient reads. If your newsletter tool bounces via bounce.yourdomain.com, a perfect record at the apex is a record receivers never look up for those messages.

SPF doesn’t inherit downwards. A record at the apex says nothing about a subdomain, and a record on a subdomain says nothing about the apex. Publish at exactly the name in the Return-Path, and if a vendor sends from its own bounce subdomain, that subdomain needs the record the vendor supplies.

Branch one: nothing is published

If the authoritative nameserver returns no v=spf1 line at the name in your Return-Path, publish one. The starter record for a domain that has never had one is:

v=spf1 include:<your provider's include> ~all

Put the include your mail provider documents in place of the placeholder, add a second include: for any tool that sends with your domain in the Return-Path, and leave ~all at the end. Softfail is the sane terminal qualifier for a first record. The case for moving to -all later is made on the SPF page, and it’s better made once the record has been live for a while and you’ve seen what it catches.

A receiver checking this record learns whether the connecting server is on your list for the Return-Path, and learns nothing about the From address the recipient reads, which is the field a forger cares about. The control that acts on the visible domain is DMARC, and it needs a working SPF or DKIM underneath it, which is why the DMARC page is where you go once this record resolves.

Branch two: a record exists and evaluates to nothing

If dig returns one or more v=spf1 lines and a checker still reports nothing, the record is failing in one of five ways. Work them in this order.

More than one v=spf1 line

RFC 7208 section 3.2 requires exactly one SPF record per name. Two or more is a PermError, and receivers treat the domain’s SPF as void. Some checkers report that state accurately as multiple records found; others report the net effect, which is no valid record, and that’s how you can see a record in your panel and be told it doesn’t exist. It usually happens during a provider change, when the new provider’s wizard adds a fresh record instead of editing the old one.

The fix is a merge into a single line, and a merge is different from concatenation. Each include: costs DNS lookups against the limit of ten, so pasting each mechanism from both records into one line can trade a not-found for a PermError of a different kind. Keep one v=spf1, one terminal qualifier and only the includes for providers that still send for you, then delete the other record.

Record type 99

Early SPF had its own DNS record type, type 99, literally named SPF, and some panels still offer it in the type dropdown. RFC 7208 requires TXT and receivers don’t query type 99, so a type-99 record is well formed and invisible at the same time. Check the type column and republish the same value as TXT.

Quotes inside quotes

Pasting an already-quoted value into a field that adds its own quotes produces a value that no longer starts with v=spf1, so to a verifier it doesn’t exist. DNS panels tend to hide this cosmetically. The dig output shows the stored value as it is, so look for a leading " inside the string.

Still not found after 24 hours

Propagation is caches expiring, and it takes one TTL, typically an hour and rarely more than 24. A record that’s still reported missing a day after you published it isn’t propagating; something else is wrong.

The two usual culprits are negative caching, where a resolver that looked the name up before the record existed holds the no-such-record answer until the negative TTL expires, and inconsistent nameservers after a migration, where the registrar still delegates to a zone nobody edits. Run the TXT query against each nameserver the NS lookup listed and compare the answers. If they differ, fix the delegation at the registrar so only the zone you edit is authoritative.

Over 255 characters, or a CNAME at the same name

A single TXT string maxes out at 255 characters. Longer records are legal, though they have to be split into multiple quoted strings inside one record, and panels regularly botch the split, truncating the value or breaking it mid-mechanism so it no longer parses. If your record is long, look at the dig output for a value that ends early.

DNS also forbids a TXT record at a name that already carries a CNAME. If the sending subdomain is a CNAME to your provider, you can’t also put SPF there; some panels accept the entry and then serve only the CNAME. Put the record where the CNAME points if you control that name, or send from a name that isn’t CNAMEd.

Wait one TTL, then look again

Once you’ve published or merged, resist the urge to re-run the checker straight away. Wait out one TTL, then query the authoritative nameserver again with the dig command above and confirm exactly one line beginning v=spf1 at the name in your Return-Path. When that holds, run the scan again. A record that resolves cleanly at the authoritative source and passes the scan is a record receivers will see as their caches turn over, and the red box goes with it.

Figures as of 5 September 2026, from the September 2026 edition of the defaults.exposed census. Census numbers move every month; the current values are on the census data page.