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.
How to set up DKIM in Microsoft 365 (quick answer)
To enable DKIM for a custom domain in Microsoft 365 (Office 365):
- In Microsoft 365 Defender (security.microsoft.com) → Email & collaboration → Policies & rules → Threat policies → DKIM, select your domain and copy the two CNAME records it shows.
- Publish both CNAME records (
selector1._domainkeyandselector2._domainkey) at your DNS provider. The target uses hyphens, not dots —company.com.aubecomescompany-com-au. - Wait for DNS propagation, then return to the DKIM page and click Enable. Publishing the records alone does not turn DKIM on — this activation step is the one Microsoft’s docs bury.
- Send a test email and confirm the header shows
d=yourdomain.com(notonmicrosoft.com).
The rest of this guide explains why the default signing domain fails DMARC, and the errors that trip people up along the way.
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.
Enabling DKIM with PowerShell
If you manage Microsoft 365 from the command line — or you’re enabling DKIM across several tenants — Exchange Online PowerShell is faster than clicking through the portal.
Connect to Exchange Online:
Connect-ExchangeOnline -UserPrincipalName admin@yourdomain.comCreate the DKIM signing configuration for your domain. Create it disabled first, so you can read the CNAME targets and publish them before signing tries to start:
New-DkimSigningConfig -DomainName yourdomain.com -Enabled $falseRead the two CNAME records Microsoft expects you to publish:
Get-DkimSigningConfig -Identity yourdomain.com | Format-List Selector1CNAME, Selector2CNAMEPublish both CNAME records at your DNS provider, wait for propagation, then enable signing:
Set-DkimSigningConfig -Identity yourdomain.com -Enabled $trueConfirm the result:
Get-DkimSigningConfig -Identity yourdomain.com | Format-List Domain, Enabled, StatusEnabled should read True and Status should read Valid. If Status shows CnameMissing, the records haven’t propagated or were published incorrectly — the same root cause as the portal error below.
Rotating to a 2048-bit DKIM key
Microsoft 365 historically generated 1024-bit DKIM keys. 2048-bit is now the recommended standard and newer tenants get it by default, but a domain set up years ago may still be signing with a 1024-bit key. Check the key size in the DKIM signing config, and rotate if needed:
Rotate-DkimSigningConfig -KeySize 2048 -Identity yourdomain.comBecause the CNAME records point at keys Microsoft manages, you don’t republish DNS when a key rotates — Microsoft swaps the underlying key behind the existing selector. The one case that breaks rotation: if your DNS provider has dropped the CNAME records (some do silently on account or plan changes), the rotation has nothing to point at and signing fails. Confirm both selectors still resolve before and after any rotation.
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. If you’d rather have someone else own DKIM signing, DMARC enforcement and the ongoing monitoring, that’s what Mail Shield is for.