How to Set Up DKIM in Office 365 (Microsoft 365)

DKIM (DomainKeys Identified Mail) lets Microsoft 365 cryptographically sign the mail your domain sends, so receiving servers can confirm the message really came from you and wasn't altered in transit. Setting it up for a custom domain takes two steps: publish two CNAME records in your DNS, then switch on DKIM signing in the Microsoft Defender portal. This guide covers the current process — including the portal path Microsoft moved DKIM to — plus how to verify and troubleshoot it.

Why Microsoft 365 uses CNAME records for DKIM

On most platforms you publish your DKIM public key as a TXT record. Microsoft 365 works differently: for a custom domain you publish two CNAME records that point back to keys Microsoft generates and manages on your tenant. Because Microsoft holds the keys, it can rotate them for you without you ever editing the key material in DNS — you only publish the aliases once.

There are two selectors, selector1 and selector2. One is active and signing your mail; the other stays in reserve and takes over at the next key rotation. That is why you always publish two records, not one.

If you only send from your initial *.onmicrosoft.com domain, there's nothing to do — Microsoft 365 DKIM-signs that domain automatically. The steps below are for signing with your own custom domain, which is what you want so that DKIM aligns with the domain your recipients actually see.

Before you start

Have these ready before starting DKIM configuration in Office 365.

Gather a few things first:

