SPF, DKIM, and DMARC for Cold Email: The Setup That Keeps You Out of Spam

SPF, DKIM, and DMARC for Cold Email: The Setup That Keeps You Out of Spam

Three DNS records decide whether your cold email gets a fair hearing at Gmail, Outlook, and Yahoo. Get them wrong and nothing downstream matters: not the copy, not the list quality, not the warmup schedule. Since 2024 the major mailbox providers stopped treating authentication as a nice-to-have signal and started treating it as an entry requirement.

Here is the setup, the copy-paste records, and the failure modes that quietly cost people their inbox placement.

What each record actually verifies

The load-bearing word in that last row is aligns. DMARC does not care that SPF passed somewhere. It cares that the domain SPF authenticated matches the domain in the visible From: header, or that the DKIM signing domain does. A message can pass SPF and still fail DMARC. That is the single most common surprise for anyone setting this up for the first time.

The requirements you are actually graded against

Google's sender guidelines require SPF or DKIM for every sender, and both SPF and DKIM plus a published DMARC record for anyone sending 5,000 or more messages a day to personal Gmail accounts. That DMARC policy is allowed to be p=none; Google does not require enforcement. Google also requires the From domain to align with either the SPF domain or the DKIM domain, valid forward and reverse DNS, a TLS connection, RFC 5322 compliant formatting, and one-click unsubscribe using RFC 8058 headers on marketing and subscribed mail. The spam rate ceiling is 0.30 percent as reported in Postmaster Tools, with Google recommending you stay under 0.10 percent.

Yahoo asks for the same shape: SPF or DKIM at minimum for all senders, both plus a DMARC policy of at least p=none for bulk senders, DKIM keys of at least 1024 bits, spam rate below 0.3 percent, a working list-unsubscribe header, and unsubscribes honoured within two days.

Microsoft went further. From 5 May 2025, domains sending more than 5,000 messages a day to outlook.com, hotmail.com, and live.com addresses must have all three records in place. Non-compliant mail is rejected outright with 550 5.7.515 Access denied, sending domain [domain] does not meet the required authentication level.

Cold email operations rarely push 5,000 a day through one domain, and that does not get you out of any of this. Filters treat authentication as a trust signal at every volume, and a fresh cold sending domain has none of the reputation history a mature marketing domain leans on. Authenticate everything.

SPF: copy-paste records

One TXT record at the root of the sending domain. Exactly one. Two SPF records on the same domain is a permanent error under RFC 7208 and both get discarded.

Google Workspace:

v=spf1 include:_spf.google.com ~all

Microsoft 365:

v=spf1 include:spf.protection.outlook.com -all

Google Workspace plus a third-party sending platform:

v=spf1 include:_spf.google.com include:sending-platform.example ~all

Two things to watch.

The ten lookup limit. SPF evaluation allows a maximum of ten DNS-querying mechanisms (include, a, mx, ptr, exists, redirect). Exceed it and the result is permerror, which most receivers treat as a failure. Each include can pull in further lookups of its own, so three or four vendor includes is enough to break a record that looks perfectly short. Count them with an SPF checker before you ship, not after.

~all versus -all. ~all is softfail: accept the message but mark it. -all is hardfail: reject it. Hardfail is stricter and is what Microsoft publishes by default. If you use -all, every legitimate sender for that domain has to be in the record or you break your own mail. Start on ~all while you are still adding infrastructure and tighten to -all once the inventory has stopped moving.

DKIM: generate, publish, verify

Google Workspace. Admin console, then Apps, Google Workspace, Gmail, Authenticate email. Select the domain, generate a new record, and choose 2048-bit unless your DNS provider cannot handle the record length. Google's default selector prefix is google, so the record you publish looks like this:

google._domainkey.yourdomain.com   TXT   v=DKIM1; k=rsa; p=<public key>

Return to the admin console and click Start authentication. Google notes that changes can take up to 48 hours to propagate. Send a test message and look for dkim=pass in the recipient's Authentication-Results header.

Microsoft 365. DKIM is published as two CNAME records rather than a TXT record, which lets Microsoft rotate keys without you touching DNS:

