Set up DKIM Office 365: Step-by-Step Guide

Misconfigured DKIM is one of the most common causes of email deliverability failure in Microsoft 365 (formerly Office 365) environments. 

Without it, your outbound messages may pass SPF but still get flagged as unauthenticated. This triggers spam filters, fails DMARC alignment, and increases exposure to spoofing and phishing.

Microsoft’s DKIM configuration spans multiple admin portals and often requires PowerShell to finalize.

That complexity leads to incomplete setups or long delays in deploying proper domain authentication.

This guide simplifies the process into six clear, actionable steps. You’ll learn how to generate DKIM records, publish CNAMEs, activate signing, and verify that your custom domain is authenticating mail correctly.

Prerequisites for Configuring DKIM in Office 365

Before you begin, ensure all required domain and admin settings are verified. Taking a few minutes to check these now can prevent hours of troubleshooting later

• Verified custom domain: Your domain must be added and verified in Microsoft 365. DKIM won’t work with the default onmicrosoft.com domain.
  For more information, see our guide on why using a separate domain for cold email sending is critical. 

• Admin permissions: You’ll need Global Admin rights or equivalent privileges to access and configure DKIM settings.

• DNS provider access: Ensure you have login access to your DNS host (GoDaddy, Cloudflare, Route53, etc.) to add two CNAME records.

• No existing DKIM records: Verify that selector1._domainkey and selector2._domainkey do not exist or do not contain incorrect values that could conflict with the new setup

• Allow time for DNS propagation: Some changes take effect within minutes, while others may require 24–48 hours to propagate and be recognized by Microsoft 365.

How to Set Up DKIM in Office 365 (Step-by-Step)

This section contains the essential steps to enable DKIM signing on your Office 365 domain. Follow these six steps carefully to ensure correct configuration, provided you’ve completed the prerequisites

Step 1: Select your domain in Microsoft Defender

• Go to security.microsoft.com and sign in as a Global Admin
• Navigate to: Email & collaboration → Policies & rules → Threat policies → Email authentication settings → DKIM
• From the list of domains, select your custom domain (not the default onmicrosoft.com one)

You’ll only see domains that have been verified in your Microsoft 365 tenant. If your domain isn’t listed, it likely hasn’t been added or verified yet in the Microsoft 365 admin center.

Step 2: Generate DKIM Keys for selector1 and selector2

Once you click into the DKIM settings for your domain, Microsoft will display two required CNAME records, these are the public keys for your domain.

They’re typically named:

• selector1._domainkey.yourdomain.com
  
• selector2._domainkey.yourdomain.com

They point to Microsoft-hosted DKIM key endpoints like:

• selector1-yourdomain-com._domainkey.yourdomain.onmicrosoft.com

These values are generated dynamically, so always copy them exactly as shown. Never modify or approximate them manually.

Step 3: Add two CNAME records to your DNS

• Log in to your DNS provider (e.g., Cloudflare, GoDaddy, Route53, cPanel).
  Create the two CNAME records provided by Microsoft

Note: Every provider’s DNS UI is different, but the selector names will always follow this pattern:

• selector1._domainkey.yourdomain.com and 
• selector2._domainkey.yourdomain.com

Cloudflare Proxy Warning: Set these to ‘DNS Only.’ Do not proxy them, or Microsoft won’t be able to validate the records.

Also, if DKIM was set up previously (with another email provider), check for and remove any conflicting selector1/2._domainkey records first.

Step 4: Wait for DNS propagation

After saving the records, DNS propagation begins. This can take:

• As little as 15 minutes
• Up to 24–48 hours, depending on TTL, DNS caching, and propagation delays
• In rare cases, Microsoft warns it may take up to 4 days to detect the records internally

You can verify the records are live using tools like:

• nslookup
• MXToolbox DKIM Lookup

Step 5: Enable DKIM signing in Microsoft 365

• Return to the DKIM settings panel in the Defender portal
• Click “Enable” or toggle “Sign messages for this domain with DKIM signatures” to on

If DNS is detected, you’ll see the status update to “Signing”. If the toggle fails or you get an error like “CNAME record doesn’t exist for this config,” DNS may not have propagated yet, so try again in a few hours.

