Microsoft 365 doesn’t enable DKIM for custom domains by default. Until you explicitly set it up, your outbound mail is signed with Microsoft’s default key — using onmicrosoft.com as the signing domain. That means your DMARC alignment will either rely entirely on SPF, or fail for messages forwarded by other servers.
Here’s how to set it up correctly, and what goes wrong.
Why the default signing domain is a problem
When DKIM isn’t configured for your custom domain, Microsoft signs outbound mail with a key tied to your tenant.onmicrosoft.com domain — not your actual From address domain.
DMARC alignment requires that the DKIM signing domain matches (or is organisationally related to) the From address domain. If you send from user@company.com.au but the DKIM signature is for company.onmicrosoft.com, DMARC passes only if SPF alignment also passes.
The failure case that matters: forwarded email. When a message is forwarded, the return-path (envelope sender) changes, which breaks SPF alignment. At that point, DKIM is your only path to DMARC alignment — and if it’s signed for the wrong domain, DMARC fails.
Setting up DKIM for your custom domain also makes your mail more resistant to false-positive filtering at large receiving providers.
What the setup actually involves
DKIM in Microsoft 365 uses two CNAME records in your DNS that point to keys Microsoft manages. The CNAME approach means Microsoft can rotate the keys without requiring you to change your DNS records each time.
The records 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.comThe target hostname uses hyphens instead of dots in your domain name — company.com.au becomes company-com-au in the CNAME target. Get that transformation wrong and the CNAME resolves to nothing.
Step by step
1. Get the exact CNAME values from the admin centre
Don’t try to construct the CNAME targets manually. Go to Microsoft 365 Defender (security.microsoft.com) → Email & collaboration → Policies & rules → Threat policies → DKIM. Select your domain. Microsoft shows you the exact CNAME records to publish.
If you have multiple custom domains, each needs its own pair of CNAME records.
2. Publish the CNAME records in your DNS
Add both CNAME records at your DNS provider. The TTL doesn’t matter much — 3600 (1 hour) is fine.
Wait for propagation. You can verify with:
nslookup -type=CNAME selector1._domainkey.yourdomain.comIt should return the onmicrosoft.com target. If it returns NXDOMAIN, the records aren’t published or haven’t propagated yet.
3. Enable DKIM in the admin centre
This is the step the Microsoft documentation buries. Publishing the CNAME records alone doesn’t enable DKIM signing. You must return to the DKIM page in Microsoft 365 Defender, select your domain, and click Enable (or toggle it on).
After enabling, Microsoft runs a validation check against your CNAME records. If they’re not found, you’ll see an error — the most common being “CNAME record does not exist for this config.”
4. Verify it’s working
Send a test email to a Gmail address and check the message headers. Look for DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yourdomain.com. The d= domain should be your custom domain, not onmicrosoft.com.
The email auth checker will also show your DKIM selector status from a DNS perspective.
What commonly goes wrong
“CNAME record does not exist for this config” — The most frequent error. Usually the CNAME records haven’t propagated yet — wait an hour and try again. If it persists after several hours, verify the records were published correctly. Check the exact hostname format (hyphens, not dots) and confirm both selector1 and selector2 records exist.
DKIM signing is enabled but DMARC still shows alignment failure — Check that d=yourdomain.com appears in the DKIM-Signature header, not a subdomain. If your From address is user@mail.company.com.au and you configured DKIM for company.com.au, you may have a subdomain mismatch with strict alignment mode. Relaxed alignment (the default) handles this — strict doesn’t.
DKIM enabled but emails still failing DMARC at some providers — Check whether the failing messages are forwarded. Forwarding strips SPF, so DKIM is the only remaining alignment mechanism. If DKIM was recently enabled, some providers may not have picked up the selector DNS record yet.
Key rotation failures — Microsoft rotates DKIM keys periodically. The CNAME approach should handle this transparently. If you see DKIM failures appearing after a period of correct operation, check whether your CNAME records still resolve correctly — occasionally DNS providers drop records on renewal.
After DKIM: the path to DMARC enforcement
Once DKIM is enabled and verified, check your DMARC aggregate reports. You should see dkim: pass appearing for messages sent through Microsoft 365. Once your reports show consistent alignment from all legitimate sending paths (not just M365 but also your CRM, marketing platform, and any other services), you can move DMARC from p=none toward p=quarantine and eventually p=reject.
If you’re reading p=none in your DMARC record and haven’t moved beyond it, the DMARC p=none explained article covers what that means and the checklist for moving to enforcement.