Set up DMARC with Microsoft 365

Microsoft 365 authenticates your email with the same three building blocks as everyone else, but its DKIM does not work like the others: it relies on two CNAME records pointing at your tenant rather than a key published directly in your zone.

SPF

One SPF TXT record per domain, including Exchange Online:

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

If other services send for this domain — a billing tool, an email platform, an application server — add their mechanisms to that same record. Two SPF records on one domain is a misconfiguration that invalidates both.

DKIM

Publish two CNAMEs — Microsoft rotates keys between the two selectors, so both are needed from the start:

selector1._domainkey  CNAME  selector1-<domain-with-dashes>._domainkey.<tenant>.onmicrosoft.com
selector2._domainkey  CNAME  selector2-<domain-with-dashes>._domainkey.<tenant>.onmicrosoft.com

Two substitutions to get right: <tenant> is the prefix of your initial .onmicrosoft.com domain, and <domain-with-dashes> is your domain with dots replaced by dashes — example.com becomes example-com.

Once the CNAMEs have propagated, enable signing in the Microsoft Defender portal (Email & collaboration → Policies & rules → Threat policies → Email authentication settings → DKIM), domain by domain. While the toggle is off, the records exist and nothing is signed.

DMARC

Publish the monitoring policy on _dmarc.yourdomain.com:

v=DMARC1; p=none; rua=mailto:your-address@yourdomain.com

Stay there long enough to identify every legitimate sender before tightening. The progression, step by step.

Common mistakes with Microsoft 365

• CNAMEs published but DKIM never enabled in the portal: the most common case, and nothing in DNS signals it.
• The initial onmicrosoft.com domain needs no configuration — it is signed out of the box. It is your custom domain that needs these records.
• Outbound connectors and applications relaying through Exchange Online (authenticated SMTP, application relay) do not always align the visible domain with the authenticating one — check the reports rather than assume.
• Sharing a domain with another tenant, or a migration in progress, produces transient alignment failures that have nothing to do with spoofing: all the more reason to stay on p=none at first.

Once it is in place, Clarsend reads your reports and shows you what passes, what fails, and who is sending without your knowledge — without opening a single XML file.