SPF, DKIM and DMARC for Cold Email: A Setup and Verification Guide

SPF says which servers may send, DKIM signs each message, DMARC decides what happens on failure. How to set all three up, align them, and verify they work.

Cold email deliverability starts with three DNS records. SPF says which servers may send for your domain, DKIM cryptographically signs each message, and DMARC tells receiving systems what to do when either one fails. All three have to be present, aligned, and actually verified, because a misconfiguration here bounces mail from perfectly valid addresses and no amount of good copy or clean data compensates for it.

Why Authentication Comes Before Everything Else

Most deliverability advice starts with content, volume, or list quality. Those matter, but they are downstream of a simpler question the receiving server asks first: can I prove this message is really from the domain it claims?

If the answer is no, nothing else gets evaluated. Your subject line, your targeting, your warmup history become irrelevant, because the message is being judged as potentially forged before anyone reads a word of it. This is also why authentication problems are so often misdiagnosed. The symptom looks like a list problem, so teams clean their list, and nothing improves.

The wider diagnosis of why cold outreach fails is covered in why B2B companies struggle with cold outreach deliverability. This article is the narrow technical layer underneath it: the three records, what each one does, how to align them, and how to confirm they work.

SPF: Which Servers Are Allowed to Send

SPF, Sender Policy Framework, is a DNS TXT record listing the servers authorised to send mail for your domain. A receiving server looks up that record and checks whether the connecting server appears in it.

A minimal record looks like this:

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

Read it left to right. v=spf1 declares the version. include: delegates to another domain's SPF record, which is how you authorise a provider without listing its IPs yourself. ~all is the policy for everything not listed.

Three things go wrong here more than anything else:

More than one SPF record on the domain. The specification allows exactly one. Two records is not additive, it is a permanent error, and receiving systems treat the whole check as failed. This happens constantly when a second sending tool is added and creates its own record instead of being merged into the existing one.
Exceeding ten DNS lookups. Each include: costs a lookup, and includes nest, so several providers can quietly blow the limit. Past ten, the check fails regardless of whether your sender was legitimate.
Using -all before you are certain. -all is a hard fail, ~all is a soft fail. Hard fail is stricter and better once your record is genuinely complete, and it will reject your own legitimate mail the moment you forget a sender. Start with ~all, move to -all after you have watched DMARC reports and confirmed nothing legitimate is failing.

DKIM: A Signature on Every Message

DKIM, DomainKeys Identified Mail, signs each outgoing message with a private key. The matching public key sits in DNS, and the receiving server verifies the signature against it.

SPF and DKIM answer different questions, which is why you need both. SPF asks whether the sending server was authorised. DKIM asks whether the message content was altered in transit and whether the signer holds the key. A forwarded message commonly breaks SPF while DKIM survives, so a domain with only SPF loses legitimate forwarded mail.

What to get right:

Use a 2048-bit key. Older 1024-bit keys still validate but are weak, and some providers weight key strength.
Give every sending service its own selector. A selector is the label in the DNS name, and separate selectors let each service rotate its key without touching the others.
Rotate keys periodically and remove the DNS records for services you no longer use. A stale public key for a decommissioned tool is a loose end.

DMARC: What Happens When a Check Fails

DMARC ties the first two together. It tells receiving systems what to do with a message that fails SPF and DKIM, and it asks them to report back on what they saw.

A starting record:

v=DMARC1; p=none; rua=mailto:dmarc@yourdomain.com; pct=100

The important part is p=, the policy, which has three values:

Policy	What receivers do on failure	When to use it
p=none	Deliver as normal, but report	Monitoring only. Where you start.
p=quarantine	Treat as suspicious, usually spam	Once reports show only real failures
p=reject	Refuse the message outright	The goal, once you are confident

Do not skip p=none. Going straight to reject on a domain whose senders you have not yet enumerated will silently destroy legitimate mail, including invoices and password resets, and you will not find out from the sender side. Run p=none, read the reports for a few weeks, fix what is failing, then tighten.

The rua= address receives aggregate reports as XML. They are unreadable by hand at any volume, so point them at a parser rather than a person's inbox.

Alignment: The Part That Silently Breaks

This is the concept that catches out people who have all three records in place and still fail DMARC.

