SPF vs DKIM vs DMARC: Which to Fix First for Cold Email Recovery
When deliverability is broken and you're trying to fix it, understanding what each authentication protocol does helps you prioritize. Here's the right order.
Your cold email deliverability is damaged and you are trying to figure out which authentication protocol to focus on first. You have heard conflicting advice about which one matters most. Here's the clear priority order for recovery.
What each protocol does
SPF: Defines which IP addresses are authorized to send email for your domain. It's a list you publish in DNS. Prevents unauthorized servers from sending as you. Does not verify the message content or prove the From address is legitimate.
DKIM: Adds a cryptographic signature to each email that proves the message was authorized by the domain owner and was not altered in transit. Tied to the message itself, not the sending IP — more robust when emails pass through forwarding or relay services.
DMARC: Ties SPF and DKIM to your visible From address through alignment. Tells receiving servers what to do with messages that fail authentication. Provides reporting so you can see what's happening with your domain's email authentication.
Priority order for recovery
1. DKIM — fix first, highest impact
DKIM is arguably the most important individual auth check for deliverability. A broken DKIM signature is one of the most common causes of sudden spam placement. Use the DKIM checker — it auto-discovers selectors and shows you exactly what's published and whether it's valid.
2. SPF — fix second
A missing or malformed SPF record means your sending server is not authorized. Check with the SPF checker. For Google Workspace: v=spf1 include:_spf.google.com ~all. For M365: v=spf1 include:spf.protection.outlook.com -all.
3. DMARC — fix third
DMARC is the enforcement and reporting layer. Add at minimum: v=DMARC1; p=none; rua=mailto:dmarc@yourdomain.com. Start with p=none — this monitors without filtering. Only tighten policy after confirming all legitimate sending sources pass authentication. Verify with the DMARC lookup.
If all three are set up but deliverability is still poor
Authentication is probably not the bottleneck. Run the placement test and check alignment — then check the headers to confirm all three are actually passing end-to-end. If all three pass, shift focus to non-authentication factors: reputation, content, and engagement.
Common mistakes in the wrong order
- Setting up DMARC with
p=rejectbefore verifying all legitimate sending sources pass authentication — this causes your own emails to be rejected - Setting up only SPF and thinking authentication is done
- Focusing on authentication optimization when the real problem is reputation or content
- Adding multiple SPF records to the same domain
- Using short DKIM keys (512-bit) when 2048-bit is the current standard
Repair or replace?
Authentication issues are always repairable through DNS configuration. You never need to replace infrastructure just because of authentication problems. Fix the records, verify they pass with the relevant checkers, and move on to diagnosing other issues.
If the underlying domain reputation is damaged, that is a different question. Clean authentication on a damaged domain helps recovery but does not guarantee it. WarmInboxes can provide inboxes on domains with both clean authentication and healthy reputation.
Run the checks first
Before replacing anything, run a free inbox placement test. You might find the issue is DNS, not the domain — and save yourself a week of unnecessary work.