The short version

Microsoft 365 signs mail from your onmicrosoft.com domain automatically, but it doesn’t DKIM-sign mail from your own domain, example.com, until you turn DKIM on for it. Until then DMARC has only SPF to go on, and SPF breaks whenever mail is forwarded. Publish the two CNAME records Microsoft gives you, then switch signing on.

Why it matters for DMARC

DMARC passes when SPF or DKIM passes for the domain in the From address. Without DKIM, mail from you@example.com sent through Microsoft 365 passes DMARC on SPF alone. That holds until the message is forwarded: a mailing list, a forwarding rule or a university alias sends it on from a server that isn’t in your SPF record, SPF fails, and with no DKIM signature DMARC fails with it. At p=reject that message is refused.

Microsoft says it plainly in its DKIM guide: for custom domains, “currently, no DKIM signing occurs for outbound mail”, and “a message needs to be DKIM signed by the domain in the From address”.

Check whether your domain is signed

Send a message from Microsoft 365 to an outside mailbox and open its headers. Look for DKIM-Signature:

  • There, with d=example.com: you’re signed with your own domain. The s= tag is the selector, usually selector1 or selector2.
  • Missing, or with a different d=: your own domain isn’t signing.

In the aggregate reports the same thing shows as Microsoft 365 traffic that is SPF-aligned but not DKIM-aligned. The DKIM Inspector shows whether a selector’s key is published.

Turn it on

  1. Get the two records. In the Microsoft Defender portal, go to Email & collaboration, Policies & rules, Threat policies, Email authentication settings, then the DKIM tab, and select your domain. It shows two CNAME records, one per selector:

    selector1._domainkey.example.com  CNAME  selector1-example-com._domainkey.<your tenant>.<letter>-v1.dkim.mail.microsoft
selector2._domainkey.example.com  CNAME  selector2-example-com._domainkey.<your tenant>.<letter>-v1.dkim.mail.microsoft

    Copy the values exactly as the portal shows them. Older tenants may show targets under onmicrosoft.com instead; either is right if it is what the portal gives you.

  2. Publish both at your DNS provider. Two records, because Microsoft rotates between the selectors: one signs, the other waits for the next rotation.

  3. Switch signing on. Back on the DKIM tab, turn the toggle for the domain to Enabled once the records resolve. It can take a while for new DNS records to be seen.

  4. Check again. Send another message and confirm d=example.com in the DKIM-Signature header.

In Exchange Online PowerShell, Get-DkimSigningConfig shows the two CNAME targets, and New-DkimSigningConfig creates a configuration with -KeySize 1024 (the default) or 2048. Use 2048.

Things that catch people out

  • Every sending domain needs its own. A subdomain you send from, such as billing.example.com, needs its own DKIM configuration.
  • Parked domains need none. Don’t publish DKIM for a domain that sends no mail; publish v=DMARC1; p=reject and an SPF record of v=spf1 -all instead.
  • It covers Microsoft 365 only. Your CRM, newsletter platform and helpdesk sign with their own keys, and each needs setting up separately; see auditing third-party senders.

Once Microsoft 365 is signing as your domain, it is one sender off the list on the way to p=reject.