Setup Guides · Microsoft 365
Microsoft 365 DKIM Setup: The selector1/selector2 CNAMEs Everyone Forgets
Out of the box, Microsoft 365 DKIM-signs your mail as yourtenant.onmicrosoft.com - a signature that can never align with your real domain, so DMARC leans entirely on SPF, which breaks the moment anyone forwards your mail. The fix is two CNAME records and one toggle. This guide covers the exact steps and the six failures we keep finding in audits.
Last updated 31 July 2026 · applies to all Microsoft 365 / Exchange Online tenants
Why this matters (the onmicrosoft.com trap)
Until you enable DKIM for your custom domain, Microsoft 365 signs every outbound message with the tenant default key - d=yourtenant.onmicrosoft.com. That signature is cryptographically valid, so casual checks say "DKIM: pass". But DMARC does not care whether a signature verifies; it cares whether the signing domain aligns with your visible From domain - and onmicrosoft.com never aligns with yourdomain.com. (Google Workspace has the same trap with its gappssmtp.com default - see the Workspace guide. No major provider aligns your mail until you finish the setup.)
The practical consequence: your DMARC passes ride on SPF alone. Any forwarded message - mailing lists, recipients auto-forwarding to another mailbox, some helpdesk tools - breaks SPF and therefore fails DMARC outright. At Microsoft's own receivers this shows up as weaker compauth evidence; at an enforcing policy it means legitimate mail quarantined. This is the single most common finding when we audit Microsoft 365 senders.
What you need
- A Microsoft 365 admin role that can reach the Defender portal (Security Administrator or Global Administrator).
- Access to your domain's public DNS (your registrar or DNS host).
- About 15 minutes, plus DNS propagation time.
The setup, step by step
1 Open the DKIM page in the Defender portal
Go to security.microsoft.com → Email authentication settings → DKIM and select your custom domain - not the .onmicrosoft.com entry.
2 Create the DKIM keys and copy the two CNAMEs
If the domain has never had DKIM configured, click Create DKIM keys. Microsoft shows two CNAME records in exactly this shape:
Host: selector1._domainkey.yourdomain.com Value: selector1-yourdomain-com._domainkey.yourtenant.onmicrosoft.com Host: selector2._domainkey.yourdomain.com Value: selector2-yourdomain-com._domainkey.yourtenant.onmicrosoft.com
Note the value format: your domain with dots replaced by hyphens, then ._domainkey., then your tenant's original onmicrosoft.com name. Copy both exactly - do not retype them.
3 Publish both CNAMEs at your DNS host
At most DNS hosts you enter only selector1._domainkey as the record name - the host appends your domain automatically. Publish both records, selector1 and selector2, as plain DNS records (on Cloudflare: DNS only, grey cloud).
4 Enable signing
Back in the Defender portal, turn on Sign messages for this domain with DKIM signatures. If it errors that the CNAMEs cannot be found, the records have not propagated yet - wait an hour and retry the toggle. Do not delete or re-create the keys.
5 Verify on a real message
Send a fresh email and view its headers: the DKIM-Signature should now show d=yourdomain.com; s=selector1 (or selector2). The fastest full check: send one email to Postbox Mailtester (Free Email Deliverability Audit) - its Microsoft panel detects tenant-default-only DKIM automatically and confirms alignment, and the report shows the signature and key.
Prefer PowerShell?
In Exchange Online PowerShell: New-DkimSigningConfig -DomainName yourdomain.com -Enabled $false creates the keys (then publish the CNAMEs), and Set-DkimSigningConfig -Identity yourdomain.com -Enabled $true turns signing on. Rotate to a 2048-bit key with RotateDkimSigningConfig -Identity yourdomain.com -KeySize 2048.
The six failures we keep finding
1. Your registrar appended the domain twice
You pasted the full host selector1._domainkey.yourdomain.com into a field that auto-appends the domain, creating selector1._domainkey.yourdomain.com.yourdomain.com. The Defender toggle keeps failing and nothing looks wrong in the DNS panel. Test from a terminal:
dig +short CNAME selector1._domainkey.yourdomain.com
If that returns nothing, query the doubled name - if that answers, shorten the record name to just selector1._domainkey.
2. Only selector1 was published
Signing works on day one, so the missing second record goes unnoticed. Then Microsoft rotates to selector2 - weeks or months later - and every message starts failing DKIM at once, with no change on your side. If DKIM "suddenly broke", check selector2 first.
3. Signing enabled for the wrong domain
The portal lists both your custom domain and the tenant's .onmicrosoft.com address. Enabling the latter changes nothing for your real mail. The custom domain's row must show signing enabled.
4. Headers still show d=onmicrosoft.com after enabling
Check a fresh message - mail already queued keeps the old signature. If new mail still signs with the tenant default after an hour, the enable toggle did not actually save (see failure 1) or you enabled the wrong domain (failure 3).
5. A relay or smart host bypasses EOP's signature
Printers, scanners, CRMs or an on-premises server relaying through a third-party smart host never pass through the signing step, so that mail goes out unsigned regardless of your portal settings. Route application mail through Microsoft 365 (or give that system its own DKIM) - our Microsoft intake checklist walks the diagnosis.
6. A legacy 1024-bit key
Tenants that enabled DKIM years ago may still sign with 1024-bit keys. Verifiers accept them today, but 2048 is the standard - rotate with the PowerShell command above. (Postbox Mailtester shows your key length in the DKIM detail.)
Verify it end to end
- One-email audit: send a message to Postbox Mailtester - it checks the signature, the alignment, the key size, and forecasts the compauth verdict Microsoft's own filters would stamp.
- DNS check: look up
selector1andselector2for your domain with the free DKIM lookup. - Deliverability context: if mail to Outlook.com or Microsoft 365 recipients still lands in junk after DKIM aligns, work through our complete Microsoft deliverability guide - authentication is the entry ticket, not the verdict.
Frequently asked questions
Do I really need both selector1 and selector2 CNAMEs?
Yes. Microsoft signs with one selector at a time but rotates between them. With only selector1 published, DKIM works until the first rotation - then everything fails at once. Publish both up front.
Will enabling DKIM disrupt my mail flow?
No. It is additive - messages simply start carrying your domain's signature instead of the tenant default. Nothing gets rejected during the change.
How long after publishing the CNAMEs can I enable signing?
As soon as both records resolve publicly - usually minutes, occasionally an hour or two. If the toggle cannot find them, wait and retry; do not re-create the keys.
DKIM passes but DMARC still fails - why?
DMARC needs alignment. A valid signature with d=yourtenant.onmicrosoft.com verifies but does not align with your From domain. Enable DKIM for the custom domain itself.
What key size should I use?
2048-bit. Older tenants may still be on 1024 - rotate via RotateDkimSigningConfig -KeySize 2048.
Primary reference: Microsoft Learn - Use DKIM to validate outbound email.
Stuck, or want the whole domain checked in one pass?