Home › Blog › SPF, DKIM and DMARC for Cold Email: Records and Failures
SPF, DKIM and DMARC for Cold Email: The Records, the Failures, and What to Set in 2026
The three authentication records are pass/fail prerequisites for inbox placement now, not optimisations. Here is what each one proves, the exact records to publish for a cold email domain, the four failures that account for most audits, and how to verify all of it before the first send.
Quick Answer: Three Records, Set Before the First Send, Verified With a Real Message
SPF lists the servers allowed to send for your domain. DKIM signs each message with a key published in your DNS, so the receiver can prove it was not altered and came from you. DMARC ties the two to the visible From address and tells receivers what to do on failure. In 2026 all three are required by Google, Yahoo and Microsoft for anyone sending at volume, and treated as a trust signal below that. For a cold email domain: one SPF record under ten lookups, DKIM enabled on the platform and signing with your domain, and DMARC at p=none with reporting, moved to p=quarantine once the reports are clean. Verify by sending a test to yourself and reading the headers, not just by checking DNS.
What Each Record Proves
- •SPF (Sender Policy Framework) is a TXT record on your domain naming the servers that may send mail with your domain in the envelope. A receiver looks up the record, checks the connecting server against it, and gets pass, fail, softfail or permerror. It proves the server was authorised. It proves nothing about the message.
- •DKIM (DomainKeys Identified Mail) is a signature added to each message by the sending platform, using a private key whose public half sits in your DNS under a selector. The receiver fetches the key, verifies the signature, and knows the message is unaltered and signed by whoever controls that DNS. It survives forwarding, which SPF does not.
- •DMARC (Domain-based Message Authentication, Reporting and Conformance) is a policy record that says: for mail claiming to be from this domain, require SPF or DKIM to pass and align with the From domain, and if neither does, do this (none, quarantine or reject). It also asks receivers to send you aggregate reports of what they saw.
The word that matters is alignment. SPF can pass for a sequencer's bounce domain and DKIM can pass for the sequencer's own signing domain, and DMARC will still fail, because neither matched the domain in the From header a human sees. Cold email tools that sign with their own domain by default produce exactly this, and it is invisible until you read a delivered header or a DMARC report.
The Records to Publish on a Cold Email Domain
These are the shapes we set on every domain we deliver. The platform-specific values come from your Google Workspace or Microsoft 365 admin, and the record generator builds them with your values filled in.
v=spf1 include:_spf.google.com ~all v=spf1 include:spf.protection.outlook.com ~all
One include for the platform that sends, and nothing else unless something else genuinely sends as this domain. Two SPF records on one domain is a permerror, and so is a record that reaches ten lookups once a helpdesk, a CRM and a second sequencer have been added over the years. Count them with the lookup counter.
google._domainkey TXT v=DKIM1; k=rsa; p=MIIBIjANBg... (Google: 2048-bit key from the admin console) selector1._domainkey CNAME selector1-yourdomain-com._domainkey.yourtenant.onmicrosoft.com selector2._domainkey CNAME selector2-yourdomain-com._domainkey.yourtenant.onmicrosoft.com
Google gives you a key to paste; Microsoft gives you two CNAMEs and then requires you to switch DKIM on for the domain in the Exchange admin centre, which is the step that gets missed. Use 2048-bit keys where the platform offers them.
_dmarc TXT v=DMARC1; p=none; rua=mailto:[email protected]; adkim=r; aspf=r; pct=100 after two clean weeks of reports: _dmarc TXT v=DMARC1; p=quarantine; rua=mailto:[email protected]; adkim=r; aspf=r; pct=100
Relaxed alignment (adkim=r, aspf=r) lets a subdomain sign for the organisational domain, which is what you want when sending domains sit under a parent. The rua address receives XML aggregate reports; the DMARC report analyzer reads them in the browser without uploading anything.
The Four Failures Behind Most Audits
- •SPF permerror from the lookup limit. The record is valid syntax and fails anyway, because includes-of-includes crossed ten. The fix is to remove what no longer sends and flatten what must stay; the walkthrough counts nested lookups.
- •DKIM delegated, never published. Microsoft 365's CNAMEs are in DNS, DKIM was never enabled for the domain, so the key does not exist. Checkers report "selector not found", people try other selector names, and the fix is one toggle in the admin centre. The DKIM checker now tells this case apart from a genuinely missing record.
- •DMARC passes for the wrong domain. The sequencer signs with its own domain, SPF passes for its bounce address, and nothing aligns with your From. Fix by signing with your domain (every mainstream sequencer supports it) and confirm with the alignment checker on a delivered header.
- •p=reject before alignment was confirmed. A policy copied from a security checklist, applied to a domain where one sending path never aligned. The receivers did what the record asked and rejected the campaign. Start at none, read the reports, then tighten.
What Authentication Does Not Do
Passing all three gets you evaluated. It does not get you placed. Receivers then weigh reputation, content and engagement, none of which a DNS record changes. A brand-new domain with perfect records is still a brand-new domain, which is why the next step after authentication is warmup, or prewarmed infrastructure that has already done it. Our deliverability guide covers the other three inputs; this page is only the first.
Every domain we deliver ships with these records set and verified by hand against a delivered message, on Google Workspace, Microsoft 365 and Azure tenants alike. If you would rather check your own, run the email authentication checker: it runs SPF, DKIM, DMARC, MX, BIMI and MTA-STS in one pass and marks the optional ones as optional rather than failing them.
Frequently Asked Questions
Do I need all three for cold email, or is SPF enough?
All three. Google and Yahoo's bulk sender rules require SPF and DKIM to both pass and DMARC to be published with at least one of them aligned, and Microsoft applies the same shape. A domain with SPF alone is treated as unauthenticated by the receivers that matter. Setting the three records takes fifteen minutes per domain; skipping any of them costs the domain.
What DMARC policy should a cold email domain use?
Start at p=none with rua reporting, so you can see what is sending as your domain and whether it aligns. Once two weeks of reports show only your own mail passing, move to p=quarantine. Reject is correct eventually, but moving there before you have confirmed alignment on every sending path quarantines your own campaigns.
My DKIM checker says the selector is not found on Microsoft 365. What is wrong?
Usually nothing is missing from DNS: the CNAME records are there, but DKIM was never enabled for the domain in the Microsoft 365 admin centre, so Microsoft never published the key the CNAME points at. It is the single most common Microsoft DKIM failure we see, and it looks identical to a missing record from the outside. Enable DKIM for the domain in Exchange admin, wait for propagation, and check again.
Why does my SPF record pass on one tool and fail on another?
Almost always the 10-DNS-lookup limit. SPF allows ten lookups across every include, a, mx and redirect; a record with Google, a sequencer and a helpdesk included can exceed it, which returns permerror. Some tools report the record as syntactically fine without counting; receivers count. Flatten or remove includes you no longer use.
Does DMARC alignment mean SPF and DKIM must both align?
No. DMARC passes if either SPF or DKIM passes and aligns with the From domain. For cold email the DKIM path is the reliable one, because forwarding breaks SPF alignment and DKIM survives it. Make sure DKIM signs with your sending domain, not the sequencer's, and SPF alignment becomes a bonus rather than a dependency.
Prewarmed & Fresh Inboxes
Google, Microsoft 365 and Azure inboxes with free prewarmed domains and DNS configured before you log in. Prewarmed inboxes send the day they land; every order is delivered within 48 to 72 hours.
Get Prewarmed & Fresh Inboxes