Mail host · DKIM

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.

  1. In Microsoft 365 Defender, go to Email & collaboration > Policies & rules > Threat policies > Email authentication settings > DKIM.
  2. Select the domain and spin up CNAMEs. Microsoft gives you two selectors, usually selector1 and selector2.
  3. 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._domainkey and selector2._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