Configure Microsoft 365 for DMARC alignment

Microsoft 365 passes DMARC through DKIM once signing is enabled for your custom domain. Without custom DKIM, Microsoft signs mail with onmicrosoft.com keys, which won't produce DMARC alignment for your domain.

Enable DKIM signing in Microsoft 365

1. Go to Microsoft 365 Defender > Email & collaboration > Policies & rules > Threat policies > Email authentication settings.
2. Select the DKIM tab.
3. Select your custom domain from the list.
4. Click Enable to start DKIM signing.

Microsoft will show you two CNAME records to publish before you can enable signing. They look like:

selector1._domainkey.yourdomain.com  CNAME  selector1-yourdomain-com._domainkey.yourtenant.onmicrosoft.com
selector2._domainkey.yourdomain.com  CNAME  selector2-yourdomain-com._domainkey.yourtenant.onmicrosoft.com

Publish both CNAME records in your DNS provider, wait for propagation, then return to the Defender portal and click Enable. Microsoft rotates between these two selectors automatically.

Verify DKIM is active

After enabling, Microsoft 365 shows a status of Enabled in the DKIM settings panel. You can also use the DKIM check tool to confirm both selectors resolve correctly.

Check a sent message's headers for a DKIM-Signature header with d=yourdomain.com to confirm signing is active end to end.

SPF: add the Microsoft include

If you don't have an SPF record, create one:

yourdomain.com  TXT  "v=spf1 include:spf.protection.outlook.com ~all"

If you have an existing SPF record, add the include to it:

"v=spf1 include:spf.protection.outlook.com include:other-provider.com ~all"

Keep your SPF record under the 10-lookup limit. spf.protection.outlook.com resolves to multiple nested includes, so it counts as several lookups. If your record is already near the limit, removing redundant includes or flattening the record may be necessary.

The onmicrosoft.com alignment problem

If DKIM signing is not enabled for your custom domain, Microsoft signs outbound mail with keys from yourtenant.onmicrosoft.com. This produces DKIM alignment for onmicrosoft.com, not for your domain. SPF alone won't save this: the envelope sender for Microsoft 365 mail passes SPF for onmicrosoft.com, not for your custom domain.

The result in DMARCdrift reports: Microsoft traffic appears with DMARC failures, even though the mail was legitimately sent through Microsoft 365.

The fix is to enable custom DKIM as described above. Once custom DKIM is active, Microsoft signs with your domain's keys and DMARC alignment will pass.

Connectors and third-party relays

If you relay mail through a third-party service before it reaches Microsoft 365 outbound (for example, a compliance or archiving relay), the DKIM signature from Microsoft may be invalidated if the relay modifies message headers or body content. In this case, the relay needs to re-sign with your domain's keys.

Microsoft 365 connectors for inbound mail (external sources routing through Exchange) don't affect DKIM signing for your outbound mail and don't require special DMARC configuration.

What Microsoft aggregate reports cover

Microsoft sends aggregate reports from dmarcreport@microsoft.com. They cover mail Microsoft received claiming to be from your domain: your Microsoft 365 outbound, any other services sending on your domain that reached Outlook or Hotmail recipients, and unauthorized senders targeting Microsoft recipients.

Microsoft reports are typically reliable and arrive within 24-48 hours. They use the domain-level view: each report covers one reporting period (usually 24 hours) across all traffic from that domain to Microsoft recipients.

Next: Postmark setup: DKIM records and SPF alignment for transactional email.

See also: DKIM alignment: why DKIM is the preferred alignment path. Relaxed vs strict alignment: how organizational domain matching works for Microsoft's subdomain signing.