Email and DNS

How to enable DKIM in Microsoft 365 (step by step)

By Matt Chapman/Published 1 November 2026/Updated 2 November 2026/8 min read

DKIM (DomainKeys Identified Mail) adds a digital signature to every email you send. The receiving server checks that signature against a public key in your DNS, which proves the message really came from your domain and wasn’t changed on the way.

Here’s the catch with Microsoft 365: it signs mail with your yourcompany.onmicrosoft.com domain out of the box, but not with your own domain. Until you switch it on, recipients see a DKIM signature that doesn’t match the address in the From line. That doesn’t help DMARC, and Gmail, Yahoo and Outlook.com all lean heavily on DMARC when deciding whether your mail lands in the inbox or the junk folder.

Turning it on takes about 15 minutes of actual work, plus a wait for DNS. This guide covers the whole job: getting the records from Microsoft, adding them to your DNS, enabling signing, and proving it works.

Before you start

• An admin account. You need Global Administrator, Security Administrator or Exchange Administrator to see the DKIM settings.
• Access to your DNS. That’s wherever your domain’s records live: your registrar, Cloudflare, your web host’s control panel, or similar.
• The domain added and verified in Microsoft 365. If you already receive mail for it in Exchange Online, this is done.

It’s worth checking where you stand first. Put your domain into the free email DNS checker. It looks up your MX, SPF, DKIM and DMARC records in one go and automatically tries Microsoft 365’s DKIM selectors (selector1 and selector2). If DKIM already shows as found, someone may have set it up before you and you can skip to step 6 to confirm it’s actually signing.

Step 1: Open the DKIM settings in Microsoft Defender

DKIM used to live in the Exchange admin centre. It’s now in the Microsoft Defender portal.

1. Go to security.microsoft.com/authentication and sign in with your admin account. The long way round is Email & collaboration > Policies & rules > Threat policies > Email authentication settings.
2. Select the DKIM tab.
3. Click your own domain in the list, not the .onmicrosoft.com one. A details panel opens on the right.

Step 2: Get your two CNAME records

If the panel shows a Create DKIM keys button, click it. Microsoft generates a key pair for the domain and shows you two CNAME records to publish. If keys already exist, the records are shown in the panel (you may need to expand a section or try the toggle once to reveal them).

They look something like this, for a domain called example.co.uk:

Host:      selector1._domainkey
Points to: selector1-example-co-uk._domainkey.examplecompany.n-v1.dkim.mail.microsoft
Host:      selector2._domainkey
Points to: selector2-example-co-uk._domainkey.examplecompany.n-v1.dkim.mail.microsoft

Two things that catch people out:

• The values end in .dkim.mail.microsoft, not .com. That’s correct. It’s Microsoft’s newer format. Older tenants may show values ending in .onmicrosoft.com instead, which also still work.
• Copy the values exactly from your own tenant. The middle part is unique to you, so never use an example from a guide (including this one). If the Microsoft 365 admin centre’s domain setup wizard shows different values from the Defender page, go with Defender.

Step 3: Add the CNAME records to your DNS

Log in to your DNS host and add two new records:

Watch for these:

• Don’t type the domain twice. Most control panels add your domain to the end of the name automatically. Enter selector1._domainkey, not selector1._domainkey.example.co.uk, or you’ll end up with selector1._domainkey.example.co.uk.example.co.uk.
• Cloudflare users: set both records to DNS only (grey cloud). A proxied record returns Cloudflare’s addresses instead of the CNAME, and Microsoft can’t find the key.
• Sending from a subdomain? If the address is something like news@mail.example.co.uk, add that subdomain to the domain in Microsoft 365 and the host becomes selector1._domainkey.mail.
• Don’t paste a TXT record. With Microsoft 365 you publish CNAMEs that point at Microsoft. Microsoft hosts the actual key, which is what lets it rotate keys without you touching DNS again.

Step 4: Check the records are live

New records usually show up within an hour, but it can take longer depending on your DNS host and TTL. Before you go back to Microsoft, check them yourself:

1. Open the email DNS checker and enter your domain.
2. Look at the DKIM result. It should find a key at selector1 and selector2 and report the key size.

If nothing is found, look up selector1._domainkey.yourdomain in the DNS lookup tool. It shows the CNAME and the chain it follows, so you can spot a typo or a doubled domain name straight away.

Step 5: Turn on DKIM signing

Go back to the DKIM tab in Defender, select your domain, and switch on Sign messages for this domain with DKIM signatures.

If the records resolve, the status changes to Valid and Microsoft 365 starts signing new outgoing mail from that domain straight away. If you get an error saying the CNAME records don’t exist, Microsoft can’t see them yet. Double-check them with the tools above, wait a little longer, then try again.

