How to Set Up DKIM for Office 365

If you use Microsoft 365 to send email from a custom domain, DKIM is one of the most important controls to enable. DKIM, or DomainKeys Identified Mail, adds a cryptographic signature to outgoing mail so receiving systems can verify authenticity and message integrity.

When configured properly, DKIM helps reduce spoofing, supports stronger email authentication, and improves email deliverability. This guide covers the key steps to set up DKIM in Office 365 environments.

Step 1: Confirm prerequisites before enabling DKIM

Before you set up a DKIM record in Office 365, make sure the environment is ready. Microsoft’s process assumes the domain is already active in Microsoft 365 and that your team can manage both the DNS side and the Microsoft 365 side of the configuration.

Confirm the following before moving forward:

• The custom domain has already been added and verified in Microsoft 365
• You have access to the domain’s public DNS
• You have sufficient admin permissions in Microsoft 365
• You’ve identified every custom domain and subdomain that sends mail
• You understand that the default .onMicrosoft.com domain does not require manual DKIM setup

This planning step helps prevent missed domains, incomplete signing coverage, and avoidable setup errors later in the process.

Step 2: Generate or view the DKIM keys in Microsoft 365

Microsoft manages Office 365 DKIM through the DKIM settings page in the Microsoft 365 security  experience. 

Microsoft’s admin paths and UI change over time, so it is safer to refer to the DKIM settings page in the Microsoft 365 security environment, often surfaced through Microsoft 365 Defender or the broader Microsoft Defender experience. This is usually a better option rather than relying on one exact click path. 

Select the custom sending domain on the DKIM page. If Microsoft shows an option to Create DKIM Keys, use it. If the button does not appear, continue to the next step and use the selector values Microsoft already provides for that domain.

At this stage, you need to capture the two selector-based values that Microsoft provides. These usually use the naming pattern:

• selector1._domainkey
• selector2._domainkey

Note these are not TXT records. They are the two CNAME records Microsoft expects you to publish before you can enable DKIM signing. Each selector acts as a DKIM selector, and Microsoft uses them to support signing and future key management, including the ability to rotate DKIM later without disrupting mail flow.

Step 3: Publish the two DKIM CNAME records in public DNS

Use the exact Microsoft-provided selector names and target values. Publish both selector records, not just one. This is a common point of confusion because administrators sometimes assume one record is enough, but Microsoft’s documented DKIM setup expects both records to exist.

Make the changes at the external DNS host for the domain, not in internal DNS. Depending on your DNS provider, the fields may be labeled as:

• Host or Name
• Target or Points to
• TTL

Leave TTL at the default value unless your organization has a specific DNS policy. The more important issue is accuracy. Typos, duplicate entries, extra spaces, or publishing the records under the wrong domain context are among the most common reasons Microsoft cannot detect the records later.

This is also where administrators sometimes confuse DKIM with SPF. DKIM for Microsoft 365 uses CNAME entries here, not a TXT record like an SPF record. SPF is a separate part of your email authentication settings, typically published as a TXT entry for Sender Policy Framework. Microsoft documents SPF separately for custom domains in Microsoft 365.

Step 4: Wait for DNS propagation, then enable DKIM signing

After publishing the DNS entries, wait for DNS propagation before trying to enable signing. Microsoft’s documentation notes that the records may not be visible immediately, and propagation time depends on the DNS provider and existing TTL behavior.

Once the records are visible externally, return to the DKIM settings page in Microsoft 365, select the domain again, and turn on signing for that domain. In many environments, Microsoft labels this as enabling or turning on DKIM for the selected domain.

A few minutes may be enough in some DNS environments, but it is also normal for this process to take 24 to 48 hours. If Microsoft says it cannot find the CNAME entries, do not assume the values are wrong immediately. 

Wait a bit longer, recheck the records externally, and then try again. DNS timing is one of the most common reasons administrators think the DKIM Office process failed when it is really just delayed propagation.

Step 5: Validate that DKIM is working

After activation, verify both the DNS side and the actual mail flow.

First, use a DKIM lookup or DKIM record checker to confirm that both selector-based CNAME record entries resolve correctly. This shows the DNS side is in place. 

Second, verify live signing. Send a test message from the configured domain to an external mailbox, then inspect the message headers. You want to confirm:

• Message contains a DKIM-Signature
• Result shows a DKIM pass
• Signing domain matches the domain you intended to protect

This is the most important validation step because a visible DNS record alone does not prove DKIM authentication is happening on real mail. A domain can have the record published and still fail if the wrong sender is being tested, if the domain was not enabled correctly, or if another system is modifying the message later in transit.

Step 6: Troubleshoot Common DKIM Setup Issues in Office 365

Most DKIM activation problems come down to a few common setup issues. If Microsoft 365 cannot detect the records or signing does not appear to work, check the following first:

• Confirm the selector names and target values exactly match Microsoft’s output – Even a small typo in the selector or target can prevent Microsoft from finding the records.
• Make sure the records were added as CNAMEs – These entries must be published as CNAME records, not as a TXT record or another DNS type.
• Verify the records exist in the correct public DNS zone – The records must be added to the external DNS zone for the correct custom domain, not to an internal zone or the wrong domain.
• Allow more time for DNS propagation – A correct setup may still fail initial checks if public DNS has not fully updated yet.
• Separate Microsoft 365 signing from other sending services – A valid Microsoft 365 DKIM setup only applies to mail signed by Microsoft 365. If other tools send mail from the same domain, such as CRMs, ticketing platforms, or secure mail services, they may need their own DKIM configuration and alignment review.

Step 7: Extend protection beyond the initial setup

DKIM should not be treated as a standalone control. It works best alongside SPF and DMARC. DKIM signs the message and helps confirm integrity. SPF identifies approved mail sources for the domain. 

DMARC applies policy and reporting when authentication fails, making spoofing harder and helping improve email deliverability and trust. Microsoft explicitly recommends using DKIM, SPF, and DMARC together for Microsoft 365 domains.

In multi-domain environments, repeat the process for every custom domain that sends mail from the tenant. If you manage many domains, PowerShell can help scale the work. Microsoft’s DKIM guidance references PowerShell-based domain checks, and in larger environments teams often use Exchange Online PowerShell for inventory, validation, and automation around mail configuration.

It is also worth remembering that some non-sending domains can still be protected from spoofing with stronger authentication policy choices, especially once DMARC in Office 365 is in place. The goal is not just signing mail, it is reducing abuse across the organization’s full domain portfolio.

Set up DKIM in Office 365 as part of a stronger authentication strategy

To set up DKIM Office 365 successfully, start with the basics: verify the domain, gather the Microsoft-provided selector values, publish both required CNAME entries in public DNS, wait for propagation, and then enable signing in Microsoft 365. After that, validate the results through both DNS checks and live message headers.

When configured correctly for each custom domain, DKIM strengthens domain protection, supports email deliverability, and improves trust in business-critical email. And when it is paired with SPF and DMARC, it becomes part of a much more effective email security foundation.