How to enable DKIM in Microsoft 365

28 May 2026 · 11 min read

Why DKIM matters in Microsoft 365

If you send email from a Microsoft 365 tenant, your messages already get a basic DKIM signature out of the box. That default signature uses a shared Microsoft domain (onmicrosoft.com) rather than your own. It keeps mail moving, but it does almost nothing for your brand or for DMARC. To pass DMARC with proper alignment, the domain in the DKIM signature has to match (or be a subdomain of) the domain in your visible From: address. The shared Microsoft selector cannot do that for you, so enabling DKIM signing for your own custom domain is the step that turns a cosmetic signature into a real authentication signal.

This guide walks through enabling DKIM in Microsoft 365 end to end: publishing the two CNAME selector records, switching signing on in the admin centre or via PowerShell, verifying the result, and avoiding the handful of mistakes that trip most people up. It is written for custom.example.com style tenants where you have already added and verified your own domain in Microsoft 365.

If you want the short version of what DKIM is before you start, the glossary has a concise definition, and the DKIM product page explains how the moving parts fit together. When you are ready to confirm your work, the free DKIM checker will read your published key back to you exactly as the world sees it.

How DKIM signing works in Microsoft 365 specifically

Most providers ask you to publish a single TXT record containing a public key. Microsoft 365 does it differently, and understanding why saves you a lot of confusion.

Microsoft keeps your actual public keys on its own infrastructure under hostnames it controls, in the dkimkeys zone. Instead of pasting a long key into your DNS, you publish two CNAME records that point at Microsoft. Those CNAMEs are the two selectors, conventionally named selector1 and selector2. Each selector resolves, via the CNAME, to the matching key that Microsoft stores and rotates.

The two selectors exist so that Microsoft can rotate keys without an outage. At any moment one selector is active and signing your mail, while the second is staged ready for the next rotation. When Microsoft rotates, it flips signing to the standby selector and provisions a fresh key behind the one that just went idle. Because both CNAMEs always point at live keys on Microsoft's side, rotation happens silently and you never have to touch DNS again after the initial setup. This is genuinely convenient: it is one of the few places where a hosted provider removes ongoing key-management work rather than adding it.

The shape of the two records you publish looks like this:

Host:  selector1._domainkey.example.com
Type:  CNAME
Value: selector1-example-com._domainkey.<tenant>.onmicrosoft.com

Host:  selector2._domainkey.example.com
Type:  CNAME
Value: selector2-example-com._domainkey.<tenant>.onmicrosoft.com

Two details matter here. First, the _domainkey label is mandatory and is part of the DKIM standard, not a Microsoft invention. Second, the value contains your initial domain, the <tenant>.onmicrosoft.com name that was created when your tenant was first set up. That is usually not the same string as your custom domain, and using the wrong one is the single most common setup failure. We will get the exact values from the admin centre rather than guessing them.

Step 1: Find your exact CNAME values

Do not hand-build these records from a template. The hyphenated middle segment and the tenant name vary, and a single wrong character means the CNAME never resolves. Microsoft gives you the precise values to publish.

1. Sign in to the Microsoft 365 Defender portal with an account that has the Security Administrator or Global Administrator role.
2. Go to Email & collaboration, then Policies & rules, then Threat policies, then Email authentication settings.
3. Open the DKIM tab. You will see every domain in your tenant listed with its current signing status.
4. Click your custom domain, for example example.com.

If DKIM has never been enabled for this domain, the slider will be off and Microsoft will display the two CNAME records you need to create, including the full host and value for both selector1 and selector2. Copy them exactly. If the records are not yet published, attempting to toggle signing on will produce an error telling you the CNAMEs are missing, and it will show you the values again, so you can always retrieve them from this screen.

You can also pull the expected records with PowerShell once connected to Exchange Online:

Get-DkimSigningConfig -Identity example.com | Format-List Selector1CNAME, Selector2CNAME

That returns the two right-hand-side values to point your CNAMEs at. Use whichever method you prefer, but always take the values from Microsoft rather than constructing them by hand.

Step 2: Publish the two CNAME records in DNS

Now add both records at whoever hosts your authoritative DNS: Cloudflare, your registrar, Route 53, or your own nameservers. The host and value are the ones Microsoft gave you in Step 1.

