SPF, DKIM, DMARC: The Cold Email Authentication Setup That Passes

SPF, DKIM, DMARC are the three DNS records that decide whether your cold email is evaluated or refused at the door. They are not a ranking factor or a best practice any more. Since February 2024 at Google and Yahoo, and since May 2025 at Microsoft, failing them is grounds for outright rejection — and for senders below the formal bulk thresholds, failing them is grounds for silent filtering, which is worse because nothing tells you it happened.

Most guides stop at “publish these three records”. That is the easy part, and it is not where setups break. This one covers what each record actually proves, the alignment trap that quietly invalidates a technically correct configuration, SPF’s ten-lookup ceiling, DKIM key handling, a DMARC rollout that will not black-hole your mail, and a troubleshooting table keyed to real bounce codes.

What SPF, DKIM, DMARC each actually prove

SPF, DKIM, DMARC answer three different questions, and they are only useful together. Two out of three is a configuration that passes tests and fails inboxes.

Record	Question it answers	Lives in
SPF	Is this server allowed to send for this domain?	A TXT record on the domain
DKIM	Was the message altered after it was signed?	A TXT record at selector._domainkey
DMARC	What should happen when the first two fail, and who gets told?	A TXT record at _dmarc

DMARC is the one that turns the other two from information into enforcement. Without it, a receiving server knows SPF failed but has no instruction from you about what to do next, so it falls back on its own judgement — and its own judgement about an unauthenticated stranger is not generous.

Why cold email breaks SPF, DKIM, DMARC more often than marketing email

A marketing team configures one domain once. An outbound team runs four lookalike domains, a dozen mailboxes, a sequencing tool, a tracking domain and sometimes a separate relay. Every one of those is a place for SPF, DKIM, DMARC to fall out of alignment, and the failure modes are specific to this setup.

• New domains, copied records. A record pasted from the main domain that references the wrong provider passes syntax checks and fails validation.
• Sending tools that rewrite the Return-Path, which breaks SPF alignment even though SPF itself passes.
• Multiple senders per domain — the mailbox provider, the sequencer, a CRM — each needing its own DKIM selector.
• Nobody monitoring. With no DMARC reporting address configured, a break is invisible until pipeline drops a month later.

SPF: one record, ten lookups, no exceptions

A working SPF record for a Google Workspace sending domain is short:

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

Three rules govern whether the SPF half of SPF, DKIM, DMARC survives contact with reality.

• One SPF record per domain. Two TXT records beginning v=spf1 is a permanent error, and it is the single most common misconfiguration. Merge the includes into one record instead.
• Ten DNS lookups, maximum. Each include, a, mx and redirect costs a lookup, and nested includes count too. Exceed ten and evaluation returns permerror, which most receivers treat as a fail. Adding a fourth vendor to a record that already had three is how teams cross the line without noticing.
• Use ~all, not ?all. A neutral ?all authorises nothing. Move to -all only once DMARC reports confirm every legitimate sender is accounted for.

SPF flattening — replacing includes with literal IP ranges to duck the lookup limit — solves the count and creates a maintenance liability, because your record silently goes stale the day your provider changes IPs. Prefer removing unused includes. The mechanics are specified in RFC 7208 if you need the authoritative wording for an internal argument.

DKIM: selectors, key length and rotation

DKIM signs the message with a private key and publishes the public key in DNS at a selector you choose. Each service that sends on your behalf gets its own selector, which is why a domain can legitimately hold several DKIM records at once.

• Use 2048-bit keys. Google accepts 1024 as a minimum and recommends 2048. Some DNS providers require splitting the longer value into strings, which is a formatting task rather than a reason to downgrade.
• One selector per sender. google._domainkey for Workspace, a distinct selector for the sequencing tool. Reusing a selector overwrites a working key.
• Rotate roughly every six months, publishing the new key before switching signing over so both validate during the overlap.
• Confirm the signing domain. The d= value in the signature must be your sending domain, not your vendor’s. If d= reads like a tool’s domain, DKIM passes and DMARC alignment fails.

DMARC: the policy, the reports and the progression

A starting DMARC record, the third leg of SPF, DKIM, DMARC, does two jobs: it satisfies the provider requirement, and it turns on the reporting that tells you what is actually happening.

v=DMARC1; p=none; rua=mailto:dmarc@yourdomain.com; fo=1; adkim=r; aspf=r

p=none is monitor-only and is the minimum that satisfies Google, Yahoo and Microsoft. rua is the address that receives daily aggregate XML reports, and without it you are running blind. adkim and aspf control alignment strictness, where r (relaxed) permits subdomains to align with the organisational domain and s (strict) does not.

Progress deliberately, over roughly six weeks: two weeks at p=none while you read reports and identify every legitimate sender, then p=quarantine; pct=25, raising the percentage as reports stay clean, then p=reject once nothing legitimate is failing. Add sp=none if subdomains are used by teams you do not control yet. The policy reference lives in RFC 7489.

Aggregate reports arrive as raw XML from dozens of receivers, which is unreadable at volume. A parsing service is worth its small cost purely for the first month, when you are discovering which of your own systems you had forgotten about.

