How to Set Up SPF, DKIM & DMARC for Microsoft 365

Microsoft 365 will happily send mail for your domain the moment you finish onboarding — but it won't authenticate it the way DMARC needs until you do three things by hand. And the one that trips up almost everyone is DKIM: M365 signs your mail by default, just not as your domain. The result is a setup that looks complete and still fails alignment.

This is the companion to Microsoft's sender requirements — the why. Here's the how: the exact records, in order, with the portal step that actually switches DKIM on.

What Microsoft 365 authenticates by default

When you added your domain to Microsoft 365, you created an MX record pointing at Exchange Online Protection and, usually, an SPF record. That gets mail flowing. Two gaps remain:

• DKIM for your domain. M365 signs outbound mail automatically — but with a key on your tenant's yourtenant.onmicrosoft.com domain. For DMARC, the signing domain has to align with your visible From:, and onmicrosoft.com doesn't. You have to enable custom-domain DKIM explicitly.
• A DMARC policy. M365 never publishes one for you. Without it, receivers have no instruction when authentication fails.

Three DNS records and one portal toggle fix it. Budget an hour, plus propagation time.

Step 1 — SPF for Exchange Online

Publish a single SPF TXT record on your root domain authorizing Microsoft's mail servers:

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

Two rules:

• One SPF record only. If you already have one for another sender, merge include:spf.protection.outlook.com into it — never publish a second v=spf1.
• Watch the 10-lookup limit. Each include: counts. If you route through several services, you can exceed it and invalidate SPF; the free DMARC generator and an SPF check will flag it.

Use -all (hard fail) once you're confident every sender is listed; ~all is a safe interim.

Step 2 — Enable DKIM signing for your domain

This is the step that's easy to leave half-done. M365 uses CNAME-based DKIM — you publish two CNAMEs that point at Microsoft, and Microsoft manages the keys (including rotation) behind them.

Publish these two records, replacing the GUID and tenant with yours (the GUID matches the one in your MX record):

selector1._domainkey   CNAME   selector1-<domainGUID>._domainkey.<tenant>.onmicrosoft.com
selector2._domainkey   CNAME   selector2-<domainGUID>._domainkey.<tenant>.onmicrosoft.com

Then turn signing on:

1. Go to the Microsoft Defender portal (security.microsoft.com).
2. Email & collaboration → Policies & rules → Threat policies → Email authentication settings → DKIM.
3. Select your domain and toggle Sign messages for this domain with DKIM signatures to Enabled.

The gotcha: the toggle fails if the two CNAMEs aren't published yet — you'll get a "CNAME record doesn't exist" error. Publish the records first, give DNS time to propagate, then enable. Until you flip that toggle, your mail keeps signing as onmicrosoft.com and keeps failing alignment. For the mechanics of why the signing domain matters, see what DKIM is.

Step 3 — Publish DMARC

Add a TXT record at _dmarc on your root domain, starting in monitor mode:

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

p=none changes nothing about delivery — it asks receivers to send aggregate reports so you can see who's sending as your domain before you enforce. Point rua= at an address or tool someone actually reads.

Verify alignment before you enforce

Passing SPF or DKIM isn't the same as DMARC passing — the authenticated domain has to align with your From:. Once custom-domain DKIM is signing, your M365 mail aligns. But third-party senders that relay through or alongside M365 — a CRM, a ticketing system, a marketing platform — often won't until you configure each one. The DMARC alignment explainer covers how to read this.

So before tightening, watch your aggregate reports until every legitimate source authenticates and aligns. Then move in stages: p=none → p=quarantine → p=reject. Done right, enforcement day is a non-event.

Microsoft 365 gotchas

• DKIM enabled but CNAMEs missing. The toggle errors out — publish both CNAMEs first, then enable.
• Still signing as onmicrosoft.com. That means custom-domain DKIM was never switched on. Re-check the Defender toggle.
• Hybrid / on-prem mail. If you also send from on-premises servers, add their IPs to SPF — Exchange Online's include alone won't cover them.
• Third-party senders via M365. Apps sending "as" your domain need their own alignment; the M365 setup doesn't authenticate them for you.
• Jumping to p=reject early. Without clean reports first, you'll block your own mail. Earn enforcement with evidence.

Frequently asked questions

Does Microsoft 365 enable DKIM by default? Not for your custom domain. Microsoft 365 signs outbound mail with a default key on your *.onmicrosoft.com domain, which doesn't align to your real domain for DMARC. You have to enable DKIM signing for each custom domain in the Defender portal and publish two CNAME records before it signs as you.

What SPF record does Microsoft 365 need? Add include:spf.protection.outlook.com to your domain's single SPF TXT record — for example, v=spf1 include:spf.protection.outlook.com -all. If you send from other services too, merge their includes into the same record and stay under the 10-lookup limit.

---

Once SPF, custom-domain DKIM, and DMARC are all in place and your reports are clean, the job shifts to monitoring — catching the next service someone connects to M365 before it fails silently. That's what DDMARC is for: readable reports instead of raw XML, and an alert when a new sender appears.