A few practical points that catch people out:

• Enter the host correctly for your DNS panel. Some panels want the fully qualified name, selector1._domainkey.example.com. Others append the zone automatically, so you enter only selector1._domainkey. If you type the full name into a panel that auto-appends, you end up with selector1._domainkey.example.com.example.com, which is wrong and will not resolve. When in doubt, add the record and then check what the panel actually stored.
• It must be a CNAME, not a TXT. This is the opposite of most other DKIM setups. If you paste the Microsoft value into a TXT record, signing will never validate.
• On Cloudflare, set the proxy status to DNS only (grey cloud). A CNAME inside _domainkey must resolve to Microsoft's hostname unchanged. If Cloudflare proxies it (orange cloud), the lookup returns Cloudflare's edge instead of Microsoft's key and DKIM breaks. Authentication records are never proxied.
• Do not flatten or alter the value. The right-hand side is a hostname, and it should be published verbatim. No quotes, no trailing edits.

Once both records are in, give DNS time to propagate. Within a single zone this is often a few minutes, but public resolvers can cache for as long as the record's TTL, so allow up to an hour before you expect everything to be visible everywhere. You can confirm propagation directly from the command line:

dig CNAME selector1._domainkey.example.com +short
dig CNAME selector2._domainkey.example.com +short

Each should return the Microsoft onmicrosoft.com target you published. If dig comes back empty, the record has either not propagated yet or was entered with the wrong host. The DKIM checker does the same lookup for you and additionally follows the CNAME through to the actual key, which is a useful sanity check that the whole chain is intact and not just the first hop.

Step 3: Turn on DKIM signing

Publishing the CNAMEs does not, by itself, make Microsoft start signing with your domain. You still have to flip the switch. Crucially, do this after the records are live in DNS, because Microsoft validates the CNAMEs at the moment you enable signing and will refuse if it cannot resolve them.

In the portal:

1. Return to the DKIM tab under Email authentication settings.
2. Select your custom domain.
3. Toggle Sign messages for this domain with DKIM signatures to Enabled.

If the CNAMEs are correctly published and propagated, the toggle flips and signing begins. If it errors, the message will tell you it could not find the CNAME records: that almost always means a propagation delay or a host-entry mistake, so recheck with dig and try again.

To do the same from PowerShell after connecting to Exchange Online:

Set-DkimSigningConfig -Identity example.com -Enabled $true

If the domain has never had a signing configuration created, you may first need:

New-DkimSigningConfig -DomainName example.com -Enabled $true

Once enabled, every message Microsoft 365 sends from an address at example.com will carry a DKIM-Signature header using selector1 or selector2, and the signing domain (d=) in that header will be your own example.com. That is the alignment DMARC needs.

Step 4: Verify that signing actually works

Enabling the toggle is not the same as confirming the result. Verify in two independent ways.

Check the published key. Run the DKIM checker against example.com with selector selector1, then again with selector2. A healthy result shows a valid public key of the expected length resolving through the CNAME. If one selector resolves and the other does not, you are missing a CNAME or it has a typo. Both should work, because Microsoft signs with one and rotates to the other.

Check a real message. Send an email from your Microsoft 365 mailbox to an external account you control, ideally one at a different provider. Open the received message and view its full headers (in Gmail, Show original; in Outlook, View message source). Look for two things:

• A DKIM-Signature header containing d=example.com and s=selector1 (or selector2). The d= value being your own domain is the whole point: if it still says onmicrosoft.com, signing for your custom domain has not taken effect.
• An Authentication-Results header showing dkim=pass.

When you see dkim=pass with d=example.com, signing is working and aligned. This matters because DKIM alignment is one of the two ways a message can satisfy DMARC, the other being SPF alignment. Having DKIM aligned makes your DMARC posture far more robust, particularly for forwarded mail, where SPF frequently breaks but a valid DKIM signature survives intact. For more on how the three protocols interlock, see the SPF product page and the DMARC product page.

Step 5: Confirm DKIM helps your DMARC, not just your headers

A passing DKIM signature is good, but the goal is a passing, aligned DMARC result. Once signing is confirmed, look at the bigger picture.

