How to set up DKIM in Microsoft 365 (without breaking your email signatures)

If you're setting up email authentication for your domain, DKIM is the piece most likely to cause friction later, especially if you also manage email signatures across the business. Fewer than one-third of organizations have implemented DMARC, DKIM, or SPF, according to Exclaimer's State of Business Email 2025, so configuring it at all puts you ahead of most senders.

This guide walks through what DKIM is, how to enable it in Microsoft 365 using the Defender portal or PowerShell, how to rotate your keys, and how to test that it's working. It also answers the question most IT teams have when adding a signature tool: whether inserting an email signature breaks DKIM, and how to configure Microsoft 365 so it doesn't.

What is DKIM and how does it work?

DKIM, or DomainKeys Identified Mail, is an email authentication method that attaches a digital signature to every message you send, letting the receiving server confirm the message came from your domain and wasn't altered in transit. It works using a pair of cryptographic keys: a private key that stays with your mail server, and a public key that you publish in your DNS. Your server signs outbound messages with the private key, and receiving servers use the public key to verify that signature.

DKIM doesn't encrypt your email or hide its contents. It signs the message so the recipient can trust two things: that your domain authorized it, and that the parts of the message covered by the signature are unchanged since signing. That second guarantee is the reason email signatures and DKIM can collide, covered in detail below.

The DKIM signing and verification process

When your mail server sends a message, it generates a hash of selected headers and the message body, signs that hash with your private key, and adds the result to the email as a DKIM-Signature header. The receiving server looks up your public key in DNS, uses it to verify the signature, and recomputes the hash from the message it received. If the two hashes match, DKIM passes. If anything covered by the signature changed after signing, the hashes won't match and DKIM fails.

The takeaway for everything that follows: DKIM validates the message exactly as it was at the moment of signing. Change the signed content afterward, and validation breaks.

DKIM vs. SPF vs. DMARC

DKIM is one of three authentication standards that work together, each doing a different job. SPF, which you configure by adding Microsoft 365's mail servers to your SPF record, tells receiving servers which servers are allowed to send on your behalf. DKIM proves the message content is authentic and unaltered. A DMARC policy then ties the two together, telling receivers what to do when a message fails SPF or DKIM and sending you reports on what's happening.

How to enable DKIM in Microsoft 365

You can turn on DKIM signing for a custom domain two ways: through the Microsoft Defender portal, or with Exchange Online PowerShell. Both do the same job. They generate a key pair, give you two CNAME records to publish, and switch signing on once those records resolve. Your initial onmicrosoft.com domain is already DKIM signed by default, so these steps apply to the custom domains you actually send from.

Before you start, add the domain to Microsoft 365 if you haven't already, and confirm you can edit records at your DNS host, where your MX record and other mail settings already live.

Enable DKIM in the Microsoft Defender portal

1. Go to the Defender portal at security.microsoft.com and open Email & collaboration > Policies & rules > Threat policies > Email authentication settings. You can jump straight there with security.microsoft.com/authentication.

2. Select the DKIM tab, then click the domain you want to configure.

3. In the flyout, find the two CNAME records under Publish CNAMEs and copy both exactly.

4. Create those two CNAME records at your DNS host, then wait for them to resolve.

5. Return to the flyout and switch Sign messages for this domain with DKIM signatures to Enabled. Status changes to Valid once Microsoft detects the records.

Enable DKIM with PowerShell

If you'd rather script it, connect to Exchange Online PowerShell and check the current state first:

Connect-ExchangeOnline

Get-DkimSigningConfig | Format-List Name,Enabled,Status,Selector1CNAME,Selector2CNAME

If your custom domain isn't listed, create a signing configuration in a disabled state. This generates the keys and selector values without signing anything yet:

New-DkimSigningConfig -DomainName contoso.com -Enabled $false -KeySize 2048

Copy the Selector1CNAME and Selector2CNAME values from the output, publish them as CNAME records at your DNS host, and once they resolve, enable signing:

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

Run the Get-DkimSigningConfig command again to confirm Enabled is True and Status is Valid. One thing worth knowing: the New-DkimSigningConfig default is a 1024-bit key, so add -KeySize 2048 to start with a stronger key, which is the current recommendation.

Publish the DKIM CNAME records in DNS

Microsoft 365 doesn't ask you to publish the public key directly. You publish two CNAME records that point to Microsoft's DKIM infrastructure, and Microsoft manages the underlying keys for you. That's why you use CNAMEs here rather than the raw TXT record some other platforms use. Publish a TXT key by hand and the status stays stuck on CnameMissing.