DMARC does not just require that SPF or DKIM pass. It requires that the domain which passed aligns with the domain in the visible From address. A message can pass SPF against your sending provider's domain and still fail DMARC, because the domain the recipient sees is yours and the domain that authenticated was not.

In practice this means using a custom return-path or bounce domain on your own domain rather than the provider's default, so that the authenticated domain and the From domain match. Every serious sending platform supports this. It is a step people skip because everything appears to work until DMARC is enforced.

Alignment also comes in strict and relaxed modes. Relaxed, which is the default, accepts a subdomain matching the organisational domain. Strict requires an exact match. Relaxed is the right choice for almost everyone.

How to Verify, Rather Than Assume

Configuring the records is not the same as confirming they work. Three checks, in order:

Read the DNS directly. Query the TXT records for your domain, your DKIM selector, and _dmarc.yourdomain.com. Confirm there is exactly one SPF record and that it resolves within ten lookups. Do this against public DNS, not your registrar's dashboard, because propagation and typos both hide there.
Send a real message and read the received headers. Mail yourself at an external address on a different provider, then open the raw headers and find the Authentication-Results line. It states plainly whether SPF, DKIM, and DMARC passed, and what domain each one authenticated against. This is the only check that tests the whole path end to end, and the alignment problem above shows up here and nowhere else.
Repeat per provider and per sending domain. Gmail, Microsoft, and a corporate-hosted address will each tell you something slightly different. If you run separate outreach domains, and you should, every one needs its own pass. Authentication is per domain, so a correct primary domain tells you nothing about the others.

Then keep watching. DMARC aggregate reports are the only mechanism that tells you a sender you forgot about is failing, or that someone is sending as your domain.

What Authentication Will Not Fix

Being clear about the boundary, because correct records get oversold.

Authentication proves your mail is genuinely from you. It does not make it welcome. A perfectly authenticated domain sending irrelevant mail to a stale list will still land in spam, because engagement, complaint rate, and bounce rate are judged separately and carry real weight.

Think of it as a prerequisite rather than a lever. Without it you cannot win. With it you can still lose, on volume (how many cold emails you can safely send per day), on data quality (why list hygiene shows up in the numbers), or on concentrating everything into one domain (why infrastructure diversity matters).

It is also worth knowing that valid addresses bounce for infrastructure reasons that look exactly like data problems, which is the fastest way to waste a week cleaning a list that was fine: why good email addresses bounce.

A Setup Order That Does Not Break Anything

Inventory every service that sends as your domain before touching DNS. Marketing platform, CRM, helpdesk, invoicing, the outreach tool, and anything a single team set up on its own. The ones you miss are the ones that break later.
Build one SPF record covering all of them, ending in ~all, and check the lookup count.
Enable DKIM on each service with its own selector, using 2048-bit keys.
Publish DMARC at p=none with reporting to a parser.
Set a custom return-path per sending domain so SPF aligns with the From domain.
Read reports for two to four weeks and fix every legitimate failure you find.
Move to p=quarantine, then p=reject, and only then consider -all on SPF.

FAQ

Do I need all three records, or is SPF enough? All three. SPF alone breaks on forwarding, and without DMARC nothing instructs receivers what to do when a check fails, so failures are handled inconsistently and you get no reporting.

Can I have two SPF records if I use two sending providers? No. One record only, with both providers merged into it via include:. Two records is a permanent error that fails the whole check.

Why does my mail fail DMARC when SPF and DKIM both pass? Alignment. Something passed, but against a domain that does not match your visible From domain, usually your provider's default return-path. Set a custom return-path on your own domain.

How long until DNS changes take effect? Usually minutes to a few hours depending on the previous TTL. Verify against public DNS rather than trusting your registrar's panel, and re-send a test message rather than assuming propagation finished.

Should every sending domain have its own DKIM key? Yes. Authentication is per domain, and shared keys mean a compromise or rotation on one domain affects the others.

Is p=reject risky? It is risky before you have read your reports, and it is the correct destination afterwards. The risk is not the policy, it is enforcing it on a domain whose legitimate senders you have not finished enumerating.

Want authentication handled correctly across every sending domain without making it a project? Lidgen configures and monitors this layer per domain as part of the infrastructure, so it is verified rather than assumed. Book a demo.