• Global admin (or Security Administrator) access to your Microsoft 365 tenant.
• The custom domain already added and verified in Microsoft 365.
• Access to your DNS provider (Cloudflare, GoDaddy, Route 53, etc.) so you can add CNAME records.
• Your initial domain prefix — the custom part of your *.onmicrosoft.com domain (for contoso.onmicrosoft.com, it's contoso). You'll see it in the record values Microsoft generates.

Step 1: Publish the two CNAME records

The exact values are tenant-specific, so let Microsoft show them to you rather than guessing. In the Defender portal, open the DKIM tab (Step 2 below) and select your domain — the Publish CNAMEs section lists the precise hostnames and targets to add. They follow this shape:

Copy the exact "Points to" values Microsoft shows for your tenant — they're generated per domain.

• Host selector1._domainkey → points to selector1-._domainkey..onmicrosoft.com
• Host selector2._domainkey → points to selector2-._domainkey..onmicrosoft.com

For a domain like contoso.com on the contoso.onmicrosoft.com tenant, the first record's target is selector1-contoso-com._domainkey.contoso.onmicrosoft.com. Some newer tenants show targets ending in .dkim.mail.microsoft instead — either way, copy the values Microsoft displays verbatim; don't hand-build them. Add both CNAMEs at your DNS provider and save.

Step 2: Enable DKIM signing in the Defender portal

DKIM is no longer configured from the Exchange admin center. It now lives in the Microsoft Defender portal:

1. Go to the Defender portal at security.microsoft.com and sign in with an admin account.
2. Navigate to Email & collaboration → Policies & rules → Threat policies → Email authentication settings. (Shortcut: go straight to security.microsoft.com/authentication.)
3. Select the DKIM tab.
4. Click your custom domain to open its details flyout.
5. Set the Sign messages for this domain with DKIM signatures toggle to Enabled.

If the CNAME records have propagated, the status flips to Valid and Microsoft 365 begins signing outbound mail from that domain. If you prefer PowerShell, the equivalent command in Exchange Online PowerShell is Set-DkimSigningConfig -Identity yourdomain.com -Enabled $true.

Step 3: Verify DKIM is signing

Confirm the signature is real before you consider the job done:

• Send a test message to an external mailbox (a personal Gmail account works well), open the message, and view the original/headers. Look for a DKIM-Signature header with d=yourdomain.com and an dkim=pass result in the Authentication-Results.
• Run a DKIM lookup. Check your published selector and key with the DKIM checker, or scan SPF, DKIM, and DMARC together with the Email Security Score.
• Check compliance. If you're chasing the Microsoft sender requirements specifically, the Microsoft compliance checker confirms DKIM alongside the other rules.

Common issues with DKIM in Microsoft 365

Most DKIM problems in Microsoft 365 come down to DNS, propagation, or the toggle. Here are the ones that trip people up.

"No DKIM keys saved for this domain" — the toggle won't enable

This means the CNAME records aren't resolving yet. Microsoft won't let you switch signing on until it can see both selector1 and selector2 CNAMEs. Re-check that you added them at the correct host (selector1._domainkey, not selector1._domainkey.yourdomain.com if your provider already appends the domain), that they're CNAME (not TXT) records, and give DNS time to propagate — usually 2–3 hours, up to 48. Then reopen the domain in the DKIM tab and enable it.

DKIM shows "CnameMissing" or fails validation

The record exists but doesn't match what Microsoft expects. The usual causes are a typo in the target, your DNS provider adding a trailing dot or your domain name to the value, or copying only one of the two selectors. Compare each record against the exact Points to value in the Publish CNAMEs section and fix any mismatch.

DKIM passes but DMARC still fails

DKIM signing works, but DMARC also needs alignment — the signing domain (d=) must match your visible From: domain. If you're signing with the onmicrosoft.com domain rather than your custom domain, DKIM passes but doesn't align. Enable DKIM on the custom domain so d= matches the address your recipients see, and make sure SPF is also aligned.

Mail from a third-party service isn't DKIM-signed

Enabling DKIM in Microsoft 365 only signs mail sent through Microsoft 365. A marketing platform, help desk, or CRM that sends as your domain has its own DKIM setup with its own selector. Configure DKIM separately in each of those tools, or those streams will fail authentication even though Microsoft 365 mail passes.

Maintaining DKIM

• Rotate keys periodically. In the DKIM tab, open the domain and choose Rotate DKIM keys. Microsoft swaps to the reserve selector; the new key becomes active after 96 hours, so leave both CNAMEs in place permanently.
• Prefer 2048-bit keys. Microsoft provisions 1024-bit keys by default but supports 2048-bit, which aligns with current guidance in RFC 8301. You can move to 2048 during a rotation.
• Keep DNS intact. Never delete the CNAME records while DKIM is enabled — removing them breaks signing at the next rotation. Learn more about selectors in our guide to DKIM selectors.

DKIM is one leg of a complete setup. Pair it with SPF and a DMARC policy at enforcement — see what DMARC, DKIM, and SPF do together — so that Microsoft 365 mail is both signed and protected against spoofing.

Frequently asked questions

Do I have to enable DKIM in Microsoft 365, or is it on by default?

Mail from your initial *.onmicrosoft.com domain is DKIM-signed automatically. Your custom domain is not — you must publish the two CNAME records and enable signing in the Defender portal for it to be signed with a domain that aligns to your From: address.

Why does Microsoft 365 use CNAME records instead of a TXT record for DKIM?

So Microsoft can manage and rotate the keys for you. The CNAMEs point to key material Microsoft hosts; when it rotates a key, the CNAME target resolves to the new value automatically and you never touch DNS again. That's also why you publish two selectors — one live, one staged for the next rotation.

How long does DKIM take to start working after I enable it?

DNS propagation is the main wait — typically 2–3 hours, up to 48 depending on your CNAME records' TTL. Once the DKIM tab shows the domain as Valid, Microsoft 365 signs new outbound mail immediately.

Can I set up DKIM with PowerShell instead of the portal?

Yes. After the CNAMEs are published, connect to Exchange Online PowerShell and run Set-DkimSigningConfig -Identity yourdomain.com -Enabled $true. To create the configuration first (for example to choose a 2048-bit key), use New-DkimSigningConfig -DomainName yourdomain.com -Enabled $false -KeySize 2048, then enable it.

Should I keep both CNAME records forever?

Yes. Both selectors must remain published for the lifetime of DKIM on the domain. Microsoft alternates between them during key rotation, so deleting either one will break signing the next time it rotates.

Related reading

• What are DMARC, DKIM, and SPF?
• Unraveling the power of DKIM selectors
• What is DKIM?