DKIM record for Microsoft 365
How to add a DKIM record when DNS or mail is at Microsoft 365. Real steps, then a live lookup.
MX will look like yourdomain-com.mail.protection.outlook.com.
- In Microsoft 365 Defender, go to Email & collaboration > Policies & rules > Threat policies > Email authentication settings > DKIM.
- Select the domain and spin up CNAMEs. Microsoft gives you two selectors, usually selector1 and selector2.
- Publish both CNAMEs at your DNS host, then enable DKIM for the domain in that same screen.
Official docs: Microsoft 365. Other records for this provider: SPF · DKIM · DMARC
Does this page apply to you?
Run this first. Microsoft 365 only matters if it is where your DNS or mail actually lives.
dig +short MX yourdomain.com
Expect: A hostname like yourdomain-com.mail.protection.outlook.com. If it points elsewhere, mail is not hosted at Microsoft.
Specific to Microsoft 365
- Microsoft uses two CNAME records, not a TXT, so your DNS host must allow CNAMEs at
selector1._domainkeyandselector2._domainkey. - Targets are shaped like
selector1-yourdomain-com._domainkey.yourtenant.onmicrosoft.com: dots in your domain become dashes. Copy them from the Defender portal rather than typing them. - Keep both records. Two selectors let Microsoft rotate keys without you touching DNS.
- After publishing, switch signing on for the domain in the Defender portal (Email authentication settings, DKIM). If it errors that the CNAME does not exist, DNS has not propagated yet, or the CNAME is being proxied.
What you should end up with
Illustrative values. Use the exact host and value your provider shows you where it generates them.
Type Name Value CNAME selector1._domainkey selector1-yourdomain-com._domainkey.yourtenant.onmicrosoft.com CNAME selector2._domainkey selector2-yourdomain-com._domainkey.yourtenant.onmicrosoft.com
What the receiving server does with this record
Your sending server signs each message with a private key and adds a DKIM-Signature header naming the signing domain (d=) and the selector (s=). The receiver builds the hostname s._domainkey.d, fetches the public key from DNS, and verifies the signature. A valid signature proves the message came from that domain and was not changed on the way.
Mistakes that break it
- Published, but signing never switched on. Most providers need a second step after the DNS record exists. Until then they sign with their own domain, which passes DKIM but does not align with your From address, so it does nothing for DMARC.
- A doubled hostname. Typing the full name into a field that already appends your domain gives
selector._domainkey.yourdomain.com.yourdomain.com. - A damaged key. A 2048-bit key is longer than one 255-character DNS string. Stray spaces, line breaks and silent truncation all invalidate it.
- The wrong selector. The record is published under one name and the sender signs with another.
Check it from the command line
The final test is a real message: send one to a Gmail address, open Show original, and read the DKIM line. Before that, confirm the record resolves:
dig +short CNAME selector1._domainkey.yourdomain.com dig +short CNAME selector2._domainkey.yourdomain.com
Check it live
Check the DKIM record
Look up the live DNS after you save. This tool does not spend credits.
Related
- SPF record for Microsoft 365
How to add a SPF record when DNS or mail is at Microsoft 365. Real steps, then a live lookup.
- DKIM record for Microsoft 365
How to add a DKIM record when DNS or mail is at Microsoft 365. Real steps, then a live lookup.
- DMARC record for Microsoft 365
How to add a DMARC record when DNS or mail is at Microsoft 365. Real steps, then a live lookup.
- SPF, DKIM and DMARC checker (free)
Look up the three DNS records that decide whether Gmail and Outlook trust mail from a domain.