An SPF record that looks correct and still fails is one of the most frustrating cold email deliverability problems to diagnose — because the standard advice is "check your SPF record," not "here are the six specific ways a correct-looking SPF record can silently fail." This guide covers all six, with exact diagnostic steps and exact fixes for each one.
💡 TL;DR
The 6 most common reasons an SPF record is not working: multiple SPF records on the same domain, DNS lookup count over 10, wrong record placement (subdomain instead of root), recently changed DNS that has not propagated, DMARC misalignment overriding a passing SPF, and sending from an IP not covered by the record. Diagnose using MXToolbox SPF Lookup and Gmail original message headers (look for spf=pass in Authentication-Results). Most fixes take under 10 minutes once the cause is identified. Litemail pre-configures SPF on every inbox — teams using pre-warmed inboxes do not encounter these issues.
Diagnose Before You Fix — The 3-Step Check That Identifies the Cause
Fixing an SPF record without knowing which failure mode you have wastes time and sometimes makes things worse. Run these three checks in order — the first one that surfaces a problem is your root cause.
MXToolbox SPF Lookup (mxtoolbox.com/spf.aspx): Enter your sending domain. The tool runs a full SPF validation and returns: whether one record exists, whether it is syntactically valid, how many DNS lookups it uses, and any specific errors. A green result means the record structure is correct. Any red or yellow result tells you exactly what is wrong.
Gmail original message headers: Send a test email from your cold email inbox to any Gmail address you control. Open the email. Click the three dots in the top right. Select "Show original." Find the Authentication-Results header. Look for spf=pass. If it shows spf=fail or spf=softfail, the record is not passing for that specific inbox.
DMARC alignment check: In the same Gmail headers, find dmarc=pass or dmarc=fail. If SPF is passing but DMARC is failing, the issue is alignment — the domain in the Return-Path does not match the From address domain. This is a DMARC configuration issue, not an SPF issue, but it produces the same deliverability outcome.
Causes 1 and 2: Multiple SPF Records and Lookup Count Over 10
These two problems account for the majority of SPF failures that are not immediately obvious from looking at the record.
🔧
Multiple SPF records — the most common agency mistake
If your domain has two TXT records starting with v=spf1, DNS returns a PermError for SPF lookups. Receiving servers treat PermError as an SPF failure. Cause: a second record was created when a new email platform was added, rather than updating the existing one. Fix: log into your DNS registrar. Find all TXT records for the root domain (@). Identify all records starting with v=spf1. Merge all include: entries into one record and delete the other. Example: if you have v=spf1 include:_spf.google.com ~all AND v=spf1 include:spf.protection.outlook.com ~all, merge them: v=spf1 include:_spf.google.com include:spf.protection.outlook.com ~all.
🔧
Lookup count over 10 — causes PermError silently
Each include: in an SPF record triggers one or more DNS lookups. The SPF standard limits total lookups to 10. Go over and the record returns PermError — which most servers treat as a failure. Teams with multiple tools (email platform, CRM, marketing automation, cold email tool) on one domain often cross this limit without realising it. Fix: run your SPF record through kitterman.com/spf/validate.html — it shows the exact lookup count. If it is over 10, use AutoSPF or Dmarcian's SPF flattener to inline the IP addresses from each include: entry, reducing lookups to 1 or 2 regardless of how many services are in the record.
Causes 3 and 4: Wrong Record Placement and DNS Propagation
🔧
SPF record at subdomain instead of root domain
SPF records must be placed at the root domain (@ in most DNS panels). If your cold email sends from firstname@outreach.yourdomain.com, the SPF record must be at outreach.yourdomain.com, not at yourdomain.com. And if you send from firstname@yourdomain.com, it must be at yourdomain.com. Check your DNS panel: find your TXT records and confirm the SPF record's host/name field shows @ (root) or the correct subdomain matching your From address. A record at the wrong level passes MXToolbox but fails during actual mail delivery — which is why this is easy to miss.
🔧
DNS propagation not complete — patience is the fix
After adding or changing an SPF record, DNS propagation takes 24 to 48 hours globally. During this window, some resolvers will see the old record and some will see the new one. A spf=fail that appeared immediately after making a DNS change is almost certainly a propagation issue, not a configuration issue. Wait 48 hours, then re-run the MXToolbox check. Check propagation status at whatsmydns.net — it shows whether the change has propagated across different global resolvers.
[INTERNAL LINK: SPF record exact format guide → /blog/cold-email-inbox-spf-record-exact-format-2026]
Causes 5 and 6: DMARC Misalignment and Sending From an Unlisted IP
🔧
DMARC misalignment — SPF passes but DMARC fails
DMARC requires SPF alignment: the domain in the Return-Path (also called Envelope-From or MAIL FROM) must match the From domain in strict mode, or share an organisational domain in relaxed mode. Cold email sending tools often use their own Return-Path domain (for bounce tracking) rather than your sending domain. If DMARC is set to strict alignment (aspf=s), this mismatch causes DMARC to fail even when SPF passes. Fix: either set DMARC to relaxed alignment (default — aspf=r is implicit) or configure your sending tool to use your own Return-Path domain. Check alignment in Gmail headers: DMARC should show the alignment result alongside the pass/fail status.
🔧
Sending from an IP not covered by the SPF record
If your email is sent through a relay, third-party sending tool, or SMTP server whose IP range is not included in your SPF record, authentication fails for those sends. This often happens when a sending tool is added without updating the SPF record to include their IP range. Fix: check the sending tool's documentation for their SPF include: domain. Add it to your existing SPF record. Common ones: SendGrid (include:sendgrid.net), Mailgun (include:mailgun.org), Postmark (include:spf.mtasv.net). Run the lookup count check after adding to confirm you are still under 10.
Verifying the Fix Worked — The Confirmation Process
After making any SPF record change, verify it is working before relaunching campaigns. The same three-step diagnostic process confirms the fix.
Step 1: Wait at least 24 hours after making the DNS change. Step 2: Run MXToolbox SPF Lookup — confirm one valid record, zero errors, under 10 lookups, and no PermError. Step 3: Send a test email from the affected inbox to a Gmail address. View original headers. Confirm spf=pass and dmarc=pass in Authentication-Results.
If SPF is passing but DMARC is still failing after 24 hours, the issue is alignment — return to Cause 5 above. If SPF is still failing after 48 hours, the DNS change may not have propagated to all resolvers — check whatsmydns.net and wait the full 48-hour window before investigating further.
Preventing SPF Problems From Recurring
Most SPF failures are not one-time problems — they recur because the team does not have a process for managing DNS records when new tools are added or platforms change. These three practices prevent the most common repeat failures.
Prevention Practice | When to Do It | Time Required |
|---|---|---|
Check for existing SPF record before adding | Any time a new email service is added | 2 minutes |
Run MXToolbox after every DNS change | After any modification to SPF, DKIM, or DMARC records | 5 minutes |
Document all services included in SPF | Quarterly review of all sending domains | 15 minutes per domain |
Check lookup count when adding new include: | Before finalising any SPF record update | 2 minutes |
For agencies managing multiple client domains: build the verification checklist into your client onboarding template so authentication is confirmed as a documented step before go-live, not a post-launch diagnostic. Pre-warmed inboxes from Litemail come with SPF pre-configured — eliminating these failure modes for teams that use them.
The Bottom Line
Diagnose before fixing: MXToolbox SPF Lookup and Gmail original message headers identify the specific failure mode in under 10 minutes — do this before touching any DNS records.
Multiple SPF records on one domain is the most common cause. Merge all include: entries into one record and delete the duplicate.
Lookup count over 10 causes PermError — use SPF flattening tools to stay under the limit when adding multiple services to one record.
DMARC misalignment can cause delivery failures even when SPF passes — check dmarc=pass in Gmail headers alongside spf=pass.
After fixing, wait 24 to 48 hours for propagation before re-testing. A fix that looks right immediately after the change may not have propagated to all DNS resolvers yet.
Prevent recurrence with three practices: check for existing SPF before adding new ones, run MXToolbox after every DNS change, and document all services covered by the SPF record.
Frequently Asked Questions
Why is my SPF record not passing even though it looks correct?
The six most common causes: multiple SPF records on the same domain (PermError), DNS lookup count over 10 (PermError), SPF record at the wrong domain level (subdomain vs root), DNS propagation not complete (wait 48 hours), DMARC misalignment overriding a passing SPF check, or sending from an IP not included in the record. Run MXToolbox SPF Lookup and check Gmail original message headers to identify which applies.
How do I check if my SPF record is failing?
Two methods: MXToolbox SPF Lookup at mxtoolbox.com/spf.aspx (shows record validity, errors, and lookup count) and Gmail original message headers (send a test email, view original, find Authentication-Results — look for spf=pass or spf=fail). Both checks take under 5 minutes combined and identify the specific failure type.
Can I have two SPF records on one domain?
No. Multiple SPF TXT records on one domain cause a PermError — an authentication failure that most receiving servers treat the same as a hard fail. If you need multiple sending services on one domain, merge their include: entries into a single record. Check for an existing SPF record before adding a new one — this mistake almost always happens when a second service is added without checking.
Why does SPF pass but DMARC still fail?
DMARC requires alignment between the domain in the Return-Path (MAIL FROM) and the From address domain. Cold email sending tools often use their own Return-Path domain for bounce tracking — which creates a misalignment with your From domain. If DMARC is set to strict alignment (aspf=s), this causes a DMARC failure even when SPF passes. Set DMARC to relaxed alignment (the default aspf=r) or configure your sending tool to use your domain's Return-Path.
How long does an SPF record fix take to work?
DNS propagation takes 24 to 48 hours after making any change. During this period, some DNS resolvers will see the old record and some will see the new one. A fix that is correct will work fully after 48 hours. Use whatsmydns.net to check propagation status across different global resolvers before concluding the fix has not worked.
What is the maximum number of DNS lookups allowed in an SPF record?
Ten. The SPF standard limits total DNS lookups (triggered by include:, a, mx, ptr, and exists mechanisms) to 10 per SPF evaluation. Going over 10 returns a PermError that most receiving servers treat as an authentication failure. Check your lookup count at kitterman.com/spf/validate.html. If over 10, use SPF flattening tools like AutoSPF to inline the IP addresses and reduce lookups.
