How to set up DMARC on Microsoft 365 (step by step)

Microsoft 365 sends your mail, but out of the box it signs with Microsoft's shared onmicrosoft.com identity — which does not count for DMARC on your domain. Here is the full setup in four steps, in plain English.

Check what your domain has today — free, no signup

Step 1: verify your SPF record

One TXT record on your root domain authorizing Microsoft's servers:

Type: TXT
Host: @  (yourdomain.com)
Value: v=spf1 include:spf.protection.outlook.com -all

If other services also send as your domain (marketing platform, invoicing tool), add their include: to the same record — you may have only one v=spf1 record, and it must stay under 10 DNS lookups.

Step 2: enable custom DKIM in the Defender portal

This is the step most Microsoft 365 domains are missing.

1. Open security.microsoft.com and go to Email & collaboration > Policies & rules > Threat policies > Email authentication settings > DKIM.
2. Select your custom domain. The portal shows two CNAME records to publish, shaped like:

selector1._domainkey.yourdomain.com
  → selector1-yourdomain-com._domainkey.<tenant>.onmicrosoft.com
selector2._domainkey.yourdomain.com
  → selector2-yourdomain-com._domainkey.<tenant>.onmicrosoft.com

3. Publish both as CNAME records (not TXT — the portal gives you the exact targets for your tenant).
4. Wait for DNS to propagate, come back, and flip Sign messages for this domain with DKIM signatures to on. If the toggle errors, DNS hasn't propagated yet — wait and retry.

Until you flip that toggle, Microsoft signs your mail as <tenant>.onmicrosoft.com. The signature is valid — dkim=pass — but it does not align with your domain, so it does nothing for DMARC.

Step 3: publish the DMARC record

A TXT record at the _dmarc host:

Type: TXT
Host: _dmarc  (_dmarc.yourdomain.com)
Value: v=DMARC1; p=none; rua=mailto:reports@yourdomain.com

p=none changes nothing about delivery yet — it switches on the daily aggregate reports that show which sources pass and fail. Point rua at a mailbox you'll actually process, or at a monitoring service. You can assemble the record with our free DMARC generator.

Step 4: verify, monitor, then tighten

Confirm the records exist:

dig +short TXT yourdomain.com
dig +short CNAME selector1._domainkey.yourdomain.com
dig +short TXT _dmarc.yourdomain.com

Send a test message to a Gmail address you control and open Show original: you want spf=pass, dkim=pass with header.d=yourdomain.com (not onmicrosoft.com), and dmarc=pass. If DMARC still fails, it's an alignment issue — see why DMARC fails and how to fix it. If no reports show up within 48 hours, see not receiving DMARC reports.

Then watch your reports for a few weeks. When every legitimate source passes aligned, move to p=quarantine, and finish at p=reject — the only setting that actually stops spoofing. The trade-offs at each level are covered in p=none vs quarantine vs reject.

Common Microsoft 365-specific mistakes

• Publishing the CNAMEs but never flipping the signing toggle. The records exist in DNS, but Microsoft keeps signing as onmicrosoft.com until you enable it in the portal.
• Publishing the selectors as TXT records. Microsoft 365 uses CNAMEs that point at keys Microsoft rotates for you — a TXT copy will break silently at the next rotation.
• Reading dkim=pass as job done. A pass for onmicrosoft.com is worthless for your DMARC; check the header.d= domain, not just the verdict.
• Forgetting non-Microsoft senders. Exchange Online being clean doesn't cover your newsletter or invoicing tools — each needs its own DKIM alignment, which your aggregate reports will surface.

On a different provider? The same walkthrough exists for Google Workspace, Zoho Mail, Amazon SES, and Mailgun. And if Outlook.com is bouncing your mail right now with 550 5.7.515, start with that fix — it's this setup under deadline pressure.