selector1._domainkey.yourdomain.com   CNAME   selector1-yourdomain-com._domainkey.<tenant>.onmicrosoft.com
selector2._domainkey.yourdomain.com   CNAME   selector2-yourdomain-com._domainkey.<tenant>.onmicrosoft.com

Then enable signing for the domain in the Defender portal. Copy the exact target values the portal shows you rather than constructing them by hand, because the tenant fragment varies.

DMARC: the policy record, tag by tag

Monitoring only, which is the correct starting point:

_dmarc.yourdomain.com   TXT   v=DMARC1; p=none; rua=mailto:dmarc@yourdomain.com; fo=1

Quarantine on a partial rollout:

v=DMARC1; p=quarantine; pct=25; rua=mailto:dmarc@yourdomain.com

Full enforcement:

v=DMARC1; p=reject; sp=reject; adkim=s; aspf=s; rua=mailto:dmarc@yourdomain.com

What the tags do:

• p= is the policy for the domain: none reports only, quarantine sends failures to spam, reject refuses them at SMTP.
• sp= sets a separate policy for subdomains. Leave it out and subdomains inherit p=. Sending cold email from a subdomain while the parent domain sits on p=reject is the classic way to kill a campaign before it starts.
• pct= applies the policy to a percentage of failing mail. Useful for staged rollouts and ignored entirely at p=none.
• adkim= and aspf= set alignment strictness: r for relaxed (the default, allows subdomain matches) or s for strict (requires an exact domain match).
• rua= is where aggregate XML reports are delivered. Without it you are enforcing blind.

p=none satisfies the Gmail and Yahoo bulk sender requirement and protects nobody from spoofing. Sit at p=none long enough to read a few weeks of aggregate reports, confirm every legitimate source passes and aligns, then move to quarantine and finally reject.

Common failure modes

Passing SPF, failing DMARC. Your platform sends with its own return-path domain, SPF authenticates that domain, and it does not match your From domain. Relaxed alignment only forgives subdomains of the same organizational domain. Fix it by having the vendor DKIM-sign with your domain, or by configuring a custom return-path on your domain.

Two SPF records. Someone adds a second record for a new tool instead of adding an include to the existing one, and both get thrown away. Merge them into one.

Blowing the lookup budget. A record with a sending platform, a CRM, a helpdesk, and a transactional provider can quietly cross ten lookups. Flatten it or drop the includes you no longer use.

A subdomain with no policy of its own. Inheritance surprises people in both directions. Publish an explicit sp= on the parent, or a dedicated _dmarc record on the sending subdomain.

Forwarding. SPF breaks on forwarding because the forwarding server is not in your record. DKIM usually survives because the signature travels with the message. That asymmetry is exactly why DKIM is the more durable of the two, and why relying on SPF alone is fragile.

Jumping straight to reject. Publishing p=reject on day one, on a domain where one of your five sending tools is unsigned, silently deletes that tool's mail with no bounce you will notice.

The cold email specific part

An outbound operation runs many sending domains, not one. Each needs its own SPF, DKIM, and DMARC records, and each fails independently. The reason we buy 3x more email infrastructure than we need is the same reason this matters: domains are consumable, and an unauthenticated domain is consumed before it sends a single message.

Build the records into domain provisioning rather than a post-launch checklist, then verify per domain before the first send:

1. dig TXT yourdomain.com returns exactly one SPF record.
2. dig TXT google._domainkey.yourdomain.com (or your selector) returns a key.
3. dig TXT _dmarc.yourdomain.com returns a policy with an rua address.
4. A test send to a Gmail account shows spf=pass, dkim=pass, and dmarc=pass, with the DKIM domain matching the From domain.
5. The domain shows a Compliant status in Google Postmaster Tools.

Authentication is table stakes rather than strategy. Once it is clean, the things that move inbox placement are list quality, volume discipline, and recipient behaviour. Start with the cold email deliverability guide and what actually works in 2026, watch your spam rate against benchmarks, and clean lists with real verification so bounces never touch your reputation. If sending is already broken, check whether you are blacklisted before rebuilding anything. And if you are mailing into Canada or the EU, records are only half the compliance picture: here is what the law requires.

Want this built and monitored for you? Get a free campaign plan and we will map the domain, authentication, and sending setup for your ICP.