A Configuration Guide to DKIM and DMARC Settings in Microsoft 365

If your organization uses Microsoft 365 for email, you've likely configured SPF (Sender Policy Framework) records to specify which IP addresses can send mail on behalf of your domain. 

But SPF alone isn't enough to fully protect your domain from spoofing attacks or ensure optimal email deliverability. DKIM and DMARC are two additional email authentication protocols that provide critical layers of protection, but many organizations overlook them simply because they're not required to send email.

The reality is that without DKIM and DMARC, your domain remains vulnerable to spoofing, and your legitimate emails may face deliverability challenges. 

The role of DKIM and DMARC in email security

While SPF helps receiving mail servers verify that an email came from an authorized IP address, it has limitations. Email forwarders can break SPF checks, and attackers can still spoof your display name while sending from their own infrastructure. This is where DKIM and DMARC fill critical gaps.

• DKIM (DomainKeys Identified Mail) adds cryptographic integrity to your emails by digitally signing message headers and body content. When you send an email, DKIM creates a unique signature that recipients can verify using a public key published in your DNS records. This proves both that the email came from your domain and that it wasn't modified in transit.
• DMARC (Domain-based Message Authentication, Reporting, and Conformance) uses both SPF and DKIM results to enforce sender identity policies. It tells receiving mail servers what to do when emails claiming to be from your domain fail authentication checks—whether to deliver them to spam, reject them entirely, or simply monitor and report back to you.

Together, the three protocols (SPF, DKIM, DMARC) create a comprehensive email authentication framework. As Microsoft emphasizes in their guidance, enabling SPF, DKIM, and DMARC together is a foundational best practice for any organization serious about email security and deliverability.

The benefits extend beyond security. Properly configured email authentication often improves deliverability rates, as major email providers (Gmail, Outlook, etc.) increasingly favor authenticated mail over unauthenticated messages.

Enabling DKIM in Microsoft 365 for all domains

By default, Microsoft 365 disables DKIM for custom domains, signing outbound messages with the default onmicrosoft.com domain instead. To enable DKIM for your custom domains, you'll need to configure both DNS records and settings within the Microsoft 365 Security portal.

1. DNS configuration

For each custom domain, you'll need to publish two CNAME records in your DNS:

selector1._domainkey.yourdomain.com CNAME selector1-yourdomain-com._domainkey.yourtenant.onmicrosoft.com selector2._domainkey.yourdomain.com CNAME selector2-yourdomain-com._domainkey.yourtenant.onmicrosoft.com

Microsoft uses two selectors to enable key rotation without interrupting mail flow. 

The exact CNAME targets will be specific to your tenant and domain—you can find these in the Microsoft 365 Security portal under Email & Collaboration > Policies & Rules > Threat Policies > Email Authentication Settings.

2. Enabling DKIM in the portal

Once your DNS records are published and propagated (typically 15-30 minutes):

• Navigate to Microsoft 365 Security portal > Email & Collaboration > Policies & Rules > Threat Policies
• Select Email Authentication Settings
• Choose your domain from the list
• Toggle Sign messages for this domain with DKIM signatures to Enabled

Microsoft 365 uses several secure defaults for DKIM configuration:

• 2048-bit RSA keys (recommended standard, upgraded from legacy 1024-bit keys)
• Relaxed canonicalization to handle minor email formatting changes during transit
• Full message body signing (NumberOfBytesToSign = all) for maximum integrity protection

If your tenant still uses 1024-bit keys from earlier deployments, consider rotating to 2048-bit keys for improved security posture.

3. Implementing DMARC

With both SPF and DKIM configured, you can implement DMARC by publishing a DNS TXT record. Start with a monitoring-only policy to understand your email ecosystem:

_dmarc.yourdomain.com TXT "v=DMARC1; p=none; rua=mailto:dmarc@yourdomain.com"

This policy (p=none) tells recipients to apply no enforcement action but send aggregate reports to the specified email address. These reports will show you which sources are sending email on behalf of your domain and whether they're passing or failing authentication checks.

Troubleshooting and common pitfalls

Even experienced IT administrators encounter predictable challenges when implementing DKIM and DMARC in Microsoft 365. Understanding these common issues can save significant troubleshooting time.

