How to Fix SPF Failure in Cold Email (Step-by-Step)
An SPF failure is one of the fastest ways to land cold email in spam, and it is also one of the most common authentication problems we see when we audit a sending setup. SPF (Sender Policy Framework) tells receiving servers which machines are allowed to send email for your domain. When it fails, mailbox providers can treat your messages as unauthenticated, which drags down deliverability and can sink an otherwise well-built campaign.
The good news is that SPF failure is fixable, usually in under an hour once you know what broke. This guide walks through what an SPF record is, why it fails, how to diagnose it from the email headers, and a step-by-step fix that gets you back to spf=pass.
What an SPF record is (quickly)
An SPF record is a single DNS TXT record on your domain that lists which servers are allowed to send email on your behalf. When a receiving mail server gets a message claiming to be from your domain, it looks up your SPF record and checks whether the sending server is on the approved list. If it is, SPF passes. If it is not, SPF fails or soft-fails.
A basic record looks like this:
``` v=spf1 include:_spf.google.com ~all ```
That says: this is SPF version 1 (v=spf1), authorize the servers in Google's SPF record (include:_spf.google.com), and soft-fail anything else (~all). The pieces after v=spf1 are called mechanisms. Common ones are include: (pull in another domain's authorized servers), a (the domain's A record), mx (the domain's mail servers), ip4: and ip6: (specific IP addresses), and the all qualifier at the end, which sets the default for everything not explicitly listed. A tilde (~all) means softfail, a hyphen (-all) means hardfail.
One rule matters above all: a domain must have exactly one SPF record. Two SPF records on the same domain is itself an error.
Why SPF fails
SPF failures almost always trace back to one of a handful of causes. Knowing which one you are dealing with is most of the fix.
The first and most common is exceeding the 10 DNS lookup limit. SPF allows a maximum of 10 DNS lookups when it evaluates your record, and certain mechanisms, especially include: and a and mx, each trigger lookups, sometimes several nested ones. Add too many sending tools and you blow past 10, which causes a permerror, a hard SPF failure regardless of whether the actual sender was legitimate.
The second is having multiple SPF records on one domain. Because a domain must have exactly one SPF record, a second one, often added by accident when a new tool's setup guide says to "add this TXT record", invalidates the lot. The third is missing includes: you started sending through a new ESP or cold email tool but never added its include to your record, so its servers are not authorized. The fourth is plain syntax errors, a typo, a missing colon, the wrong qualifier. The fifth is forwarding: when mail is forwarded, the forwarding server sends from its own IP, which is not in your SPF record, so SPF breaks on the forwarded hop.
How to diagnose an SPF failure
Before you change anything, find out exactly how SPF is failing, because the fix differs by cause. The fastest source of truth is the email headers of a message that failed.
Open a received test message and view its original or raw headers. Look for the Authentication-Results line. It will show one of a few states. spf=pass means SPF is working. spf=fail means the sending server was explicitly not authorized (often a hardfail from -all). spf=softfail means it was not authorized but you used ~all, so it is a soft warning. spf=permerror is the one that signals a broken record, most often the 10-lookup limit was exceeded or there are multiple records or a syntax error. spf=none means there is no SPF record at all.
Then confirm with an SPF checker tool. Plenty of free ones let you enter your domain and see your parsed record, your total lookup count, and any errors. The lookup count is the number to watch: if it is at or near 10, that is almost certainly your problem. The checker will also flag multiple records and syntax issues that are hard to spot by eye.
How to fix it step by step
Once you know the cause, the fix is methodical. Work through these in order.
- Find your current SPF record. Use an SPF checker or query your domain's TXT records directly. Confirm what is actually published right now, not what you think is published. Note every mechanism and the total lookup count.
- List every service that sends email for you and add the right include. Write down each tool that sends on your behalf: your main ESP or mailbox provider, any cold email platform, transactional senders, marketing tools, helpdesks. For each one, find its required SPF include from its documentation and make sure it is present in your record. A missing include is a guaranteed failure for that sender.
- Flatten or consolidate to stay under 10 lookups. If you are at or over the 10-lookup limit, reduce it. Remove includes for tools you no longer use. Where appropriate, replace lookup-heavy mechanisms with the specific ip4: or ip6: addresses they resolve to, which count as zero additional lookups. This is called flattening. Be careful: flattened IPs can change, so only flatten sources whose IPs are stable, or use a maintained flattening service.
- Keep only one SPF record. Merge everything into a single TXT record that starts with v=spf1 and ends with one all qualifier. If you find two SPF records, combine their mechanisms into one and delete the extra. Never publish a second v=spf1 record.
- Publish the TXT record and wait for DNS. Save the corrected single record in your DNS settings as a TXT record on the root domain. DNS changes are not instant, allow time for propagation, which can range from minutes to a few hours depending on your TTL.
- Re-test and confirm spf=pass. Send a fresh test email after propagation and check the headers again. You want spf=pass and a lookup count comfortably under 10. Re-run the SPF checker to confirm no errors remain.
Work through those six steps and the vast majority of SPF failures resolve cleanly. The two that catch people out are the lookup limit (step 3) and the single-record rule (step 4), so give those the most attention.
SPF, DKIM, and DMARC work together
SPF is one of three layers, and fixing it in isolation only gets you part of the way. SPF authorizes sending servers. DKIM (DomainKeys Identified Mail) adds a cryptographic signature to each message so the receiver can verify it was not tampered with in transit and that it genuinely came from your domain. DMARC sits on top and tells receivers what to do when a message fails authentication, using SPF and DKIM alignment to decide.
The point is that these three reinforce each other. A passing SPF record with no DKIM and no DMARC is a weak setup, and modern mailbox providers increasingly expect all three to be in place for cold senders. If you are fixing SPF, fix it as part of getting all three configured and aligned, not as a one-off patch. Otherwise you solve one failure and leave the door open to others.
Where LeadHaste fits
Most SPF failures we see are not isolated mistakes, they are a symptom of sending infrastructure that was assembled piecemeal and never monitored. A tool gets added here, a record gets duplicated there, the lookup count creeps past 10, and one day deliverability quietly collapses.
We set up and monitor the full sending infrastructure for the outbound systems we run: SPF, DKIM, DMARC, and the warm-up that builds and protects sender reputation over time. It is configured correctly from the start and watched continuously, so a stray include or a forgotten record never reaches your campaigns. And because we believe in ownership, all of it is built in your name. You own the domains, the mailboxes, the records, and the warmed reputation, so if you ever leave, the infrastructure goes with you.
If you want to go deeper on deliverability and the technical pieces behind landing in the inbox, our resources cover the fundamentals, and the blog has more on cold email infrastructure. For the full picture of how we build and run it, see our services page.
Ready to stop fighting deliverability problems?
SPF failure is one of a dozen ways a sending setup can quietly break, and chasing each one manually is a losing game, so we build and monitor the entire infrastructure for you, owned by you and tuned to land in the inbox.
Frequently Asked Questions
A strong positive reply rate for B2B cold email is 1.5–3%. Top-performing campaigns with tight targeting and personalized copy can hit 4–5%. If you're below 1%, it usually signals a deliverability or messaging problem — not a volume problem.
The safe range is 30–50 emails per inbox per day for warmed inboxes. That's why outbound systems use multiple inboxes (we use 80) — to reach 40,000+ monthly sends while keeping each inbox well within safe limits. Sending more than 50/day from a single inbox risks spam folder placement.
Yes. The CAN-SPAM Act permits unsolicited commercial email as long as you include a physical address, an unsubscribe mechanism, accurate headers, and non-deceptive subject lines. Unlike GDPR in Europe, the US does not require prior opt-in consent for B2B cold outreach.
Domain warm-up typically takes 2–3 weeks. During this period, sending volume gradually increases while the email warm-up tool generates positive engagement signals (opens, replies) to build sender reputation. Skipping or rushing warm-up is the most common cause of deliverability problems.
Cold email is targeted, relevant outreach to a specific person based on their role, industry, or company — with a clear business reason. Spam is untargeted mass messaging with no personalization or relevance. The distinction matters legally (CAN-SPAM compliance) and practically (deliverability depends on relevance signals).
Dimitar Petkov
Co-Founder of LeadHaste. Builds outbound systems that compound. 4x founder, Smartlead Certified Partner, Clay Solutions Partner.
