Office 365 DKIM setup: configure, verify, and troubleshoot it

Do not copy Microsoft 365 DKIM targets from a blog post.

The hostnames begin with selector1._domainkey and selector2._domainkey, but the values they point to are tenant- and domain-specific. Get both CNAME targets from your Microsoft 365 tenant, publish them exactly as your DNS host expects, enable DKIM, and then prove a real external message is signed.

The toggle is not the finish line. The received message is.

The Office 365 DKIM setup in five steps

1. Add and verify the custom domain in Microsoft 365.
2. Retrieve the exact Selector1CNAME and Selector2CNAME targets from the Defender portal or Exchange Online PowerShell.
3. Publish both CNAME records in the authoritative DNS zone.
4. Wait until both records resolve publicly, then enable DKIM signing for the domain.
5. Send a message outside the tenant and inspect DKIM-Signature and Authentication-Results.

Save the domain, tenant, record values, DNS owner, Microsoft status, test-message headers, and handoff owner in one record. Otherwise the next person will repeat the setup just to figure out what happened.

Know which domain Microsoft is signing

Microsoft automatically signs outbound mail from the tenant’s initial *.onmicrosoft.com domain. That does not mean a message using person@yourcompany.com is DKIM-aligned with yourcompany.com.

For a custom domain, publish the records and enable DKIM for that custom domain. The important value in the received DKIM-Signature header is d=. It identifies the signing domain. DMARC then checks whether an authenticated SPF or DKIM domain aligns with the visible From domain.

These are different statements:

• dkim=pass means the receiver validated a DKIM signature.
• header.d=yourcompany.com tells you which domain signed.
• dmarc=pass means at least one qualifying authentication path aligned with the visible From domain.

A message can have a valid Microsoft signature and still fail the alignment you intended. Always compare the visible From domain with the DKIM d= domain.

The SPF, DKIM, and DMARC guide explains that relationship in more detail. For this setup, stay focused on the custom domain Microsoft should sign.

Get the exact two CNAME targets

Microsoft creates two selectors so it can rotate keys. One selector signs at a time; the other gives Microsoft a second DNS path for a future key.

Both records are required. Publishing only selector1 may appear to work today and then leave rotation broken later.

Defender portal path

Microsoft’s current documented path is:

1. Open the Microsoft Defender portal.
2. Go to Email & collaboration.
3. Open Policies & rules, then Threat policies.
4. Choose Email authentication settings.
5. Open the DKIM tab.
6. Select the custom domain.
7. Copy both values shown under the prompt to publish CNAMEs.

Portal names move. The values in your tenant are authoritative; a screenshot from another tenant is not.

Exchange Online PowerShell path

Microsoft documents this command to retrieve the current targets:

Get-DkimSigningConfig -Identity example.com |
  Format-List Selector1CNAME,Selector2CNAME

If no signing configuration exists for the domain, Microsoft documents creating one in a disabled state before publishing DNS:

New-DkimSigningConfig -DomainName example.com -Enabled $false

Replace example.com with the exact accepted custom domain. Do not run a copied command against the wrong tenant and assume the output belongs to the domain you are configuring.

Translate the records into your DNS host

Microsoft gives you a hostname and target. Your DNS provider may ask for Name, Host, Label, Points to, Target, or Value.

The safe mapping looks like this:

Some DNS dashboards automatically append the zone name. If you paste selector1._domainkey.example.com into a field that already adds .example.com, the result may become:

selector1._domainkey.example.com.example.com

It looks close in the dashboard. It is the wrong hostname.

Other dashboards require the fully qualified name and may accept or require a trailing dot on the target. Follow the provider’s current instructions, then check public DNS rather than trusting the form preview.

Keep the source map

Save the record pair before changing DNS:

custom_domain:
microsoft_tenant:
selector1_host:
selector1_target:
selector2_host:
selector2_target:
target_source: Defender portal | Get-DkimSigningConfig
dns_provider:
dns_zone_owner:
published_at:
public_lookup_1:
public_lookup_2:
enabled_at:
verified_message_id:
verification_owner:

Do not store admin credentials in this record. Store who owns access and where the approved secret is managed.

Publish both records and verify public DNS

After saving the records, add both CNAMEs to the authoritative DNS zone. Before you enable DKIM, resolve each hostname from outside the DNS provider’s dashboard.

You are checking:

• the exact selector hostname exists;
• the record type is CNAME;
• it points to the exact Microsoft target from the tenant;
• the public answer is coming from the authoritative zone you intended;
• no duplicated domain label changed the hostname;
• both selectors resolve.

