Microsoft 365 DKIM signing uses CNAME records in your DNS pointing to keys Microsoft manages. When it’s working, every outbound email from your Exchange Online tenant is signed with your domain’s DKIM key. When it stops, nothing bounces — mail continues to deliver — but DMARC alignment fails silently.
The only way to detect this without actively looking is to review DMARC aggregate reports, which show DKIM pass/fail rates by source. Most organisations aren’t reviewing these regularly.
Common causes
Licence migration. Moving between Microsoft 365 licence tiers — particularly migrations that change the underlying service plan — can reset DKIM signing configuration. The Exchange Admin Center may still show DKIM as “enabled” even though signing has stopped. We’ve worked this exact incident: a NSW financial services firm whose DKIM signing stopped after a licence migration and stayed broken for three weeks before anyone read the DMARC reports.
Custom domain changes. Adding or removing a custom domain, or changes to domain federation settings, can disrupt DKIM signing for existing domains on the tenant.
Selector rotation failure. Microsoft periodically rotates DKIM signing keys. If the rotation fails — usually because the CNAME records in DNS haven’t been updated — signing stops. No alert, no bounce, nothing until you check.
DKIM never enabled. DKIM for custom domains on Exchange Online is not automatic. When you add a custom domain, you must publish the CNAME records Microsoft provides and explicitly enable DKIM in the Exchange Admin Center — our Microsoft 365 DKIM setup guide walks through the full process. Many M365 tenants have had DKIM disabled since initial setup.
How to check
In the Exchange Admin Center: go to Email authentication → DKIM. Select your domain and confirm the status shows Enabled and the CNAME records are correctly published.
The two default M365 DKIM selectors are selector1._domainkey.yourdomain.com and selector2._domainkey.yourdomain.com. Both should return a valid DKIM public key. If either is missing from DNS, signing will fail for messages using that selector.
Alternatively, run your domain through the Email Authentication Checker — it resolves DKIM selectors and tells you whether they’re returning valid keys.
Reading DKIM in the message headers
The Exchange Admin Center reports configuration state. The message headers report what actually happened, which is the thing you care about. Send a test message to an external mailbox and view the raw source.
Two headers matter. The receiving server writes Authentication-Results:
Authentication-Results: mx.google.com;
dkim=pass header.d=yourdomain.com;
spf=pass smtp.mailfrom=yourdomain.com;
dmarc=pass header.from=yourdomain.comAnd the signing server writes DKIM-Signature:
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=yourdomain.com; s=selector1;
h=from:subject:date:message-id; bh=...; b=...The field that decides DMARC is d=. It is the domain that owns the
signature, and DMARC requires it to align with the domain in the visible From
header. Read it every time — this is the single value that tells you whether
your DKIM is doing anything for you.
dkim=pass header.d=yourdomain.com is what you want.
dkim=pass header.d=yourtenant.onmicrosoft.com is the trap. The signature
is cryptographically valid, so it says pass, but it belongs to Microsoft’s
domain rather than yours. It cannot align, so it contributes nothing to DMARC.
Anyone glancing for the word “pass” will read this as healthy.
dkim=none means no signature was present at all. dkim=fail means a
signature was present but did not verify — usually something modified the
message in transit after signing.
Checking the CNAME chain
Both Microsoft 365 selectors are published as CNAMEs in your DNS pointing at records Microsoft hosts under your tenant. Resolve them directly:
dig CNAME selector1._domainkey.yourdomain.com
dig CNAME selector2._domainkey.yourdomain.comEach should return a CNAME, and following it should land on a TXT record
starting v=DKIM1; and carrying a p= public key. Use the exact target values
shown in the admin portal rather than constructing them by hand — the tenant
portion varies, and a hand-built guess that happens to be wrong looks identical
to a DNS propagation delay.
Both selectors need to resolve, not just one. Microsoft rotates between selector1 and selector2 to roll keys. If only one is published, signing works until the rotation moves to the missing selector and then stops — which is the “it worked for months and then broke on its own” case.
A p= value that is present but empty is a revoked key, not a working one.
Third-party senders sign separately
DKIM in Exchange Online covers mail that Microsoft 365 sends. It does nothing for the other platforms sending as your domain — the CRM, the marketing platform, the invoicing tool, the ticketing system.
Each of those signs with its own key and its own selector, and each needs its own DKIM configuration pointed at your domain, or it signs with the vendor’s domain and fails alignment. There is no central switch. A tenant with perfect Exchange Online DKIM can still have most of its outbound mail failing DMARC, and the Exchange Admin Center will show no sign of it — it only knows about its own mail flow.
The DMARC aggregate reports are the only place the full picture appears, because they cover every source sending as your domain, not just the one platform you happen to be looking at.
How to fix it
- Go to Exchange Admin Center → Email authentication → DKIM
- Select your domain
- If Disabled: click Enable to generate new CNAME records
- Publish the CNAME records Microsoft provides to your DNS
- Wait for propagation (check the TTL — usually 3600 seconds)
- Return to Exchange Admin Center and confirm the status shows Enabled
- Send a test message to an external address and check DKIM signing in the message headers
If the Exchange Admin Center shows Enabled but DKIM is still not signing, disable and re-enable DKIM for the domain. This forces a key regeneration and resolves most cases where tenant configuration is inconsistent.
Preventing recurrence
Add DKIM signing status to your monitoring. DMARC aggregate reports reviewed weekly are the minimum — they’ll catch any signing failure within one reporting period. A periodic DNS check of your DKIM selectors is straightforward to add to any monitoring stack and will flag failures within minutes of them occurring. If you’d rather not build and watch that monitoring yourself, a managed gateway like Mail Shield handles the ongoing checks for you.