Step 6: Send a test email and check DKIM headers

• Send an email from your Office 365 domain to a Gmail or Yahoo inbox
• Open the email, view the full headers, and look for:

Authentication-Results: ... dkim=pass ...

Also, confirm that the domain listed under d= in the DKIM-Signature header matches your custom domain.

DMARC is another important record you need to set up. Read our DMARC guide for quick setup. 

Troubleshooting DKIM Setup in Office 365

Use this section to quickly identify and fix the most common DKIM setup issues, without interpreting unclearMicrosoft errors or guessing.

Error: “CNAME record doesn’t exist”

Microsoft can’t detect the required selector1 and selector2 records.

Fix:

• Double-check the host and value fields in your DNS settings
• Make sure you didn’t include your domain twice in the hostname (e.g., selector1._domainkey.yourdomain.com.yourdomain.com)
• If you're using Cloudflare, make sure you’ve turned off the proxy for these records    

Problem: Emails are still signed with onmicrosoft.com

DKIM is technically active, but Microsoft is still using the default tenant domain instead of your custom one.

Fix:

• You likely skipped the final “enable” step for your custom domain
• Go back to the DKIM settings in Defender and toggle the option “Sign messages for this domain” to enable it 

Error: DKIM fails even after setup

DNS is live, but email headers show dkim=fail or no signature at all.

Fix:

• This is usually a propagation delay. The records may be live for you, but not yet visible to Microsoft’s DNS
• It can also happen if only one of the two selectors is published, or the wrong domain is in use
• Double-check the selector formatting, and confirm that the CNAMEs resolve publicly

Problem: No DKIM header in sent emails

The email is being sent from a domain that doesn’t have DKIM enabled.

Fix:

• Make sure the “From” domain matches the one where DKIM was configured
• If you're using multiple domains or aliases, you’ll need to repeat the DKIM setup for each one individually

To confirm that everything is working correctly, send a test email and run it through the MailReach spam test. It will immediately indicate whether DKIM is passing and flag any DNS or signing issues before they impact inbox placement.

Advanced DKIM Setup in Office 365 via PowerShell

This method is intended for admins managing multiple domains, automating configuration across tenants, or managing domains that are not visible in the UI If you're managing a single domain, the Defender portal is faster and more reliable, while PowerShell provides greater administrative control.

Connect to Exchange Online

Start by connecting to Exchange Online PowerShell using your Microsoft 365 admin credentials. This allows you to view and manage DKIM configurations at scale.

Check DKIM status

Run a command to list all DKIM configurations across your tenant. This helps you identify which domains already have DKIM set up and which still need attention.

Initialize DKIM for a new domain

If your domain isn’t listed, you’ll need to initialize DKIM manually. This creates the configuration and tells Microsoft to prepare DKIM keys for your custom domain.

Get CNAME records from PowerShell

Once initialized, you can retrieve the exact selector1 and selector2 CNAME records for that domain. These need to be published in your DNS settings just like with the standard method.

Enable DKIM signing

After confirming that the records have propagated, enable DKIM signing for the domain. This activates the configuration and starts signing outgoing mail.

Rotate DKIM keys (optional)

Microsoft supports key rotation for enhanced security. If needed, you can trigger a rotation using a single PowerShell command. As long as both selectors remain in DNS, the transition is seamless.

PowerShell is an effective option for onboarding multiple domains or managing a global tenant.

Even with automation, DKIM represents only one component of your email authentication strategy. MailReach helps you monitor domain reputation and spam placement at scale, especially when you're managing volume across multiple brands or clients.

How Long DKIM Takes to Go Live

Set realistic expectations for timing. DKIM setup is fast on your end, but mailbox providers may not recognize changes immediately

DNS propagation: 15 minutes to 48 hours

Once you publish the CNAME records in your DNS, they can take effect in minutes, or in some cases, up to two full days. This depends on TTL values and your DNS host's update cycle.

Until the records propagate globally, Microsoft won't let you enable DKIM. If you're still seeing DNS errors after publishing the records, it's usually a propagation delay and not a misconfiguration.

