SPF Record Not Found? Fix Your Email Authentication

Quick Answer: "SPF record not found" means a receiving mail server checked your domain's DNS and found no valid TXT record starting with v=spf1. Fix it by publishing one SPF TXT record on your root domain that lists every service allowed to send mail for you, keeping it under the 10 DNS-lookup limit, then waiting up to a few hours for DNS to propagate. As of July 2026, this is the top reason legitimate email lands in spam.

You sent a test email, ran your domain through a checker, and got hit with "spf record not found." Your stomach drops, because you know what tends to follow: messages sliding into spam, or bouncing outright. Take a breath. This is one of the most fixable email problems there is, and you can usually sort it yourself in about ten minutes.

In the tickets we handle every day, somewhere between 20 and 30 of them, a missing or broken SPF record is one of the deliverability complaints that comes up most. Usually the cause is dull: the record was never added, or it's sitting on the wrong domain. This guide walks the fix from the fastest check down to the trickier edge cases, with the exact records and commands you'll need.

One thing to know before you touch anything. SPF (Sender Policy Framework) is a single TXT record in your DNS that tells receiving servers which machines are allowed to send email using your domain name. On a well-run stack like Hostaccent's, those sending IPs are documented up front, so the record is quick to build. When it's missing, malformed, or hiding on a subdomain, receivers can't verify you, and your sender reputation takes the hit. A quick primer on what a TXT record is helps if DNS is new to you.

What SPF Record Not Found Actually Means

An "SPF record not found" result means that when a receiving server (Gmail, Outlook, Yahoo) looked up your domain's DNS for an SPF policy, it came back empty. No TXT record beginning with v=spf1 existed at the name it queried. The receiver then has no list of approved senders to check your mail against, so it treats the message as unverified, and every domain should have exactly one such record.

Think of SPF as a guest list posted at your domain's front door. When Gmail receives a message claiming to be from [email protected], it reads that list to confirm the sending server was invited. No list, no confirmation. The message still arrives sometimes, but with a black mark that pushes it toward the junk folder or a rejection.

Here's the part that trips people up: "not found" is not the same as "failed." A fail means the record exists but the sending server wasn't on it. "Not found" means there was no list to read at all. That distinction changes the fix. A fail is usually a missing include: or IP; "not found" is almost always a publishing or location problem.

SPF is also one of three email-authentication layers, and it helps to know where it sits. SPF says which servers may send for you. DKIM adds a cryptographic signature proving the message wasn't altered in transit. DMARC ties the two together and tells receivers what to do when a check fails. Because DMARC leans on SPF passing, SPF is the right layer to fix first. Cloudflare's overview of SPF is a solid primer if you want the background.

SPF has mattered more since early 2024, when Google and Yahoo began requiring authenticated mail from anyone sending more than 5,000 messages a day. A domain with no SPF record now fails that bar on day one. The upside: because SPF is just one DNS record, fixing it is far quicker than most email problems. You're editing a text string, not rebuilding a mail server.

The Real Causes, Ranked by How Often We See Them

Nine times out of ten, this error traces to one of five causes: no record was ever published, the record sits on a subdomain instead of the root, the domain carries two competing SPF records, the record uses a deprecated SPF record type instead of TXT, or DNS simply hasn't propagated yet. As of July 2026, a record that was never published is still the runaway leader.

The ranked breakdown from what actually lands in our queue:

1. No record exists. The domain was set up for email but nobody ever added SPF. Most common by a wide margin.
2. Wrong domain or subdomain. The record is published at mail.yourdomain.com while the checker (and receivers) look at the root yourdomain.com. Common with newsletters and custom sending domains.
3. Two SPF records. RFC 7208 allows exactly one. If two v=spf1 records exist, many receivers give up and treat SPF as broken.
4. Legacy record type. The record was published as an old "SPF" DNS type (type 99) instead of a TXT record. Modern tools only read TXT, so they report nothing found.
5. Propagation delay. You added it correctly five minutes ago. DNS just hasn't caught up.

The reason the ranking matters: if you start flattening includes or rewriting mechanisms before checking whether a record exists at all, you'll burn an afternoon on a problem you don't have. Work top-down.

From the Ticket Queue: According to Hostaccent's own support-queue data (July 2026), WordPress issues make up about 30% of monthly tickets and SSL-related problems about 20%. Email-deliverability complaints, with SPF gaps the usual suspect, cut across both of those buckets.

On our own stack, we document the exact include: or ip4: mechanism each customer needs, so the record is copy-and-paste rather than guesswork. That single habit heads off most "not found" tickets before they start. Deliverability is downstream of a dozen small settings, which is also why WordPress emails going to spam so often trace back to SPF and DNS rather than the message content itself.

The 60-Second SPF Triage (our support shortcut): Before editing anything, answer three questions. (1) Are you checking the root domain, not a subdomain? (2) Does the domain have exactly one record starting with v=spf1? (3) Is it a TXT record, not a legacy SPF type? Ninety percent of "not found" cases fail one of these three, and none of them require touching your mail server.