The alignment trap that invalidates correct SPF, DKIM, DMARC records

This is the part that costs teams the most time, because every individual check reports a pass while DMARC still fails. Alignment asks a question neither SPF nor DKIM asks on its own: does the domain the recipient sees match the domain that was authenticated?

Domain	Where it appears	Must align with
From domain	Visible header the recipient reads	The reference point for everything
Return-Path	Envelope sender, checked by SPF	From domain, for SPF alignment
DKIM d=	Signature header	From domain, for DKIM alignment

DMARC passes when at least one of the two aligns. The classic cold email failure is a tool that sends with its own Return-Path: SPF passes against the tool’s domain, the From header says yours, the two do not align, and if DKIM is also signing with the vendor’s d= then nothing aligns and DMARC fails outright. The fix is a custom Return-Path or bounce domain on your sending domain, which every serious sending platform supports.

An SPF, DKIM, DMARC rollout order that will not break your mail

1. Inventory every sender using the domain: mailbox provider, sequencer, CRM, invoicing, helpdesk, marketing platform.
2. Publish one SPF record covering all of them, and count the lookups.
3. Enable DKIM at every sender, one selector each, 2048-bit.
4. Set a custom Return-Path in the sending tool so SPF aligns with the From domain.
5. Publish DMARC at p=none with a working rua address.
6. Send a live test to a Gmail and a Microsoft 365 mailbox, then read the raw headers for three passes: spf=pass, dkim=pass, dmarc=pass.
7. Read two weeks of aggregate reports and fix anything legitimate that is failing.
8. Escalate to quarantine, then reject, raising pct gradually and watching reports at each step.

Finish the SPF, DKIM, DMARC work before email domain warmup begins. Warming a domain whose authentication is broken teaches providers that mail from this domain fails checks, which is the opposite of the intended lesson.

What the providers now require

Google and Yahoo require SPF, DKIM, DMARC with alignment from senders above 5,000 messages a day, alongside TLS, valid reverse DNS, one-click unsubscribe and a complaint rate below 0.3%. Microsoft applies a comparable rule to outlook.com, hotmail.com and live.com from 5 May 2025, rejecting non-compliant mail with 550 5.7.515. Google’s sender guidelines remain the reference text; our post on the Gmail bulk sender requirements covers the enforcement detail and the recovery timelines.

Beyond SPF, DKIM, DMARC: the optional records

• MTA-STS and TLS-RPT enforce and report on encrypted transport. Neither is required for cold email, and both are cheap signals of a properly run domain.
• BIMI displays your logo beside the message, but requires DMARC at quarantine or reject plus a verified mark certificate. Worth it for brand-heavy senders, rarely for lookalike outbound domains.
• Reverse DNS is handled by your provider on shared infrastructure, and becomes yours to configure the moment you move to a dedicated IP.

Troubleshooting SPF, DKIM, DMARC by bounce code

Symptom	Likely cause	Fix
550 5.7.515 from Microsoft	Authentication below required level	Publish DMARC, confirm alignment on one of SPF or DKIM
dmarc=fail with both checks passing	Alignment, not authentication	Set a custom Return-Path; check DKIM d=
spf=permerror	Over ten lookups, or two SPF records	Merge records, remove unused includes
dkim=none	Signing not enabled at that sender	Add a selector for the sender in question
Passes to Gmail, fails to Microsoft	Missing DMARC record entirely	Publish p=none as a minimum

Frequently asked questions about SPF, DKIM, DMARC

Do I need DMARC if SPF and DKIM already pass?

Yes. Microsoft rejects high-volume mail without a DMARC record regardless of the other two, and without rua reporting you have no way of learning that something broke until placement drops.

Should each sending domain have its own records?

Yes, and they are evaluated independently. Four lookalike domains means four complete configurations. Templating this at setup takes minutes; discovering that domain three was never signed takes a quarter.

Is p=reject risky for a cold email domain?

Less than for a corporate domain, because a dedicated sending domain has few legitimate senders to break. Still progress through none and quarantine first — a forgotten sender at p=reject disappears silently.

How long until DNS changes take effect?

Usually minutes to a few hours, governed by the record’s TTL. Lower the TTL to 300 seconds before a planned change, then restore it afterwards.

SPF, DKIM, DMARC are the price of entry, not the strategy

Correct SPF, DKIM, DMARC records get your mail evaluated. They do not get it into the inbox — that is decided by list quality, sending behaviour and whether recipients want to hear from you. Treat authentication as the thing you configure once, monitor forever with aggregate reports, and never have to think about again.

Continue with the full cold email deliverability stack, the email domain warmup schedule that follows this setup, reducing your email bounce rate and B2B email verification for the list layer, or cold email sequence design for the copy. More in cold email and deliverability.

Authentication solved? The list is next. ZenBee brings a 700M+ verified contact network, real-time buying and hiring signals, and multichannel LinkedIn and email sequencing into one workflow, so a properly authenticated domain is pointed at people worth reaching. Request a demo, or start for free.