Cold email domain setup checklist: the six DNS records and the one redirect

Most cold email that lands in spam was doomed before the first send: a missing DKIM record, a DMARC policy that says "monitor only", two SPF records instead of one. None of those show an error anywhere. The mail simply goes to spam and the sender blames the copy. Here is the whole checklist for a domain hosted on Microsoft 365, with the values to paste.

Before the records: the right domain

Never the real one. Cold email goes from a look-alike you own — getacme.com or tryacme.com next to acme.com — so that if a campaign ever dents a reputation, it is never the domain your customers, invoices and password resets run on. Buy .com, no hyphens, no numbers. About $10 a year on Cloudflare.

Add it to Microsoft 365 (admin center → Settings → Domains → Add domain), pick "I'll add the DNS records myself", and paste the one verification TXT it gives you. Then stop following Microsoft's wizard and use the list below instead — the wizard's list is incomplete for cold email.

The records

The step everyone misses: enable DKIM

Adding the two CNAMEs is not enough. In Microsoft 365, DKIM signing for a custom domain is off until you turn it on: security.microsoft.com → Email & collaboration → Policies → Email authentication settings → DKIM → your domain → Enable. Until then, Microsoft signs your mail with its own onmicrosoft.com key, the signature does not align with your From domain, and DMARC at p=quarantine does exactly what you told it to: quarantines your own mail. This is the single most common reason a "fully configured" new domain lands in spam.

DMARC: quarantine, not none

p=none is monitoring. It tells receivers nothing about what to do with a spoofed message, and Google and Microsoft increasingly read it as "this sender has not finished setting up." Go to p=quarantine from day one on a new sending domain — there is no legacy mail to break — and read the reports that arrive at the rua address. Strict alignment (adkim=s; aspf=s) is fine here because only Microsoft sends for this domain.

The redirect

A curious prospect will type the domain into a browser. It must land on your real site, not a parking page or an error. In Cloudflare: Rules → Redirect Rules → dynamic redirect from getacme.com and www.getacme.com to https://acme.com, status 301. If the domain has no A record yet, add a proxied placeholder (192.0.2.1) so the rule has something to attach to.

Checklist

• Look-alike domain, .com, registered under your own account
• Added to Microsoft 365 and verified
• MX → mail.protection.outlook.com, priority 0
• Exactly one SPF record with -all
• Both DKIM CNAMEs present and DKIM enabled in Defender
• DMARC at p=quarantine with a rua address someone reads
• Redirect from the bare domain and www to your real site
• One licensed mailbox per person; ramp from 10 a day
• Domain added to Google Postmaster Tools once it has sent for a few days

Things that fail silently

Two SPF records (one from a website builder, one from Microsoft) — receivers treat that as a permanent fail. A DKIM CNAME with a trailing space pasted from a wiki. DMARC set on the real domain but not the sending domain. Cloudflare proxying (orange cloud) on the DKIM or autodiscover CNAMEs — turn the proxy off for every record in this list. A verification TXT record deleted after verification (harmless) versus the SPF TXT deleted by mistake (fatal). Check with a resolver you trust, then check again the next morning.