How to Add an SPF Record (Step by Step)

If the triage points to a missing record, adding an SPF record cleanly comes down to one TXT record published at your root domain. The whole job takes about five minutes of editing plus propagation time, and it works the same way at every DNS provider: list your senders, build one string, publish it as TXT.

Step 1: List every service that sends mail for you. Your web host, your mailbox provider (Google Workspace, Microsoft 365), and any third parties (a newsletter tool, a CRM, your app's transactional mail). Miss one and its mail starts failing later. If your host also runs your mailboxes, you may only need a single include: for that host plus your mailbox provider. Fewer mechanisms means fewer lookups and less to break.

Step 2: Build the record. SPF records are plain text and follow a set order. A domain sending through Google Workspace and one marketing tool might use:

bashCopy
v=spf1 include:_spf.google.com include:servers.mcsv.net ~all

The v=spf1 opens it. Each include: pulls in a provider's approved servers. The ~all at the end is a "softfail" telling receivers to accept-but-flag anything not listed. Use ~all while testing, then tighten to -all (hardfail) once you're confident every sender is covered.

Step 3: Publish it as a TXT record. In your DNS dashboard, create a new record: Type TXT, Name/Host @ (the root), Value the string above. Save.

Pro Tip: Never wrap your SPF value in extra quotation marks inside the DNS panel. Some editors add them automatically, and a stray " at the start breaks parsing, so the record reads as "not found" even though it's clearly sitting there. If a valid-looking record won't validate, check for rogue quotes first.

Step 4: Mind the 255-character limit. A single DNS TXT string is capped at 255 characters. A long SPF record has to be split into multiple quoted chunks that the resolver reassembles. Most panels handle this for you, but if you're editing a raw zone file, split at 255 or the record can read as malformed.

Step 5: Wait, then verify. DNS changes take anywhere from 15 minutes to 48 hours to propagate, though most panels push updates within 1 to 4 hours. Recheck with a lookup tool or the command line before assuming it failed.

Do I Add the SPF Record at My Host or My Registrar?

You add it wherever your domain's DNS is actually hosted, which is not always where you bought the name. If your nameservers point to your web host, edit DNS there. If they point to your registrar or to Cloudflare, edit it there instead. This split is a top cause of "I added it and nothing changed": the record went into a DNS zone that isn't live. When the domain and hosting sit under one roof, there's one dashboard and one place for the record to be, which removes an entire category of this mistake.

Live site and no time to experiment? Our engineers fix this exact error for a small one-time fee, and you'll see the precise quote before anyone touches your DNS. Hosted with Hostaccent already? Then a problem like this is simply covered by support at no charge. Have an engineer fix it.

When Your SPF Record Is Not Working: Subdomains, Custom MAIL FROM, and PermError

Sometimes the record is published and correct, yet you still see "SPF record not working" or an "SPF lookup failed" message. Three culprits cause most of these, and each has a clean fix, so work through them in order.

Subdomain and custom MAIL FROM mismatches. Bulk senders and some CRMs use a custom MAIL FROM domain like mail.yourdomain.com or em.yourdomain.com. SPF is checked against that domain, not your root. So the fix is to publish an SPF record at the subdomain your sender specifies, exactly as their setup docs describe. Your root record does not cover it automatically.

Too many DNS lookups (PermError). This is the sneaky one. Per RFC 7208, section 4.6.4, an SPF record may trigger at most 10 DNS lookups during evaluation. Every include:, a, mx, ptr, exists, and redirect counts, including the nested ones inside your providers' records. Add a fourth or fifth email service and you can quietly cross 10, at which point receivers return a PermError and DMARC treats it as a hard fail. An "SPF lookup failed" result usually points straight at this ceiling.

Insider Insight: There's a second, quieter limit almost nobody checks. RFC 7208 also caps void lookups (DNS queries that return nothing) at 2. A single dead include: pointing at a domain that no longer resolves can trip a PermError even while you're well under 10 real lookups. When a record looks fine but fails anyway, audit every include for one that's gone stale.

To get back under the limit, remove services you no longer use, replace lookup-heavy mechanisms with direct ip4:/ip6: ranges where a provider publishes them, and avoid ptr entirely (it's strongly discouraged in the spec and wastes a lookup). Flattening tools that expand includes into raw IPs work too, but they need re-checking whenever a provider changes its servers.

Multiple records. If two v=spf1 records exist, merge them into one by combining their include: and ip4: mechanisms, then delete the extra. One record, one all mechanism at the end.

How to Confirm the Fix and Stop It Coming Back

Once the record is live, confirm it from the receiver's side rather than trusting a single tool. Send one test message to a Gmail address, open it, choose "Show original," and read the Authentication-Results header: spf=pass means you're done, spf=none means receivers still find nothing, and spf=permerror means you've crossed the 10-lookup limit.

From the command line, a quick query confirms what's actually published:

bashCopy
dig TXT yourdomain.com +short

You should see one line beginning v=spf1. If you see none, the record isn't live where you think it is. If you see two, you have the duplicate problem from earlier.

Prevention is mostly discipline. Keep exactly one SPF record. Every time you add an email service, update that single record instead of creating a new one, and recount your lookups before saving. Providers change their SPF footprints over time, so a record that used 8 lookups last year can quietly hit 11 this year without you touching it. A quarterly recheck catches that drift. Once SPF passes, adding a DMARC record tells receivers what to do on a failure and gives you reporting, but SPF comes first because DMARC depends on it.

Pro Tip: Set a recurring calendar reminder to re-run an SPF check every three months, and always after adding or removing any tool that sends email. The failures that hurt most are the silent ones, where mail degrades slowly and you don't notice until a customer says "I never got your invoice."

Across the 4,000+ sites we've migrated as a UK-registered host (operating since 2012, incorporated 2018), mail records are the single thing most likely to arrive misconfigured, usually because they were edited in a DNS zone that went dark after a nameserver change. Confirming where your DNS lives is half the battle. If deliverability keeps slipping even after SPF passes, the cause may be broader hosting health: it's worth ruling out a slow origin with a WordPress slow-site diagnosis, checking whether you're brushing against shared hosting resource limits, confirming your server isn't dragging down Core Web Vitals, and looking at high TTFB in WordPress if pages feel laggy.

Your Next Step: Email That Actually Lands

Now that you know "spf record not found" is nearly always a publishing or location problem rather than a broken mail server, you've got two clean paths. Fixed it yourself? Keep the one-record discipline, re-check quarterly, and remember that on a well-run host this whole class of DNS-and-deliverability chore is support's job, not yours. That's the quiet case for hosting somewhere that documents your records for you. The Economy shared hosting plan at $1.99/mo (start on the Economy plan) runs on NVMe storage with a 99.9% uptime and a 30-day money-back guarantee, and putting your .com domain at $13.99/yr under the same dashboard means one DNS zone, not two places for a record to hide. One honest caveat: if you're running ten client sites, Standard suits you better than Economy. Still stuck? Open a ticket and Hostaccent's engineers will fix this exact error, one-time fee, quote first.

Frequently Asked Questions About SPF Records

Why does my domain still say "spf record not found" when I already added one?

Three things usually explain it. You published the record on a subdomain while receivers check the root domain; you added it as a legacy SPF record type instead of a TXT record, so modern tools skip it; or DNS simply hasn't propagated yet, which can take up to 48 hours. Run dig TXT yourdomain.com +short to see exactly what's live at the root, and confirm you edited DNS in the zone your nameservers actually point to.

How long does an SPF record take to work after I add it?

Usually between 15 minutes and a few hours, though the spec allows up to 48 hours for full global propagation. The delay depends on your DNS provider's TTL settings and how aggressively resolvers cache. Most modern panels push changes within 1 to 4 hours. Don't keep re-editing the record while you wait, since that resets the clock. Add it once, then verify with a lookup tool after an hour before assuming something went wrong.

Can I have more than one SPF record on the same domain?

No. RFC 7208 permits exactly one SPF TXT record per domain, and having two is a common reason SPF breaks. When receivers find multiple v=spf1 records, most treat the result as a permanent error and reject or flag your mail. If you need to authorize several email services, merge them into a single record using multiple include: mechanisms rather than creating separate records. One record, one v=spf1, one closing all mechanism.

What does "SPF PermError: too many DNS lookups" mean?

It means evaluating your SPF record requires more than the 10 DNS lookups that RFC 7208 allows. Each include:, a, mx, ptr, exists, and redirect counts, including the ones nested inside your providers' records, so four or five email services can quietly push you over. Receivers return a PermError and DMARC reads it as a fail. Fix it by removing unused services, swapping lookup-heavy mechanisms for direct IP ranges, and dropping ptr entirely.

Does a missing SPF record really send my email to spam?

Often, yes. Without SPF, a receiving server can't confirm that your sending machine is authorized, so it leans on other signals and frequently routes the message to spam or rejects it outright. Since 2024, Google and Yahoo require authentication for bulk senders, which raised the stakes further. In the deliverability tickets Hostaccent handles, a missing or broken SPF record is one of the most common root causes of mail that suddenly stops reaching inboxes.

How do I fix "SPF record not found" for a custom MAIL FROM domain?

Publish a separate SPF record at the exact subdomain your sending service uses for its MAIL FROM, such as mail.yourdomain.com or em.yourdomain.com. Your root domain's record does not automatically cover a subdomain. Check your provider's setup documentation for the precise host and value they expect, add it as a TXT record in your DNS, and verify against that subdomain specifically rather than the root. This is a frequent gap with newsletter and CRM platforms.

Do I still need an SPF record if I only send a few emails?

Yes. SPF protects any domain that sends mail, whether that's one message a week or thousands a day. Even low-volume senders get spoofed, and without SPF a scammer can forge your address more easily. Receivers also increasingly expect authentication regardless of volume, so a missing record can push even legitimate personal or small-business mail toward spam. Publishing one TXT record takes about five minutes and protects your domain's reputation for the long run.