DKIM signing: Instant after enabling

After you’ve enabled DKIM in the Microsoft 365 portal and the system detects your records, signing takes effect immediately. All new outgoing mail will include a DKIM signature from that point forward.

However, DKIM doesn't apply retroactively. Any email sent before enabling DKIM will remain unsigned.

Key rotation: May take up to 96 hours

When rotating DKIM keys, allow extra time for the transition. Microsoft may delay active signing with the new selector for up to four days to ensure DNS changes are fully recognized.

Both selector1 and selector2 records should remain in DNS to avoid any disruption during key rollover.

In the first 24 hours after setup, mailbox providers like Gmail or Outlook might still treat your domain as unverified, particularly if they cannot detect the DKIM records yet. If you observe mixed inbox placement or lower open rates during this period, do not panic.

Best Practices for DKIM Setup in Office 365

These are practical, long-term habits to maintain your DKIM configuration healthy, especially when you're managing deliverability across multiple mailboxes or business units. Each one includes a situational example so you know when it matters.

Use 2048-bit keys

Microsoft 365 (formerly Office 365) defaults to 2048-bit DKIM keys. It is recommended to retain this setting. Some legacy systems still use 1024-bit keys, but many providers (including Gmail) now view those as weak.

Example: If your domain was previously set up with 1024-bit DKIM on another platform (like cPanel), switch to 2048-bit when migrating to Office 365. A mismatch in key strength can cause deliverability issues during warm-up or when enforcing DMARC.

Rotate DKIM keys every 6–12 months

Key rotation reduces the risk of compromise and helps maintain alignment with compliance standards.

Example: If you’re sending transactional or regulated emails (in fields like finance, healthcare, education), rotating DKIM keys every 6–12 months can satisfy internal audits and security reviews. It also reduces stale key exposure during domain or IT transitions.

Align DKIM “d=” domain with your From address

For DKIM to pass DMARC alignment, the domain in the DKIM signature (d=) must match the domain in your From address.

Example: If you send from marketing@brand.com but your DKIM is still signed by onmicrosoft.com, DMARC will fail. This often happens when admins skip the last step of enabling DKIM for the custom domain. This should be corrected before you enforce a p=reject DMARC policy.

Don’t delete selector1/2 CNAMEs

Even after DKIM is enabled, leave the CNAMEs in your DNS. Microsoft 365 uses both selectors to allow seamless key rotation.

Example: A junior team member might remove selector1._domainkey, thinking it’s redundant. This breaks key rollover and can cause signing to fail silently. Always leave both records published unless Microsoft explicitly says otherwise.

Combine DKIM with SPF, DMARC, and domain warming

DKIM is one part of your domain's trust profile. To protect inbox placement, combine it with:

• A valid SPF record
  
• A monitoring or enforcement-level DMARC policy
  
• A structured email warm-up process
  

Example: If you're launching cold outreach from a new domain, DKIM alone won’t prevent spam filtering. Pairing it with SPF, a DMARC record (p=none to start), and an email warm-up tool gives mailbox providers consistent signals over time. This is especially important if your sending volumes increase rapidly.

Strong authentication is your technical foundation, but it’s only part of inbox placement. MailReach helps you maintain it with daily spam tests, domain reputation tracking, and an automated warm-up that respects your DKIM, SPF, and DMARC settings.

Final Steps Toward Better Deliverability

Setting up DKIM in Office 365 is quick but its impact compounds over time. You’ve now added a key layer of authentication that mailbox providers check when determining whether your cold emails land in the inbox or the spam folder.

DKIM serves as your technical foundation and verifies your domain identity. However, building a sender reputation requires ongoing effort..

The real challenge starts after setup. New domains, new inboxes, or sudden spikes in volume can still trigger spam filters, even with DKIM in place. Without consistent testing and monitoring, you won’t know if your reputation is improving or silently slipping.

This is where we can help. Ready to go further?

MailReach automates inbox warm-up, DKIM and SPF testing, and domain health monitoring across mailbox providers to ensure emails are delivered to your prospective client’s inboxes.

Explore automated email warm-up.