Since Google and Yahoo began enforcing authentication requirements for bulk senders, SPF, DKIM and DMARC stopped being “nice to have” and became the entry ticket to the inbox. Miss one record — or misconfigure it, which is far more common — and your cold email lands in spam no matter how good the copy is. Having configured DNS authentication across hundreds of sending domains, here is the complete setup, the exact records, and the mistakes that silently break deliverability.
KEY TAKEAWAYS
- SPF lists which servers may send for your domain; DKIM cryptographically signs each message; DMARC tells receivers what to do when either fails.
- Google and Yahoo require all three for bulk senders — missing DMARC alone routes you to spam.
- The #1 silent killer: two SPF or two DMARC records on one domain, which invalidates both.
- Always send cold email from separate domains, never your main company domain.
- Verify with real tools after setup — a record that exists is not the same as a record that passes.
What Each Record Actually Does
Think of the three records as answering three different questions a receiving mail server asks about your message:
SPF (Sender Policy Framework) answers “is this server allowed to send for this domain?” It’s a TXT record listing your authorized senders. For a Google Workspace sending domain it looks like: v=spf1 include:_spf.google.com ~all. The ~all (softfail) ending is standard for cold email domains.
DKIM (DomainKeys Identified Mail) answers “was this message tampered with, and does it really come from this domain?” Your sending platform signs every outgoing message with a private key; the public key sits in your DNS as a TXT record (usually at a selector like google._domainkey). You generate this inside Google Workspace Admin or Microsoft 365 and paste the record into your DNS — with Cloudflare, that takes about a minute per domain.
DMARC (Domain-based Message Authentication) answers “what should I do if SPF or DKIM fails?” It’s a TXT record at _dmarc.yourdomain.com. A sane starting policy for cold email domains: v=DMARC1; p=none; rua=mailto:reports@yourdomain.com — monitor first, then tighten to p=quarantine once you’ve confirmed everything passes.
The Setup Order That Works
Set them up in this sequence, per sending domain: first SPF (immediate), then generate and publish DKIM from your email provider, then add DMARC last — because DMARC evaluates the other two, publishing it before they pass just documents your failures. Allow DNS propagation time, then send a test message to a Gmail address and open “Show original”: you want to see SPF: PASS, DKIM: PASS, DMARC: PASS on every send.
The Mistakes That Silently Break Everything
After auditing DNS across a fleet of 400+ sending domains, the same handful of errors accounts for nearly every authentication failure:
Duplicate records. Two SPF records on one domain is not “double protection” — the standard says it invalidates SPF entirely. Same for DMARC. This happens constantly when a registrar auto-adds a record and someone later adds another manually. One SPF, one DMARC, per domain, always.
Missing DKIM on secondary provider domains. Teams enable DKIM on their first batch of domains, then forget it on later batches — we once found DKIM missing on 228 Microsoft domains in a single audit. Every sending domain needs its own DKIM record published and switched on in the provider admin.
SPF lookup limit. SPF allows a maximum of 10 DNS lookups. Stack too many include: statements (common when tools tell you to add theirs) and SPF returns a permanent error. Cold email domains should have exactly one include — your actual sending provider.
Authenticating the wrong domain. Records must live on the domain in the From address of your cold emails — your sending domains — not (only) your main company domain.
⚠️ Warning: Never run cold email from your primary company domain, even with perfect authentication. Sending domains absorb reputation risk; your main domain carries your business. Buy separate, similar domains and keep them isolated.
Beyond the Records: What Authentication Doesn’t Fix
Passing SPF, DKIM and DMARC gets you considered for the inbox — it doesn’t get you into it. Sender reputation is built by the rest of the system: gradual warmup on new domains and inboxes, sending volumes that stay under provider thresholds, and above all a clean list. Authentication tells Google who you are; your bounce rate tells Google whether to trust you. A perfectly authenticated domain sending to an unverified list still ends up in spam — which is why list verification (including catch-all verification) sits alongside DNS setup, not after it.
Skip the DNS busywork
We set up and audit SPF, DKIM and DMARC across entire domain fleets as part of our cold email infrastructure service — and deliver verified lead lists that keep the reputation you build.
Frequently Asked Questions
Do I need DMARC for cold email?
Yes. Google and Yahoo require it for bulk senders, and its absence is treated as a negative signal even at lower volumes. Start with p=none and tighten later.
How long does DNS propagation take?
Usually minutes on modern DNS hosts like Cloudflare, but allow up to 24–48 hours before concluding something is broken.
Can I use one SPF record for all my sending domains?
Each domain needs its own records, but they can be identical in content. Bulk DNS management (or scripted record generation) makes fleet-wide setup manageable.
How do I check if my authentication passes?
Send to a Gmail account and use “Show original,” or use free checkers like MXToolbox. Check per sending domain — passing on one proves nothing about the others.
Running more than a handful of sending domains? Talk to us — full-fleet DNS audits and setup are what we do daily.