DKIM
DKIM (DomainKey Identified Mail) uses digital signatures to verify that your domain actually sent the message, which helps protect against spoofing. Microsoft 365 uses a more streamlined DKIM setup process now. It keeps things consistent across domains and makes configuration a bit less painful when you're working with custom domains. This guide covers the updated configuration process, key differences, and now to implement DKIM using both the Microsoft 365 Defender portal and PowerShell.
WHAT CHANGED?
In the past, DKIM CNAME records pointed to Microsoft-hosted domain ending in .onmicrosoft.com. Microsoft now uses a uniform naming setup that routes to .dkim.mail.microsoft.com. This approach offers better scalability and allows Microsoft to more securely manage DKIM keys within their infrastructure.
For further details, refer to How to use DKIM for email in your custom domain - Microsoft Defender for Office 365 | Microsoft Learn.
UNDERSTANDING THE NEW CNAME FORMAT
To active DKIM for a domain in Microsoft 365, two CNAME records need to be published. These records are domain-specific and provided in your Microsoft 365 Defender portal.
Components Explained
For a domain like yourdomain.com, with a tenant prefix domain, and a partition identifier p, your records would look like this:
INTERNAL DOMAINS
If you're sending from a default Microsoft domain like yourtenant.onmicrosoft.com, you don't need to configure anything. Microsoft automatically signs those messages with DKIM and handles both key management and rotation on the backend.
Enabling DKIM through Microsoft 365 Defender Portal
Enabling DKIM through PowerShell
PowerShell is recommended when you're managing DKIM for multiple domains or want to automate deployment.
Prerequisites
Allow PowerShell scripts to run in this session and installing the module:
Enable DKIM
DKIM (DomainKey Identified Mail) uses digital signatures to verify that your domain actually sent the message, which helps protect against spoofing. Microsoft 365 uses a more streamlined DKIM setup process now. It keeps things consistent across domains and makes configuration a bit less painful when you're working with custom domains. This guide covers the updated configuration process, key differences, and now to implement DKIM using both the Microsoft 365 Defender portal and PowerShell.
WHAT CHANGED?
In the past, DKIM CNAME records pointed to Microsoft-hosted domain ending in .onmicrosoft.com. Microsoft now uses a uniform naming setup that routes to .dkim.mail.microsoft.com. This approach offers better scalability and allows Microsoft to more securely manage DKIM keys within their infrastructure.
For further details, refer to How to use DKIM for email in your custom domain - Microsoft Defender for Office 365 | Microsoft Learn.
UNDERSTANDING THE NEW CNAME FORMAT
To active DKIM for a domain in Microsoft 365, two CNAME records need to be published. These records are domain-specific and provided in your Microsoft 365 Defender portal.
Domain | DNS Type | Host | Value |
yourdomain.com | CNAME | selector1._domainkey | selector1-yourdomain-com._domainkey.tenantprefix.partition-v1.dkim.mail.microsoft |
yourdomain.com | CNAME | selector2._domainkey | selector2-yourdomain-com._domainkey.tenantprefix.partition-v1.dkim.mail.microsoft |
Components Explained
- Yourdomain-com - Your domain name with periods replaced by hyphens (example: domain.com becomes domain-com).
- Tenantprefix - The prefix of your Microsoft 365 tenant (from your .onmicrosoft domain).
- Partition-v1 - A system-assigned routing identifier (example: p-v1, n-v1, s-v1). This value is domain specific and cannot be guessed or reused across tenants.
For a domain like yourdomain.com, with a tenant prefix domain, and a partition identifier p, your records would look like this:
Domain | DNS Type | Host | Value |
yourdomain.com | CNAME | selector1._domainkey | selector1-yourdomain-com._domainkey.domain.p-v1.dkim.mail.microsoft |
yourdomain.com | CNAME | selector2._domainkey | selector2-yourdomain-com._domainkey.domain.p-v1.dkim.mail.microsoft |
INTERNAL DOMAINS
If you're sending from a default Microsoft domain like yourtenant.onmicrosoft.com, you don't need to configure anything. Microsoft automatically signs those messages with DKIM and handles both key management and rotation on the backend.
Enabling DKIM through Microsoft 365 Defender Portal
- Go to https://security.microsoft.com
- Navigate to Email & Collaboration > Policies & Rules > Threat Policies > DKIM
- Select the custom domain wishing to enable DKIM.
- Microsoft will display the exact CNAME records required.
- Publish the CNAME records in your DNS host.
- After your DNS have finished propagation, return to the portal and enable DKIM.
- Note: Propagation can take up to 48 hours depending on your DNS host.
Enabling DKIM through PowerShell
PowerShell is recommended when you're managing DKIM for multiple domains or want to automate deployment.
Prerequisites
- Install the Exchange Online PowerShell Module.
- A user with either Global or Exchange Administrator roles.
Allow PowerShell scripts to run in this session and installing the module:
- Set-ExecutionPolicy RemoteSigned
- Install-module -Name ExchangeOnlineManagement
Connect to Exchange Online using:
- Connect-ExchangeOnline
Check DKIM configuration:
- Get-DkimSigningConfig
If the domain doesn't exist in the list, create and enable it by running the PowerShell command below.
- New-DkimSigningConfig -DomainName yourdomain.com -KeySize 2048 -Enabled $true
Enable DKIM
- Set-DkimSigningConfig -Identity yourdomain.com -Enable $true
Rotate the DKIM key to be 2048-bit length (This adds extra security).
- Rotate-DkimSigningConfig -KeySize 2048 -Identity yourdomain.com
Run the following command to see the current DKIM configuration. Confirm DKIM has been enabled and bit length has been rotated.
- Get-DkimSigningConfig -Identity domain.com | Format-List
Once you have confirmed DKIM has been enabled and bit length has been rotated, verify your messages are passing DKIM by sending yourself a test message and analyzing the header of the message.