Key Takeaways
- DKIM adds a digital signature to outgoing emails so receiving servers can verify the message was sent from an authorized source and was not altered in transit.
- Microsoft 365 automatically handles DKIM for onmicrosoft.com domains. Manual setup is only required for custom domains, and it involves creating two CNAME records in your DNS.
- DKIM signing is enabled through the Microsoft Defender portal after the CNAME records are published and detected.
- DKIM alone is not enough. It should always be configured alongside SPF and DMARC for complete email authentication and domain protection.
- DKIM keys should be rotated every one to two years to maintain strong email security.
If you are sending email through Microsoft 365 and have not configured DKIM for your custom domain, your emails are going out without a digital signature. That means receiving servers have no way to verify that your messages have not been altered in transit, and your domain is more vulnerable to spoofing.
Setting up DKIM for Office 365 is one of the most important steps in building a secure, trustworthy email setup.
This guide walks you through everything: what DKIM does, how Microsoft 365 handles it, and exactly how to configure it for your custom domain.
What Is DKIM and Why Does It Matter for Microsoft 365?
Before walking through the setup process, it is worth understanding what DKIM does and why it is a critical part of your Microsoft 365 email configuration.
DomainKeys Identified Mail (DKIM) is an email authentication protocol that adds a cryptographic digital signature to each outgoing email. When a message is sent, the signing domain uses a private key to generate the signature.
The receiving server then retrieves the corresponding public key from DNS and uses it to verify that the message body and headers have not been altered in transit.
What DKIM does for your email
| Benefit | How it works |
|---|---|
| Verifies message integrity | Cryptographic signature confirms the message was not altered after sending |
| Prevents domain spoofing | Makes it significantly harder for attackers to forge emails from your domain |
| Improves email deliverability | Authenticated emails are less likely to be flagged as spam by Gmail, Yahoo, and other providers |
| Builds sender trust | A valid DKIM signature indicates the signing domain takes responsibility for the message |
| Enables DMARC enforcement | DKIM is a required input for DMARC to function correctly |
Where DKIM fits alongside SPF and DMARC
DKIM works in conjunction with SPF and DMARC to form a complete email authentication framework. Each protocol covers a different layer:
- SPF verifies that the sending server is authorized to send email for your domain
- DKIM verifies that the message content was not altered in transit
- DMARC enforces policy by requiring SPF and DKIM to align with the From address
For DKIM to pass DMARC checks, the domain in the From address must match the domain used in the DKIM signature. This alignment requirement is what makes the combination of SPF, DKIM, and DMARC so effective against phishing attacks and spoofing.
DKIM alone is not sufficient to prevent all types of email spoofing. It must be used alongside SPF and DMARC for complete protection. We will cover how to implement DMARC alongside your Microsoft 365 DKIM setup later in this guide.
How Microsoft 365 Handles DKIM
Understanding how Microsoft 365 manages DKIM by default will save you from unnecessary confusion during setup.
What Microsoft handles automatically
Microsoft automatically enables DKIM signing for the initial onmicrosoft.com domain associated with your Microsoft 365 tenant. If you are only sending from yourcompany.onmicrosoft.com, DKIM is already working without any manual configuration.
What requires manual setup
Manual DKIM configuration is required for every custom domain you use to send email.
If your organization sends from a custom domain such as yourcompany.com, you need to create CNAME records in your DNS and enable DKIM signing through the Microsoft Defender portal.
Each subdomain used to send email from Microsoft 365 also requires its own DKIM configuration. DKIM does not automatically extend from a root domain to its subdomains.
The two-selector system
Microsoft 365 uses two DKIM selectors, selector1 and selector2, for each custom domain.
Using two selectors allows Microsoft to rotate DKIM keys automatically for better security. When you set up DKIM, you create CNAME records for both selectors pointing to the public keys generated by Microsoft 365.
| Expert insight: “In my experience helping organizations implement DKIM, automating DKIM monitoring with PowerDMARC not only saves time, but helps catch configuration errors before they impact email deliverability. This is especially critical for SaaS companies and regulated industries where email reliability is paramount.” |
Prerequisites for DKIM Setup in Office 365
Before starting the DKIM setup process, confirm that the following are in place.
| Prerequisite | Details |
|---|---|
| Admin access | A Global Administrator or Exchange Administrator role is required to perform DKIM setup steps |
| Custom domain verified | Your custom domain must be verified in Microsoft 365 before DKIM can be configured |
| DNS access | You need access to your domain registrar or DNS hosting provider to publish CNAME records |
| SPF configured | SPF should already be set up for your domain before enabling DKIM |
If SPF is not yet configured for your domain, set that up first. For step-by-step instructions, see our guide on how to set up SPF.
How to Set Up DKIM for Office 365: Step by Step
Setting up DKIM for a custom domain in Microsoft 365 involves three main actions: retrieving your CNAME record values from the Microsoft Defender portal, publishing those records in your DNS, and enabling DKIM signing once the records are detected.
The process is straightforward, but requires accuracy at every step. Typos in your CNAME values are the most common reason DKIM setup fails, so take your time with the DNS configuration.
Step 1: Get your DKIM CNAME record values from Microsoft 365
Microsoft 365 generates the exact CNAME record values you need to publish in your DNS. To find them:
- Sign in to the Microsoft Defender portal
- Navigate to Email and Collaboration > Policies and Rules > Threat policies
- Select Email Authentication Settings
- Click the DKIM tab
- Select your custom domain from the list
- Open the details flyout for that domain
The portal will display the two CNAME record values you need. If DKIM cannot be enabled yet, the portal will indicate the required values to use in the CNAME records.
The basic syntax of the DKIM CNAME records for custom domains follows this format:
| Host name | Points to |
|---|---|
| selector1._domainkey.yourdomain.com | selector1-yourdomain-com._domainkey.yourtenantname.onmicrosoft.com |
| selector2._domainkey.yourdomain.com | selector2-yourdomain-com._domainkey.yourtenantname.onmicrosoft.com |
Always use the exact values shown in the Defender portal for your specific domain and tenant, not a generic template.
Step 2: Create the CNAME records in your DNS
Log in to your domain registrar or DNS hosting provider and create two new CNAME records using the values from the previous step.
Key things to confirm when adding the records:
- Record type must be set to CNAME, not TXT or any other type
- Host name values must include the full selector prefix: selector1._domainkey and selector2._domainkey
- Check carefully for typos in the CNAME values. Errors at the domain registrar are the most common cause of DKIM setup failures
- Do not add multiple conflicting records for the same host name
DNS changes can take up to 48 hours to propagate globally, though they often happen much faster. It may take several minutes to a few hours for Microsoft 365 to detect the new CNAME records.
Step 3: Enable DKIM signing in the Microsoft Defender portal
Once your CNAME records are published and propagated, return to the DKIM tab in the Microsoft Defender portal:
- Select your custom domain
- Open the details flyout
- Toggle Sign messages for this domain with DKIM signatures to enabled
The status of the domain on the DKIM tab must show valid values for DKIM signing to be enabled. If the portal cannot detect your CNAME records, it will display an error along with the expected values. Double-check your DNS records for accuracy before trying again.
After enabling DKIM, it may take some time for the status to update and confirm that DKIM signatures are being applied to outgoing messages.
Step 4: Verify DKIM is working
To confirm DKIM signing is active, send a test email from your custom domain to a Gmail address and inspect the message header:
- Open the received email in Gmail
- Click the three-dot menu and select Show original
- Look for the DKIM-Signature header field in the raw message header
- Confirm the DKIM signature is present and that the d= value matches your custom domain
- The s= value in the DKIM-Signature header identifies the selector currently in use
A passing DKIM result in the message header confirms that DKIM signing is active and working correctly for your custom domain.
| Need help with DKIM troubleshooting? Our email security experts at PowerDMARC can help you resolve DKIM configuration issues quickly. Start your free trial for expert support and automated monitoring. |
How to Configure DKIM Using PowerShell
For advanced users and administrators, Exchange Online PowerShell offers powerful tools to manage and configure email settings, including DKIM. Using PowerShell commands allows you to automate DKIM setup, enable or disable DKIM signing for your custom domains, and troubleshoot issues efficiently, especially useful when managing multiple domains or complex environments.
You can use PowerShell to enable your Exchange Online DKIM setup for Office 365, especially if you want to enable it for multiple domains. To do so:
1. Connect to Exchange Online
2. Extract your Office 365 DKIM selectors by running the following script:
3. Add the CNAME records provided to your by Office 365 to your DNS
4. Run the following command to enable DKIM for the domain:
Key Considerations and Limitations for DKIM Implementation
DKIM is a powerful email authentication protocol, but it comes with technical constraints that are important to understand before and during implementation.
Knowing these limitations upfront helps you avoid common pitfalls, plan your configuration correctly, and set realistic expectations for what DKIM can and cannot protect against on its own.
| Consideration | What you need to know |
|---|---|
| Key length | Microsoft 365 uses 2048-bit cryptographic keys by default, which provides strong protection for outgoing messages |
| DNS propagation | After publishing your CNAME records, allow up to 48 hours for DNS changes to propagate globally, though propagation often happens much faster |
| DKIM key rotation | Rotate DKIM keys every one to two years to maintain strong email security and reduce the risk of old keys being exploited |
| Multiple domains | Each custom domain used to send email requires its own separate DKIM configuration. DKIM does not extend automatically from a root domain to its subdomains |
| Unused domains | Do not publish DKIM records for domains that never send email. Doing so can enable DKIM validation of forged messages sent from those domains |
DKIM limitations
Understanding where DKIM falls short is just as important as knowing what it does. These limitations are precisely why DKIM should always be implemented alongside SPF and DMARC rather than treated as a standalone solution.
Email forwarding
DKIM signatures can break during email forwarding. When a message is forwarded, some mail servers modify the message header or body in ways that invalidate the original DKIM signature.
This is one of the key reasons DMARC requires alignment across both SPF and DKIM rather than relying on either one alone.
Message modification
Any modification to the email content after it has been signed will invalidate the DKIM signature. This includes changes made by mailing lists, email gateways, or content filtering tools that alter the message body or certain header fields before delivery.
Third-party sending services
External email services that send on your behalf, such as marketing platforms, CRMs, and helpdesk tools, may require additional DKIM configuration.
Each third-party sender typically needs to sign outgoing messages with either your domain or their own, and this needs to be verified and accounted for in your overall email authentication setup.
Hybrid environments
Organizations running a combination of on-premises Exchange and Microsoft 365 in a hybrid environment may need special consideration when configuring DKIM signing.
Messages routed through on-premises servers before reaching Microsoft 365 can behave differently than cloud-only sending, and DKIM configuration should account for the full message flow before enabling signing.
Setup DKIM for Office 365 the Right Way With PowerDMARC!
Why PowerDMARC?
“PowerDMARC made our DKIM deployment effortless and gave us peace of mind with automated monitoring.” – IT Manager, FinTech Company
|
Set Up DKIM and Go Further With PowerDMARC
Enabling DKIM signing for your Microsoft 365 custom domain is a critical step in securing your email. But DKIM alone only covers part of the picture.
Without DMARC in place to enforce alignment and provide visibility into your email traffic, your domain remains exposed to spoofing and impersonation that DKIM cannot stop on its own.
PowerDMARC makes it straightforward to go from DKIM setup to full DMARC enforcement. With hosted DMARC, automated reporting, and a platform built to simplify every stage of email authentication, PowerDMARC gives you complete visibility into who is sending on your behalf and the tools to lock down your domain for good.
Take a free DMARC trial to weigh out your benefits today.
FAQs
1. How do I ensure that DKIM is enabled for all Exchange Online domains?
To make sure DKIM is enabled for all your Exchange Online domains, check the Microsoft Defender portal under Email & collaboration > Policies & rules > Threat policies > DKIM. Verify that DKIM is turned on for each custom domain.
2. How to rotate DKIM keys in Office 365?
To rotate DKIM keys in Office 365, you need to generate new CNAME records for the new keys in your DNS and then enable DKIM signing for those new keys in the Microsoft Defender portal. This process helps improve security by periodically updating the cryptographic keys that sign your emails.
3. How often should you rotate DKIM keys?
It’s recommended to rotate your DKIM keys every 1 to 2 years, or sooner if you suspect your keys have been compromised. Regular rotation helps maintain strong email security and prevents attackers from exploiting old keys.
4. What is the recommended key length for DKIM records?
Microsoft Office 365 uses 2048-bit DKIM keys by default, which provides strong security and is considered the current industry standard. This key length offers excellent protection against cryptographic attacks while maintaining good performance.
5. How do SPF, DKIM, and DMARC work together to protect email?
SPF authorizes sending servers, DKIM verifies message integrity through digital signatures, and DMARC provides policy enforcement by combining SPF and DKIM results. Together, they create a comprehensive email authentication framework that protects against spoofing, phishing, and ensures legitimate emails reach their intended recipients.
6. What should I do if DKIM signatures are not appearing in my outbound emails?
If DKIM signatures are not appearing in your outbound emails, check that DKIM is enabled on your sending service and that the correct DKIM public key is published in your DNS. Also, confirm that the selector matches and that DNS changes have fully propagated. If the issue continues, review your email server settings or contact your email provider.
