Microsoft 365 email security setup

A Microsoft 365 tenant sends mail the moment you attach your domain, but it does not protect the domain's name for you. Four DNS records do: SPF, DKIM,DMARC, and MTA-STS. This is the exact setup we recommend for small-business tenants, in order.

1 · SPF: one TXT record

At your domain root (host @), publish exactly one SPF record:

• Anything else that sends as your domain (newsletter platform, CRM, ticketing, scan-to-email) needs its own include: before the -all.
• Keep it to under 10 DNS lookups and exactly one SPF record — two records means SPF fails entirely.
• Finish with -all (hard fail). ~all is acceptable during rollout; +all never is.

2 · DKIM: enable it, don't skip it

Microsoft 365 does not sign with your domain until you turn DKIM on — a fresh tenant signs with onmicrosoft.com, which doesn't align for DMARC.

1. Open the Defender portal → Email & collaboration → Policies & rules → Threat policies → Email authentication settings → DKIM.
2. Select your domain. Microsoft shows two CNAME records, selector1._domainkey and selector2._domainkey, pointing at your tenant. Add both to DNS exactly as shown.
3. Back in the portal, toggle Sign messages for this domain on. If it errors, DNS hasn't propagated yet — wait and retry.
4. Use 2048-bit keys. If your tenant is old enough to be on 1024-bit keys, rotate: the portal's rotate button generates 2048-bit replacements.

3 · DMARC: monitor, then enforce

Publish a TXT record at _dmarc.yourdomain.com:

1. Run p=none for 2–4 weeks and read the aggregate reports. Every legitimate sender must pass SPF or DKIM with alignment — this is where you catch the copier that scans to email and the marketing tool nobody mentioned.
2. Move to p=quarantine, then finish at p=reject — the only policy that actually stops direct-domain spoofing.
3. Don't leave a weaker subdomain policy (sp=) behind: spoofers will happily use billing.yourdomain.com.

4 · MTA-STS and TLS-RPT

Microsoft 365 receives your mail on *.mail.protection.outlook.com, which fully supports TLS — MTA-STS tells the world's mail servers to require it. Two records and one tiny hosted file:

Start with mode: testing if you're cautious, but don't stay there —testing mode enforces nothing. The policy file needs HTTPS hosting at mta-sts.yourdomain.com; a free static host (Cloudflare Pages, GitHub Pages) works fine.

The pitfalls we see most on M365 domains

• DKIM never enabled. The records exist, the toggle was never flipped. Mail still flows, so nobody notices — until DMARC enforcement starts quarantining your own newsletter.
• SPF blown past 10 lookups. Each vendor says "just add our include" and each include costs lookups. Over 10, SPF permanently errors.
• Stale verification TXT records from tools you stopped using years ago — tidy them up.
• DMARC parked at p=none forever. Monitoring mode is a phase, not a destination.

On Google Workspace instead? There's a guide for that too.