A generic “DKIM checker” may look for a TXT public key at the selector. Microsoft’s setup uses a CNAME from your domain into Microsoft’s DKIM infrastructure. Follow the chain. Confirm the CNAME resolves to the current Microsoft destination.

If the DNS dashboard shows the record but public resolvers do not, check the nameservers delegated for the domain. It is easy to edit a stale zone at a former DNS host while the active nameservers point somewhere else.

Enable DKIM only after DNS resolves

Once both public records resolve, enable the custom domain in the DKIM area of the Defender portal.

The PowerShell equivalent Microsoft documents is:

Set-DkimSigningConfig -Identity example.com -Enabled $true

Then inspect the status:

Get-DkimSigningConfig -Identity example.com |
  Format-List Name,Enabled,Status,Selector1CNAME,Selector2CNAME

Do not repeatedly toggle the setting while DNS is unresolved. Fix the record Microsoft cannot find. A settings change cannot repair the wrong hostname or target.

The Microsoft control plane may take time to recognize new public DNS. Record when the records first resolved and when enablement succeeded. That timeline is more useful than “we waited a while.”

Verify the real outbound message

Send through the exact Microsoft mailbox and application path the campaign will use. A direct test from Outlook proves something different from a message sent through a sequencer, relay, or application.

Deliver the message to an external mailbox you can inspect. Then save the raw headers and find:

DKIM-Signature: ... d=example.com; s=selector1; ...
Authentication-Results: ... dkim=pass ... header.d=example.com ...

Header formatting varies by receiver. Capture the complete values rather than copying a green icon from a checker.

Verify all of the following:

Do this before handoff. “Enabled” in Microsoft is configuration evidence. Authentication-Results on the received message is path evidence.

Troubleshoot the layer that failed

Microsoft reports CnameMissing

Resolve both selector hostnames publicly. Common causes are:

• the record was added to the wrong DNS provider;
• the DNS host appended the domain twice;
• a TXT record was created instead of a CNAME;
• the CNAME target was copied from an example or another tenant;
• selector2 is missing;
• the target format does not match what the DNS provider expects.

Compare the live answer with Selector1CNAME and Selector2CNAME from the tenant. Do not reconstruct the target by pattern.

The enable toggle returns to disabled

First confirm Microsoft can resolve both records and that the domain has a current DKIM signing configuration. Check the tenant status through PowerShell as well as the portal.

If the exact CNAMEs resolve and Microsoft still cannot generate or activate the keys, save the status, timestamps, domain, and current command output before escalating to Microsoft support. The evidence packet should let another person reproduce the failure without changing DNS again.

DKIM passes, but the wrong domain signs

Compare:

• visible From: domain;
• DKIM d= domain;
• DKIM selector s=;
• SPF-authenticated MAIL FROM domain;
• DMARC result.

If d= is the tenant’s onmicrosoft.com domain while the visible From address uses your custom domain, the custom-domain signing path is not the one you intended. Recheck which domain was enabled and which route sent the message.

DKIM passes, but DMARC fails

DKIM validation and DKIM alignment are separate. A valid signature from an unrelated domain does not align with the visible From domain under DMARC.

Check header.d against the From domain. Then inspect the SPF path as a separate possible aligned identifier. The DMARC failure guide gives you a source-by-source process instead of telling you to change policy first.

DKIM fails after forwarding or modification

DKIM covers selected headers and the message body. A service that changes signed content can break the signature. Compare the original submitted message, Microsoft’s trace where available, and the final received copy. Do not blame DNS if the public key resolves and the message changed after signing.

Rotation does not work

Microsoft alternates between selector1 and selector2 for key rotation. Both CNAMEs have to exist. Microsoft’s current documentation also describes a four-day period for a rotated key to start signing.

Record the rotation request, old selector, new selector, status, and first externally verified message using the new selector. Do not delete the inactive CNAME after one successful test; it is part of the next rotation path.

Hand the setup to the person who runs it

The final handoff should contain:

• custom domain and Microsoft tenant;
• authoritative DNS provider and nameservers;
• both selector hostnames and tenant-provided targets;
• Microsoft enablement status;
• active selector observed in a real message;
• received header showing dkim=pass and the signing domain;
• DMARC alignment result;
• date and exact application path tested;
• owner for DNS, Microsoft, sequencer, and incident escalation;
• next rotation review.

Cheap Inboxes supports domain, DNS, and Microsoft mailbox operations within its documented product surface. The developer overview shows the current public workflow. Microsoft remains the source for tenant-specific targets and signing behavior.

The setup is complete when the record pair resolves, Microsoft signs, the external receiver validates the signature, and the next operator owns the evidence.

