Blog / Guides

SPF, DKIM and DMARC: A Setup Checklist for Cold Email

16 May 2026

To set up email authentication for cold email, publish three DNS records in order: SPF to list which servers may send for your domain, DKIM to cryptographically sign each message, and DMARC to tell receivers what to do when the first two fail. Add them per sending domain, start DMARC at p=none, then verify all three pass on a real test send before you start sending volume.

Why all three, not one

The three records do different jobs, and mailbox providers expect to see all of them. SPF (Sender Policy Framework) checks that the sending server is authorised. DKIM (DomainKeys Identified Mail) proves the message was not altered in transit and genuinely comes from the signing domain. DMARC (Domain-based Message Authentication, Reporting and Conformance) ties the two together and sets the policy for handling failures.

Since February 2024, Google and Yahoo require bulk senders to pass SPF and DKIM and to publish a DMARC record, plus one-click unsubscribe and a low spam-complaint rate (commonly cited as under roughly 0.3%). For cold email this is not optional hygiene — missing or broken authentication is one of the fastest routes to the spam folder.

Record	Question it answers	Without it
SPF	Is this server allowed to send for the domain?	Mail from your real path may fail authentication
DKIM	Was the message tampered with, and is the domain genuine?	No verified signature; weaker trust signal
DMARC	What happens when SPF or DKIM fails?	Receivers decide on their own; you get no reports

The setup checklist

Work through these in order. Each step links to a deep-dive if you want the detail.

1. Publish one SPF record per domain

Add a single TXT record at the domain root. List only the services that actually send for the domain, and end it in ~all or -all. For a Microsoft 365 setup with no other senders, the record is usually:

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

The two classic mistakes are publishing two v=spf1 records (which is a permerror, not extra coverage) and exceeding the 10 DNS-lookup limit by stacking includes. Keep it to one record, under ten lookups. The full detail is in the SPF record guide.

2. Enable and publish DKIM

Turn on DKIM in your mail platform, then publish the public key it gives you as a DNS record at the selector host (for Microsoft 365, two CNAME records pointing at the tenant’s keys). Once published, the platform signs outgoing mail and receivers verify the signature against the key in DNS.

DKIM is what proves the message body and key headers were not changed after signing. Get the selector and key exactly as the platform specifies — a typo here means silent dkim=fail. See the DKIM for cold email guide for selectors and key rotation.

3. Add a DMARC record at p=none

DMARC depends on the first two records, so publish it last. Add a TXT record at _dmarc.yourdomain.com. Start with a monitoring-only policy:

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

p=none publishes a valid policy and starts the aggregate reports flowing to your rua address without changing how any mail is handled. This is the right starting point for cold email: you confirm SPF and DKIM are aligned before tightening anything. Moving to p=quarantine or p=reject is a separate later decision, covered in the DMARC for cold email guide.

4. Understand alignment

DMARC does not just check that SPF and DKIM pass — it checks alignment. SPF aligns when the envelope-sender domain matches the visible From domain; DKIM aligns when the signing domain matches. A message can pass raw SPF yet still fail DMARC because the domains do not line up. At least one of SPF or DKIM must both pass and align for DMARC to pass.

This is why “I have all three records” is not the same as “all three pass.” Alignment is the step people skip.

5. Test a real send, then read the headers

This is the step that catches everything the previous four miss. Send an actual message from your sending domain to a test inbox you control, open the original message, and read the Authentication-Results header. You want to see:

spf=pass dkim=pass dmarc=pass

A record existing in DNS proves nothing about your actual sending path. The common failure is a domain that “has SPF” but lists the wrong source, so the record is present and still fails for real mail. Confirm passes on a live send — more on this in how to test cold email deliverability.

6. Repeat per sending domain

Cold email runs on dedicated secondary sending domains, not your primary domain, and each one needs its own SPF, DKIM and DMARC. There is no shared authentication across domains — a correct setup on one tells you nothing about the next. Bake this checklist into your cold email domain setup so no domain goes live unauthenticated.

Common mistakes to avoid

Mistake	Result	Fix
Two SPF records on one domain	permerror, SPF fails	Merge into a single v=spf1 record
Over 10 SPF DNS lookups	permerror, SPF fails	Trim unused includes or flatten to IPs
DKIM selector or key typo	silent dkim=fail	Copy the platform’s values exactly
DMARC published before SPF/DKIM work	reports show failures you cannot explain	Publish DMARC last, start at p=none
Records exist but never tested	mail still lands in spam	Verify pass on a real send

Authentication is necessary but not sufficient. Even a clean pass on all three will not save mail from going to spam if the domain reputation, content or sending volume is wrong — it is the foundation, not the whole house.

How Mailionaire approaches this

Every sending domain Mailionaire provisions gets SPF, DKIM and DMARC written and verified automatically inside its own isolated Microsoft 365 tenant, so there is no record-order trap, no second-SPF mistake and nothing to copy by hand. The DMARC policy ships at p=none, in line with the conservative starting point above, and it is all part of the flat $50 per active domain per month. See how it works for the full provisioning flow.

FAQ

In what order should I set up SPF, DKIM and DMARC?

Publish SPF first so receivers know which servers may send for the domain, then enable DKIM so messages carry a verified signature, then add DMARC last because it depends on the other two. DMARC only passes when SPF or DKIM aligns with the From domain, so the first two have to be working before DMARC means anything.

What DMARC policy should cold email start with?

Start with p=none. It publishes a valid DMARC record and lets you collect reports without affecting delivery while you confirm SPF and DKIM are aligned. Many senders stay at p=none for cold email; moving to p=quarantine or p=reject is a separate, later decision once you are certain every legitimate source passes.

How do I know my SPF, DKIM and DMARC are actually working?

Send a real message to a test inbox and read the received headers. They should show spf=pass, dkim=pass and dmarc=pass for your sending domain. A record existing in DNS is not proof it passes — only an authenticated test send confirms the full path works end to end.

Does passing SPF, DKIM and DMARC make my cold email legal?

No. These are technical authentication checks, not legal permission to send. Whether you may email someone depends on the recipient's jurisdiction — Germany's UWG §7(2) generally requires prior opt-in for advertising email, including B2B. The sender stays responsible. This is not legal advice.

---