A domain you’re about to use for cold email starts with zero sending history and zero trust. Mailbox providers have no reason to believe anything sent from it, and the authentication records you publish before the first send are what starts building that trust correctly instead of digging a hole you spend months climbing out of.

This is the order that works, in the sequence it actually needs to happen, plus the mistakes that show up almost every time someone skips a step.

Why sequence matters here

SPF, DKIM and DMARC aren’t three independent boxes to check — DMARC specifically depends on the other two already being correct, because DMARC doesn’t authenticate anything itself. It’s a policy layer that reads SPF and DKIM results and decides what to do when they disagree with the From: address. Publish DMARC before SPF and DKIM are solid and you’re building a policy on top of a foundation you haven’t tested yet.

The order:

SPF — declare which servers are allowed to send as your domain.
DKIM — sign your outgoing mail so receivers can verify it wasn’t altered in transit and genuinely came from you.
DMARC at p=none — start watching what happens, change nothing yet.
Watch — read the reports until you can name every sending source.
Climb — move to p=quarantine, then p=reject, once you trust what you’re seeing.

Step 1: SPF

SPF (Sender Policy Framework) is a DNS TXT record listing which mail servers are authorized to send as your domain:

v=spf1 include:_spf.yourprovider.com -all

For a new cold-email domain, the include is usually whichever sending platform or SMTP relay you’re actually using — get this exact, since a missing include is the single most common reason a legitimate send fails SPF on day one. -all at the end is a hard fail for anything not listed; some guides recommend ~all (soft fail) while you’re still confirming every source, tightening to -all once you’re confident the list is complete. The full mechanics, including why you can only have one SPF record per domain and what happens when two get merged incorrectly, are in SPF records explained.

Step 2: DKIM

DKIM (DomainKeys Identified Mail) adds a cryptographic signature to outgoing mail, verified against a public key published in DNS. Your sending platform generates the key pair and gives you the DNS record to publish — typically a selector._domainkey.yourdomain.com TXT record.

Two things trip up new domains specifically:

Using the platform’s shared signature instead of your own selector. Some tools sign with their own domain by default until you explicitly set up custom-domain DKIM. That still passes DKIM, technically, but it’s signing as them, not you — worth confirming explicitly rather than assuming.
Publishing the record with the wrong selector name. DKIM records are keyed by selector, and a typo here fails silently — the record exists, it’s just never checked, because nothing points at it.

DKIM explained: selectors and keys covers selector rotation and the multi-key setup you’ll eventually want once you’re sending at real volume.

Step 3: DMARC at p=none

Only once SPF and DKIM are confirmed working does DMARC belong in the picture — and it belongs at p=none first, every time, with no exception for a domain that “should” be clean because it’s brand new:

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

p=none takes no action on failing mail. What it does is turn on reporting — the rua tag is what actually matters in this phase, because without it you’re publishing a policy that observes nothing for nobody. Build this record correctly, including the alignment and reporting tags most guides skip, with the free DMARC record generator.

Skipping straight to p=quarantine or p=reject on a domain you haven’t watched yet is the single most common way a new-domain launch actually goes wrong. There’s no legitimate sending history to compare against yet — you don’t know if your own infrastructure is fully aligned, and a brand-new domain enforcing a policy it hasn’t verified can end up blocking its own mail before it ever reaches a prospect.

Step 4: watch before you touch anything else

Give the domain real time at p=none before changing the policy or ramping send volume — long enough to see a full reporting cycle and confirm every source appearing in your aggregate reports is one you recognize. How to read DMARC reports walks through the raw XML, and the full climbing checklist — what “ready to move” actually means, not just “it’s been a week” — is in p=none vs p=quarantine vs p=reject.

This is also the window to run a full authentication check rather than testing SPF, DKIM and DMARC one at a time. The domain health checker validates all three together along with MX and blocklist status, which catches the case where each record is individually correct but something in the combination still isn’t aligned.

Step 5: climb, once you can name every source

Move to p=quarantine, then eventually p=reject, only once you can account for every sending source in your reports and your legitimate mail is passing consistently. Use pct= to apply a new policy to a fraction of mail first — p=quarantine; pct=25 — so a misconfiguration costs you a quarter of your traffic instead of all of it while you confirm the move was safe.

Common first-week mistakes

Publishing DMARC before SPF or DKIM are confirmed. DMARC has nothing to evaluate if the layers underneath it aren’t already working, and the reports you get back will mostly tell you about problems you should have caught earlier.
Two SPF records instead of one. A domain can only have a single SPF TXT record; a platform’s setup instructions plus a leftover record from a previous provider is a common way to end up with two, which most validators treat as a permanent SPF failure regardless of what either record says.
Sending real cold email volume before the domain has any age or reputation. DMARC setup and domain warmup are separate concerns — correct authentication doesn’t substitute for the gradual, patient volume ramp a new domain still needs before it can carry cold-email volume without triggering spam filters.
Treating p=none as “DMARC is done.” It’s the starting line, not the finish. A domain parked at p=none indefinitely gets the reporting benefit and none of the actual protection against spoofing.
Forgetting subdomains. If you’re sending cold email from a secondary domain or subdomain separate from your primary corporate domain, each needs its own SPF and DKIM setup — DMARC policy inheritance from the organizational domain doesn’t substitute for a subdomain having its own working authentication. And regardless of which domain you send from, the underlying bulk-sender bar is the same one Gmail and Outlook both enforce — see Gmail & Outlook sender requirements for the full checklist.
Not checking again after the first pass. Authentication that was correct on day one can silently break — a DNS change, a new tool someone connects, a TTL-related propagation issue nobody caught. Re-run the domain health checker periodically, not just once during setup.

The realistic timeline

For a genuinely new domain: SPF and DKIM can be correct within a day. DMARC at p=none should sit and collect reports for at least a few weeks before you seriously consider moving it — long enough to catch sources that don’t send daily. Only after that does it make sense to start ramping actual cold-email volume in parallel with the climb toward enforcement, rather than treating authentication setup and sending volume as two separate projects that happen to share a launch date.

Do the sequence in order, watch before you act, and a brand-new domain earns the trust it needs to actually land in the inbox instead of spending its first weeks fighting authentication problems it created for itself.