DKIM CNAME records

Publishing the CNAME records is only the DNS step; enable DKIM for the domain in Microsoft 365, confirm its status is Valid, and then verify a sent message reports dkim=pass.

1. Confirm and enable DKIM in Microsoft 365

Sign in with a Microsoft 365 administrator account, then:

1. Open the Microsoft Defender portal.
2. Go to Email & collaboration → Policies & rules → Threat policies → Email authentication settings.
3. Select the DKIM tab.
4. Select your custom domain.
5. Check its state:
   • Status: Valid and Toggle: Enabled — Microsoft 365 has detected the CNAME records and DKIM signing is enabled.
   • Status: Valid, but Disabled — change the toggle to Enabled.
   • Status: CnameMissing — Microsoft 365 cannot yet resolve one or both records. Compare the displayed Publish CNAMEs values with those at your DNS provider and allow more time for DNS propagation.

Microsoft specifically advises obtaining the required CNAME targets from the Defender portal or Exchange Online PowerShell; example values from documentation should not be copied because newer domains can use a dynamically assigned CNAME format.^1^

2. Run Microsoft’s DKIM diagnostic

For an additional tenant-side check:

1. Open the Microsoft 365 Admin Center.
2. Go to Diagnostics.
3. Select Validate DKIM Signing Configuration.
4. Select your custom domain and run the test.

A successful result is Properly Created and Correct DNS Entries Enabled. The diagnostic can also distinguish between incorrect DNS publication, a configuration that exists but is not enabled, and a missing DKIM configuration.^2^

3. Verify an actual signed message

This is the end-to-end test:

1. Send a new message from an address using the custom domain through Microsoft 365.
2. Send it to a mailbox where the full internet headers can be viewed.
3. Open the received message’s headers.
4. Find Authentication-Results and look for:

dkim=pass (signature was verified) header.d=example.com

Also find the DKIM-Signature header and confirm that:

• d= identifies the expected signing domain.
• s= identifies one of the configured Microsoft selectors.

Microsoft records dkim=pass, dkim=fail, or dkim=none in the Authentication-Results header. pass confirms that the recipient resolved the public key and successfully verified the signature.^3^

If the portal shows Enabled/Valid but the message reports:

• dkim=none: the message was not DKIM-signed. Confirm it was sent through Microsoft 365 using the configured domain.
• dkim=fail: check the accompanying reason. A missing/wrong selector can indicate a DNS mismatch; a body-hash failure can indicate that another service modified the message after signing.^4^
• dkim=pass with an unexpected header.d domain: another service may be signing the message. For DMARC alignment, the DKIM signing domain should align with the visible From-address domain.

Optional PowerShell confirmation

In Exchange Online PowerShell, run:

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

Replace example.com with your domain. The expected Microsoft 365 state is:

Enabled : True
Status  : Valid

The selector values should match the CNAME targets published by the DNS provider.^1^

References

1. Set up DKIM to sign mail from your cloud domain
2. Diagnostics in Enhanced Engagements
3. Anti-spam message headers in cloud organizations
4. Troubleshoot email authentication in Microsoft 365