For a new custom domain, the records follow this format, introduced in May 2025:

Hostname: selector1._domainkey

Points to: selector1-contoso-com._domainkey.contoso.n-v1.dkim.mail.microsoft

Hostname: selector2._domainkey

Points to: selector2-contoso-com._domainkey.contoso.n-v1.dkim.mail.microsoft

Domains configured before that change use an older format ending in your onmicrosoft.com domain. Either way, don't build these values by hand. Copy the exact target from the portal or from Get-DkimSigningConfig, because a single wrong dash or dot leaves signing broken. Publish both records even though only one selector is active at a time, since the inactive selector is what lets keys rotate later without downtime. Set the TTL to at least 3600 seconds to avoid intermittent lookup failures.

Does adding an email signature break DKIM?

It can, but with the right setup it won't. Inserting an email signature changes the message, and DKIM is built to detect exactly that kind of change, which is why the two need to be configured to work together.

DKIM validates the message as it was at the moment it was signed. Most server-side signature tools add the email signature by routing outbound mail through a transport rule that inserts HTML into the message body. If that HTML is added after Microsoft 365 has already applied the DKIM signature, the body no longer matches what was signed, and DKIM fails at the receiving end. That's the failure mode IT teams are right to worry about.

The fix is the order of operations. Exclaimer's cloud solution strips the DKIM signature on receipt, inserts the email signature, and returns the message to Microsoft 365, which re-applies DKIM after the signature is in place and before delivery. Because the final signing happens after the content is added, the signature the recipient verifies matches the message they receive, and DKIM passes.

This is also where a purpose-built platform earns its place over a hand-rolled transport rule. Getting the signing order wrong is exactly the kind of mistake a DIY setup makes, and it's easy to miss, because the email still looks correct to the sender while failing authentication downstream. Configure the mail flow as documented, and DKIM keeps validating with your email signatures in place.

How to rotate your DKIM keys in Microsoft 365

DKIM keys are credentials, and they should be changed on a schedule, at least once a year. Microsoft 365 doesn't rotate custom domain keys for you, so this is a task you own.

The two CNAME records you published earlier are what keep rotation from disrupting mail flow. One selector signs your mail while the other sits on standby. When you rotate, Microsoft 365 activates the standby selector with a fresh key and retires the old one, so signing never stops.

To rotate in the Defender portal, open the DKIM tab, select the domain, and choose Rotate DKIM keys at the bottom of the flyout.

To rotate with PowerShell:

Rotate-DkimSigningConfig -Identity contoso.com

To move up to a 2048-bit key at the same time, add the KeySize parameter:

Rotate-DkimSigningConfig -Identity contoso.com -KeySize 2048

Rotation isn't instant. The new key takes four days (96 hours) to start signing, and the current key keeps signing until then. You can't start a second rotation while one is in progress. There's one gotcha when raising the bit depth: the 2048-bit size applies only to the next active selector on this rotation, so the other selector updates to 2048 on the following rotation.

How to test and validate your DKIM record

A Valid status in the portal confirms your configuration, not that receivers accept your signature. Check both: the configuration in Microsoft 365, then a real message.

Start in PowerShell. Get-DkimSigningConfig should return Enabled as True and Status as Valid for your domain:

Get-DkimSigningConfig -Identity contoso.com | Format-List Name,Enabled,Status,Selector1CNAME,Selector2CNAME

Then test an actual email. Send a message from the domain to an external mailbox you control, open it, and view the original source or headers. In the Authentication-Results header, look for dkim=pass. You'll also see a DKIM-Signature header whose d= value matches your domain and whose s= value shows which selector signed the message, for example s=selector1-contoso-com.

A DKIM validation tool does the same check without reading headers by hand. Send a message to the address the tool gives you, or enter your domain and selector, and it reports whether the signature verifies against your published key. Either way, a passing result means the receiving side can validate your signature against DNS.

Common DKIM problems and how to fix them

Most DKIM problems in Microsoft 365 trace back to DNS or timing rather than DKIM itself. The failures below are the ones you're most likely to hit, with the fix for each.

If a message still fails once you've ruled out these causes, read the full Authentication-Results header. It shows whether the failure is DKIM, SPF, or DMARC, so you can isolate the problem instead of guessing.

Done right, you don't have to choose between authenticated mail and consistent, branded email signatures.