Do I need all three records, or is SPF enough?

Google requires SPF or DKIM from every sender and Yahoo requires both, so two are effectively mandatory. DMARC is formally required above 5,000 messages a day, but publishing it is standard practice for cold outreach because it is the only record that enforces alignment and the only one that reports failures back to you.

What DMARC policy should a new sending domain start with?

Start at p=none with a reporting address. That satisfies the bulk sender requirement while you read the aggregate reports and confirm that legitimate mail passes. Move to p=quarantine and then p=reject once the reports are clean, which protects the domain from being spoofed.

Why does DMARC fail when SPF and DKIM both pass?

Because passing and aligning are different checks. Alignment compares the visible From: domain against the domain that SPF authorised or DKIM signed. If your platform signs with its own vendor domain, both underlying checks pass and DMARC still fails.

Do these records need to go on my main domain too?

Yes. Authentication is not only a bulk sender rule, and an unauthenticated primary domain is also the easiest one for someone else to spoof. Each sending domain, including secondary ones, needs its own records.

How long do DNS changes take to apply?

Propagation depends on the TTL set on the record and on the resolver caching it. Verify with a lookup rather than assuming, and confirm each record resolves before connecting the domain to a sending platform.

SPF, DKIM and DMARC Setup for Cold Email

Authentication is the cheapest part of a cold email stack and the part that most often silently breaks. The records are three TXT entries in DNS, they take an afternoon, and they never need touching again. What goes wrong is rarely that someone skipped them. It is that all three exist, every online checker reports green, and mail still fails, because the records authenticate a domain that is not the one in the From: header.

This guide covers what each record does, how to publish it on a cold email sending domain, and how to verify the part the checkers do not always show.

Warm your inboxes once DNS is in place

What changed, and why it is not optional

Google and Yahoo announced a shared set of sender requirements in October 2023 with enforcement beginning February 2024, and Microsoft followed in May 2025. Enforcement is now active across all three, and non-compliant bulk mail is refused at the SMTP level with a permanent 550 rather than filed into a spam folder.

The formal bulk sender threshold is 5,000 messages per day per sending domain, and the classification is permanent once crossed. But the authentication requirement itself is broader: Google asks every sender for SPF or DKIM regardless of volume, and Yahoo asks for both. A modest cold email operation sending a few hundred messages a day is inside that rule.

Domains with no bulk sending history before January 2024 also face tighter scrutiny from the start, which describes almost every secondary domain registered for outreach.

SPF

SPF is a TXT record listing which servers may send mail for your domain. A receiving server looks up the record, compares it against the IP that delivered the message, and records a pass or fail.

A minimal record looks like this:

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

Three things matter in practice.

One record per domain. Two SPF records on the same domain is a permanent error, not a merge. If you add a sending platform, extend the existing record with another include: rather than publishing a second one.

The ten lookup limit. Every include:, a, mx and redirect costs a DNS lookup, and each of those can nest further lookups of its own. Past ten, evaluation stops and the result is a permanent error. Stacking a mailbox provider, a sequencing platform and a transactional service on one domain gets close to that ceiling quickly.

The final mechanism. ~all is a soft fail and -all is a hard fail. Soft fail is the safer starting point while you confirm that every legitimate sender is listed.

DKIM

DKIM signs each outgoing message with a private key held by your sending platform, and publishes the matching public key in DNS. The receiving server fetches the key and verifies the signature, which proves the message was not altered in transit and that the signing domain authorised it.

The record lives at a selector you do not choose yourself. Your mailbox provider or sending platform generates the key pair and tells you the selector and the value, and you publish it as selector._domainkey.yourdomain.com.

Two details worth checking. Key length matters: 1024-bit is the practical minimum and 2048-bit is preferable, while short legacy keys are rejected outright by Yahoo even when SPF and DMARC pass. And every service that sends on your behalf needs its own selector, so adding a platform means adding a record rather than editing the existing one.

DMARC

DMARC is a TXT record at _dmarc.yourdomain.com that does two things SPF and DKIM cannot do alone: it enforces alignment, and it reports failures back to you.

A starting record:

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

p is the policy applied to mail that fails. none means monitor and take no action, quarantine means deliver to spam, reject means refuse. rua is where aggregate reports are sent, and it is the reason to publish DMARC even below the threshold: without it you are guessing at why mail disappears.

Bulk senders are required to publish at least p=none. Current practice is to progress toward p=quarantine or p=reject once the reports confirm legitimate mail passes, because a permissive policy leaves the domain open to being spoofed by someone else.

Alignment, which is where stacks break

This is the part that catches people who did everything else correctly.

SPF and DKIM each answer a narrow question. SPF asks whether the sending IP was authorised by the envelope sender's domain. DKIM asks whether the signature is valid for the signing domain. Neither one looks at the From: address the recipient actually sees.

DMARC does. It compares the visible From: domain against the SPF domain and the DKIM signing domain, and it passes only if at least one of them matches. So if your platform sends from your address but signs with its own vendor domain, SPF passes, DKIM passes, and DMARC fails. Every checker reports three green records and mail still lands badly.

Two practical consequences. Publish DKIM on your own domain with your own selector rather than relying on the platform's shared signing domain, and check alignment specifically rather than trusting a record-presence check. The aggregate reports from rua are what show this, which is a second reason to publish DMARC early.

Custom tracking domains

Almost every sequencing platform rewrites links for click and open tracking, and by default those links point at a domain the vendor shares across its entire customer base. Every sender on that domain contributes to its reputation, including the ones sending badly.

Configuring a custom tracking domain moves the rewritten links onto a subdomain of your own, usually with a CNAME pointing at the vendor. It is a short change, and the certificate step is where it commonly falls over: the subdomain needs a valid certificate or the rewritten links break, which is worse than the shared domain it replaced.

What else the providers check

Authentication is necessary but not sufficient. The other requirements that cause rejections:

A valid PTR record, so the sending IP resolves back to a hostname.
TLS for transmission.
A spam complaint rate below 0.3%, with 0.1% the figure to aim for. Google Postmaster Tools is where you read it.
One-click unsubscribe headers on bulk marketing and promotional mail, honoured within two days.
A From: header that does not impersonate the mailbox provider.

Verification before you send

Work through this in order, and verify rather than assume:

Confirm exactly one SPF record resolves, and count the lookups it triggers.
Confirm the DKIM record resolves at the selector your platform generated.
Confirm the DMARC record resolves at _dmarc and that the reporting address receives mail.
Send a test message to a mailbox you control and read the received headers, checking that SPF, DKIM and DMARC each pass and that DMARC reports alignment.
Confirm the tracking subdomain resolves and serves a valid certificate.
Confirm the sending IP has a PTR record.

Only after that does warm-up make sense, because a warm-up network exercising a misconfigured domain builds reputation on a domain that will fail anyway.

Set up inbox warm-up

Where this sits in the stack

Authentication is layer two of four. The domains come first, warm-up and list verification follow, and the sending platform is the last decision rather than the first. The full sequence is in the complete cold email stack, and the layer that follows this one is covered in email warm-up tools and the WarmupInbox review.

On the platform side, deliverability controls differ meaningfully between tools, particularly around sending limits and inbox rotation. See the Woodpecker review and the wider best sales engagement software roundup.

Compare sending platforms