Operate DKIM across more than one Microsoft domain

The setup becomes an operations problem once a tenant or agency has several domains. Keep one register with the custom domain, Microsoft tenant, both tenant-specific CNAME targets, DNS host and owner, public-resolution check, Microsoft DKIM status, external test date, sanitized header evidence, and change owner.

That record prevents an operator from publishing targets from the wrong tenant or assuming that ten similar-looking domains share one setup. Keep credentials and customer message content out of it; the required proof is the configuration plus a sanitized external header.

Use the same onboarding order every time: retrieve, publish, resolve, enable, send, inspect, record. During offboarding, decide whether the domain remains in the tenant, moves to another provider, or is retired. Removing DNS before the replacement path is verified can break working mail.

Recheck after the changes that matter

Run the external DKIM test again after a DNS-host migration, mailbox-provider migration, Microsoft tenant move, selector rotation, custom-domain removal, or gateway change. Do the same when an operator edits CNAME records while cleaning the zone.

Do not wait for a DMARC report or delivery problem to discover that the selector paths were lost during a migration.

Treat rotation as a verification event

Microsoft manages the private keys and can rotate the selector in use. Your job is to keep both published CNAME paths valid and confirm that external messages continue to pass.

If you trigger a rotation with Rotate-DkimSigningConfig, record the command time, wait for Microsoft’s documented rotation window, and inspect the selector on a newly received message. A portal status by itself does not prove the new signature reached the receiver.

The operating goal is boring: both selectors resolve, one valid Microsoft signature is present, the signing domain aligns, and someone knows what to do when that changes.

A safe DNS cutover for Microsoft 365 DKIM

Moving DNS providers is one of the easiest ways to lose a working DKIM setup. The new zone may contain the obvious website and MX records while the two selectors are forgotten.

Before changing nameservers:

1. Export or inventory the current authoritative zone.
2. Query both selector hostnames from a public resolver.
3. Retrieve the current targets from Microsoft again.
4. Add both CNAMEs to the new zone.
5. Check every related record in the new zone, including MX, SPF, DMARC, verification, and website records.
6. Lower TTL only when the DNS migration plan calls for it and the current provider allows enough time for the change to take effect.
7. Change delegation.
8. Confirm the new authoritative nameservers answer with the same CNAME targets.
9. Send through the production application path and inspect the received signature.

Do not remove the old zone until the delegation and message test are complete. A DNS dashboard showing the copied record is not proof that the internet is asking that dashboard for the answer.

Moving the domain between Microsoft tenants

A tenant move is not a normal selector rotation. The destination tenant returns its own target values for the custom domain.

Capture the source tenant’s known-good evidence before the move. Follow Microsoft’s current custom-domain removal and addition process, retrieve the destination values, publish them, enable signing, and verify an external message from the destination path.

Do not assume the old CNAME targets can remain because both environments are Microsoft 365. The tenant and domain pair determines the values.

If the domain also receives mail, coordinate DKIM with the MX and mailbox migration. Outbound signing can be correct while replies still route to the old tenant—or the reverse.

Give support a reproducible failure

If both public CNAMEs match the tenant output but Microsoft will not enable DKIM, prepare a small evidence packet:

• Custom domain and tenant identifier suitable for the support case.
• UTC timestamps for record publication, first public resolution, and enablement attempt.
• Get-DkimSigningConfig output showing status and both targets.
• Public DNS answers from more than one resolver.
• Screenshot or exact portal error.
• Whether the domain was recently added, removed, or moved.
• Sanitized header from the latest external test.

Do not keep changing correct DNS while the case is open. Every unrecorded edit resets the evidence support is trying to inspect.

If a sequencer message fails but a direct Outlook message passes, include both paths. The difference tells the next operator to investigate the application connection and actual sending route rather than rewriting the DKIM records.

The final verification record

Close the setup with one concise result:

domain: example.com
tenant: <owned tenant reference>
selector1: resolves to tenant-provided target
selector2: resolves to tenant-provided target
dkim_enabled: true
tested_path: <mailbox and application>
received_result: dkim=pass
header_d: example.com
active_selector: selector1 | selector2
dmarc_alignment: pass | separately investigated
verified_at: <UTC timestamp>
owner: <team or person>

That record is small enough to maintain and complete enough to compare after the next change.

Sources

• Microsoft Learn: Configure DKIM for email in a custom domain
• Microsoft Learn: Email authentication in Microsoft 365
• RFC 6376: DomainKeys Identified Mail
• RFC 8301: Cryptographic algorithm and key usage update for DKIM