SPF, DKIM and DMARC for Cold Email: The Complete Setup Guide
Authentication is the entry ticket. Since Google and Yahoo's sender requirements, mail without SPF, DKIM and DMARC doesn't get a fair hearing — it gets filtered before your copy is ever judged. Here's the exact setup I deploy across every sending domain I manage.
SPF — who is allowed to send
SPF is a TXT record listing the servers permitted to send for your domain. One record per domain, max 10 DNS lookups.
Google Workspace: v=spf1 include:_spf.google.com ~all
Microsoft 365: v=spf1 include:spf.protection.outlook.com ~all
Common failures: two SPF records on one domain (instantly invalid), leftover includes from old tools blowing the 10-lookup limit, and +all (which authorizes the entire internet).
DKIM — cryptographic proof it wasn't altered
DKIM signs each message with a private key; receivers verify against the public key in your DNS. The critical detail: publishing the DNS record is only half the job — you must also enable signing in Google Admin (Apps → Gmail → Authenticate email) or via M365. I've audited fleets where most domains had the record but signing was never switched on. Verify by sending a real message and checking headers for dkim=pass with your domain, not the provider's default.
DMARC — the policy that ties it together
DMARC tells receivers what to do when SPF/DKIM fail, and requires alignment — the authenticated domain must match your From domain.
Publish at p=none
v=DMARC1; p=none; rua=mailto:dmarc@yourdomain.com — observe, don't enforce.
Watch reports 1–2 wks
Confirm your real mail passes aligned SPF/DKIM and nothing legitimate fails.
Move to p=quarantine
Failures go to spam instead of inbox. This is the standard for cold email fleets.
Verify per domain
Run the panel above on every domain — automation helps at fleet scale.
The order to build a new domain
On a fresh sending domain: MX first, then SPF, then create the mailboxes, enable DKIM and confirm signing, then DMARC at p=none, then redirects and tracking domain, then warmup. Doing DMARC-at-quarantine before DKIM signing is live is a classic self-inflicted spam trip. Full domain buildout: domain setup guide; what happens when this is wrong: why cold emails go to spam.
Two follow-ons worth reading: if SPF and DKIM pass but DMARC does not, the cause is alignment — why DMARC fails when SPF and DKIM pass. And for what the mailbox providers actually require of you, is DMARC mandatory?
Sources
- Google Workspace — Turn on DKIM signing
- Google — Email sender guidelines
- Microsoft Learn — Configure DKIM
- Microsoft Learn — Configure DMARC
- Yahoo — Sender best practices
- RFC 7208 — SPF
- RFC 9989 — DMARC
Tools for this
SPF checkerValidate a record and see who it authorises.DKIM checkerFind signing keys without the selector.DMARC checkerSee whether your policy enforces anything.Frequently asked questions
What DMARC policy should cold email domains use?
Start every new sending domain at p=none with a rua reporting address so you can see alignment before enforcing. Once SPF and DKIM pass consistently for a couple of weeks, move to p=quarantine. Publishing no DMARC at all now costs you placement under Google and Yahoo bulk-sender requirements.
Do I need SPF, DKIM and DMARC on every sending domain?
Yes — every single one. Authentication is per-domain, not per-account. A fleet where 90% of domains are authenticated and 10% are not still bleeds: the broken 10% get junked and drag down the campaign stats you make decisions with.
Why does DKIM show as configured but fail?
Usually the CNAME or TXT record was published in DNS but DKIM signing was never turned on inside Google Admin or Microsoft 365 — the record existing does not mean the mailbox is signing. Always confirm by inspecting the headers of a real sent message.