If you have not yet published a DMARC record, do that next. A starting record at p=none collects reporting data without affecting delivery, and it is the safe first move before any tightening. The DMARC generator will build a correct record for you, and the DMARC checker confirms what is currently published. If you want the full sequence from no policy to enforcement, the requirements guide lays it out.

Once DKIM is aligned and DMARC is reporting, you can read the aggregate reports to confirm that legitimate Microsoft 365 mail is passing DKIM in the wild, across all your sending sources, not just the one test message you sent. Paste a report into the DMARC report analyzer and you will see, per source, whether DKIM is aligning. That visibility is what lets you safely move from p=none to p=quarantine and finally p=reject without losing legitimate mail, which is the entire arc our done-for-you service automates.

Common problems and how to fix them

The toggle will not enable and reports a missing CNAME. The records have not propagated, or the host field is wrong. Confirm with dig CNAME selector1._domainkey.example.com +short. If it returns nothing, fix the host entry (watch for the double-suffix problem on auto-appending panels) and wait for the TTL to expire before retrying.

dig returns a Cloudflare address instead of an onmicrosoft.com name. The CNAME is being proxied. In Cloudflare, edit each selector record and set it to DNS only (grey cloud). Authentication records must never be proxied.

The signature shows d=tenant.onmicrosoft.com rather than your domain. Signing for your custom domain is not active. Either the toggle is still off for that specific domain, or you enabled it on the wrong domain in a multi-domain tenant. Re-open the DKIM tab, select the correct custom domain, and confirm its status reads Enabled.

Only one selector resolves. You published one CNAME but not the other, or one has a typo. Both selector1 and selector2 must be present and correct, otherwise key rotation will eventually break signing when Microsoft flips to the selector that does not resolve.

You enabled DKIM but DMARC still fails. DKIM passing is not the same as DMARC passing. DMARC also requires alignment, and it requires a published DMARC record. Check that the From: domain matches the d= domain and that you actually have a DMARC policy live. The DMARC checker and SPF checker together will show you which leg is failing.

Subdomains send mail too. DKIM signing configuration in Microsoft 365 is per domain. If you send from mail.example.com or marketing.example.com as distinct accepted domains, each needs its own selector CNAMEs and its own signing config. The shared organisational DMARC record can cover subdomains, but DKIM keys are configured individually.

A note on key rotation and ongoing maintenance

One of the real advantages of the CNAME approach is that you set it up once and Microsoft handles rotation for you. Because both selectors point at keys Microsoft controls, it can retire an old key and provision a new one behind the scenes without you editing DNS. You should still keep an eye on things, though, because DNS records do get accidentally deleted during migrations, registrar changes, or zone clean-ups, and a removed selector CNAME will silently start failing DKIM the next time rotation lands on it.

This is exactly the kind of slow, invisible regression that monitoring catches and manual checks miss. Continuous monitoring watches your selectors, your DMARC record, your SPF record, and your MTA-STS and BIMI configuration, and alerts you the moment any of them changes or breaks, rather than leaving you to discover it weeks later when deliverability drops. You can read about that on the monitoring page. If you would rather not own any of this operationally, the hosted products take the whole stack, including MTA-STS and BIMI, off your plate and keep them correct over time.

The practical takeaway

Enabling DKIM in Microsoft 365 comes down to a small, ordered checklist:

1. Get the exact selector1 and selector2 CNAME values from the DKIM tab in the Defender portal (or via Get-DkimSigningConfig).
2. Publish both as CNAME records, unproxied, with the host field entered correctly for your DNS panel.
3. Wait for propagation, confirm with dig, then enable the DKIM signing toggle for your custom domain.
4. Verify with the DKIM checker and by inspecting a real message for dkim=pass and d=example.com.
5. Make sure a DMARC record exists so that passing DKIM actually translates into a passing, aligned DMARC result.

Do those five things in that order and your Microsoft 365 mail will be signed with your own domain, aligned for DMARC, and resilient to forwarding. When you are ready to confirm the result, start with the free DKIM checker and the wider tools collection; when you would rather have the whole authentication stack set up, monitored, and driven safely to p=reject without an outage, that is precisely what the DMARC Engine service is built to do.