SPF, DKIM and DMARC for cold email: the complete setup

Email authentication is not optional any more. Google and Yahoo made it mandatory for bulk senders in 2024, Microsoft followed for high-volume senders in 2025, and the practical effect is that an unauthenticated domain sending cold mail now has close to no chance of consistent inbox placement.

The three records work together. SPF says which servers may send for your domain. DKIM cryptographically signs your mail so tampering is detectable. DMARC tells receivers what to do when the first two fail, and asks them to report back. Configure all three or the receiving side has no basis to trust you.

SPF: authorising your senders

SPF is a TXT record listing the infrastructure permitted to send mail for your domain. A receiver checks the sending IP against that list.

example.com.  IN TXT  "v=spf1 include:spf.protection.outlook.com -all"

The final mechanism is the one people get wrong. `-all` is a hard fail: mail from anywhere not listed should be rejected. `~all` is a soft fail, which tells receivers to accept unauthorised mail but mark it suspicious. Use `-all`. A soft fail undermines the entire purpose of publishing the record, and it weakens DMARC alignment downstream.

The ten-lookup limit

SPF permits a maximum of ten DNS lookups while evaluating a record. Every `include`, `a`, `mx`, `ptr` and `redirect` counts, and includes nest - so one include can consume several lookups on its own. Exceed ten and the result is a permerror, which most receivers treat as an outright SPF failure.

This bites teams who accumulate tools over time. A record with Microsoft, a CRM, a helpdesk, an ESP and an analytics platform is often already over the limit without anyone noticing, because nothing visibly breaks until deliverability degrades.

• Only one SPF record per domain is valid. Two TXT records both starting v=spf1 is a permerror, not a merge.
• Cold email domains should list only the platform sending the cold mail. Do not copy your corporate SPF record onto a sending domain.
• Check the lookup count after every change, not just when something breaks.

DKIM: signing what you send

DKIM attaches a cryptographic signature to each message using a private key held by your sending platform. The matching public key lives in DNS. A receiver fetches the key, verifies the signature, and knows both that you authorised the message and that its headers and body were not altered in transit.

On Microsoft 365 this is two CNAME records per domain, pointing at keys Microsoft publishes for your tenant.

selector1._domainkey.example.com.  IN CNAME  selector1-example-com._domainkey.tenant.onmicrosoft.com.
selector2._domainkey.example.com.  IN CNAME  selector2-example-com._domainkey.tenant.onmicrosoft.com.

Two selectors exist so keys can be rotated without an interruption: Microsoft signs with one while the other is being replaced. Publishing the CNAMEs is not sufficient on its own - DKIM signing must then be enabled for the domain in the Microsoft 365 Defender portal. This is the single most common gap we see. The records are present, everything looks configured, and no mail is actually being signed.

DMARC: policy and visibility

DMARC ties the other two together. It tells receivers what to do with mail that fails authentication, and it requests aggregate reports so you can see who is sending as your domain. Once a policy is published you can confirm it with the free DMARC checker.

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

Start at `p=none`. It enforces nothing, but it turns on reporting, and the reports are the point. Read them for two weeks and confirm your legitimate mail is passing and aligning. Only then tighten.

1. p=none for two weeks, reading aggregate reports to confirm legitimate mail aligns.
2. p=quarantine, which sends failing mail to spam rather than rejecting it.
3. p=reject once you are confident, which refuses failing mail outright.

Moving straight to `p=reject` without reading reports is how teams discover, by way of a customer complaint, that their invoicing system was sending as the domain and is now being refused.

Alignment is the part that catches people

DMARC does not merely require SPF or DKIM to pass. It requires one of them to pass *and* to align with the domain in the From header. Mail can pass SPF against a sending platform's own domain and still fail DMARC, because the passing domain is not the domain your recipient sees. This is why "SPF passes" is not the same statement as "DMARC passes", and why checking only the former misses real failures.

The failures we see most often

• DKIM CNAMEs published but signing never enabled in the admin portal - looks correct, signs nothing.
• Two SPF records on one domain, which is a permerror rather than a combination.
• SPF using ~all instead of -all, weakening both SPF and DMARC alignment.
• DMARC rua pointing at a mailbox nobody monitors, so failures accumulate unseen.
• The ten-lookup limit exceeded after adding one more tool.
• Records published on the root domain but mail sent from a subdomain with no records of its own.

Verifying before you send

Never assume a record is working because it exists. Query it, send a test message to a mailbox you control on the platform you are targeting, and read the received headers to confirm all three checks pass and align.

dig +short TXT example.com                     # SPF
dig +short CNAME selector1._domainkey.example.com   # DKIM
dig +short TXT _dmarc.example.com              # DMARC

Our free DNS records checker runs all three at once and reports what is missing or malformed, which is faster than reading dig output when you are checking a batch of domains.

If you would rather not do any of this by hand, it is what we provide. Every inbox we hand over has SPF, DKIM and DMARC configured and verified before you receive it, so the first message you send is authenticated properly rather than being a test of whether the setup took. Authentication only decides whether you are eligible for the inbox - how much you send per mailbox decides whether you stay there.