DKIM won't enable in the portal

The most frequent issue is DNS propagation problems. If the DKIM toggle remains grayed out or shows an error, verify:

• CNAME records are published correctly with no typos in the target domains
• DNS propagation is complete (use nslookup or online DNS checkers)
• Your DNS provider supports CNAME records for subdomains (some basic DNS services have limitations)

Mixed key lengths and legacy configurations

Organizations with older Microsoft 365 tenants may still have 1024-bit DKIM keys, which some receiving servers flag as weak. Check your current key length using PowerShell:

Get-DkimSigningConfig -Identity yourdomain.com

If you see 1024-bit keys, rotate to 2048-bit keys through the Security portal.

Third-party email services

DKIM and DMARC failures often surface when organizations use third-party email services (Mailchimp, Salesforce, HubSpot) that send on their behalf. These services need their own SPF inclusion and DKIM configuration to pass DMARC alignment checks. Review your DMARC reports to identify legitimate services that need additional configuration.

DMARC alignment requirements

DMARC requires either SPF or DKIM to "align" with the From header domain. For Microsoft 365:

• SPF alignment requires the Return-Path domain to match the From domain
• DKIM alignment requires the DKIM signature domain to match the From domain

Microsoft 365 handles this automatically for primary domains, but subdomain configurations may require additional attention.

For more, visit Microsoft’s DKIM FAQs.

Monitoring DKIM and DMARC health over time

Email authentication isn't a "set it and forget it" configuration. DNS changes, expired keys, new third-party services, and domain additions can all impact your authentication posture over time.

DKIM monitoring in Microsoft 365

Use Microsoft's built-in tools to verify DKIM status:

Admin center monitoring:

• Navigate to Mail Flow > Accepted Domains to see DKIM status for each domain
• Use Message Trace to verify DKIM signatures are being applied to outbound messages

PowerShell validation:

Get-DkimSigningConfig | Format-Table Identity, Enabled, KeySize, Selector1CNAME, Selector2CNAME

This command shows the current DKIM configuration for all domains, highlighting any that aren't enabled or are using weak key sizes.

DMARC report analysis

DMARC aggregate reports provide crucial visibility into your email authentication ecosystem. These XML reports show:

• Which IP addresses are sending email claiming to be from your domain
• SPF and DKIM authentication results for each sender
• Volume and disposition of messages from each source

Several tools can help parse and analyze DMARC reports:

• Dmarcian - Comprehensive DMARC analytics and policy recommendations
• Postmark DMARC Digests - Simple, readable report summaries
• EasyDMARC - User-friendly DMARC monitoring and analysis

Look for patterns indicating:

• Legitimate services failing authentication (requires SPF/DKIM configuration)
• Spoofing attempts from unexpected IP addresses or geographic regions
• Changes in email volume that might indicate new services or security issues

Continuous configuration monitoring

For organizations managing multiple domains or complex email infrastructures, manual monitoring becomes challenging. This is where automated monitoring tools prove valuable.

Prelude's platform can continuously monitor email authentication configurations across your environment, surfacing issues like:

• DKIM disabled or misconfigured for specific domains
• Weak key lengths (1024-bit) that should be rotated to 2048-bit
• DMARC policies set to ineffective monitoring mode (p=none) without progression to enforcement
• Misalignments between SPF, DKIM, and From header domains that prevent proper DMARC functionality

This continuous monitoring approach helps ensure that configuration drift doesn't silently degrade your email security posture over time. Without monitoring, you might assume DKIM and DMARC are working properly even when they've failed due to DNS changes, expired keys, or new email services that weren't included in your authentication setup.

Moving forward with email authentication

Implementing DKIM and DMARC in Microsoft 365 provides immediate security benefits and often improves email deliverability. The key is methodical implementation: start with DKIM for all custom domains, implement DMARC in monitoring mode, analyze the reports to understand your email ecosystem, and gradually move toward enforcement policies.

Remember that email authentication is an ongoing responsibility, not a one-time configuration. Regular monitoring ensures your protections remain effective as your email infrastructure evolves and new threats emerge.