Repeat steps 1 to 5 for every custom domain you send mail from. Each one needs its own records.

Step 6: Prove a real email is signed

A green status in the portal tells you the setup exists. It doesn’t tell you the signature survives the trip. Send a test email from Outlook to a personal Gmail address, then:

1. Open the message in Gmail, click the three dots and choose Show original.
2. At the top you should see DKIM: ‘PASS’ with domain yourdomain. If it names your .onmicrosoft.com domain instead, signing isn’t on for your own domain yet.
3. In the headers, find DKIM-Signature. The d= value should be your domain and s= should be selector1 or selector2.

In Outlook you can do the same from File > Properties on a received message: look for dkim=pass header.d=yourdomain in the Authentication-Results header.

Doing it with PowerShell instead

If you manage several tenants, or the portal won’t play ball, Exchange Online PowerShell does the same job. Connect first:

Install-Module ExchangeOnlineManagement   # first time only
Connect-ExchangeOnline -UserPrincipalName admin@example.co.uk

See whether the domain already has a DKIM configuration, and get the CNAME values:

Get-DkimSigningConfig -Identity example.co.uk | Format-List Name,Enabled,Status,Selector1CNAME,Selector2CNAME,Selector1KeySize

If nothing comes back, create the keys (with signing off for now, because the DNS records don’t exist yet):

New-DkimSigningConfig -DomainName example.co.uk -KeySize 2048 -Enabled $false
Get-DkimSigningConfig -Identity example.co.uk | Format-List Selector1CNAME,Selector2CNAME

Publish the two CNAMEs as in step 3, wait for them to resolve, then switch signing on:

Set-DkimSigningConfig -Identity example.co.uk -Enabled $true

Upgrade to a 2048-bit key

The email DNS checker reports your key size. Domains that were set up a few years ago often still use 1024-bit keys. They work, but 2048-bit is the current recommendation, and upgrading is a rotation in PowerShell:

Rotate-DkimSigningConfig -Identity example.co.uk -KeySize 2048

You don’t need to change DNS, because your CNAMEs point at Microsoft. The command only upgrades the selector that isn’t currently in use, and Microsoft switches over to it a few days later (check the RotateOnDate value with Get-DkimSigningConfig). Once it has switched, run the same command again to upgrade the other selector. The same command, without -KeySize, is how you rotate keys as routine housekeeping.

Troubleshooting

“CNAME record does not exist” or “No DKIM keys saved”

Microsoft can’t resolve your records. In order of likelihood: DNS hasn’t caught up yet, the domain has been typed twice in the host name, there’s a typo in the value, or the record is proxied in Cloudflare. Check with the DNS lookup before waiting any longer.

DKIM passes for Outlook mail but not for everything else

Microsoft 365 only signs mail that goes out through Microsoft 365. Newsletters, CRM systems, website contact forms, invoicing software and helpdesk tools that send as your domain each need DKIM set up in their own settings, with their own records. The email DNS checker lets you enter a custom selector, so you can check each one (find the s= value in a message that service has sent).

DKIM fails even though the portal says Valid

Something is changing the message after Microsoft signs it. Common culprits are third-party email signature tools, disclaimer services and outbound filtering gateways that route mail back out through their own servers. Check the full headers to see where the message went after leaving Microsoft, and look at that product’s own DKIM guidance.

Your MX points at a filtering service

If inbound mail goes through Mimecast, Proofpoint or similar before reaching Microsoft 365, the Defender page can be awkward about creating keys. The PowerShell route above usually gets round it. Also check whether the filtering service signs outbound mail itself, because you don’t want two products fighting over it.

Next step: DMARC

DKIM on its own doesn’t stop anyone spoofing your domain. DMARC is the record that tells receivers what to do when a message fails, and it needs SPF or DKIM to pass for your own domain, which is exactly what you’ve just fixed.

If you don’t have a DMARC record yet, start with p=none and a reporting address, read the reports for a few weeks to find every service sending as you, then move to p=quarantine and finally p=reject. My guide to setting up DMARC walks through each stage, including what to do with the reports. The email DNS checker shows your current policy and flags common mistakes. For a wider look at your domain, my DNS security check covers the other records worth tidying up.

Quick checklist

• Check the current state with the email DNS checker
• Create DKIM keys for your domain in Defender (or with New-DkimSigningConfig)
• Publish the selector1 and selector2 CNAMEs exactly as shown, DNS only
• Confirm both selectors resolve before enabling
• Turn on signing and wait for the Valid status
• Send a test email and confirm DKIM passes with your own domain
• Upgrade any 1024-bit keys to 2048-bit
• Set up DKIM in every other service that sends as your domain
• Add or tighten DMARC