Microsoft 365 DKIM: Enable and Verify Custom-Domain Mail

Microsoft 365 DKIM should sign outbound mail with your own sending domain, not merely leave you hoping that a generic authentication pass is enough. For Exchange Online administrators, the practical job is to publish the right DNS selectors, enable signing, and prove the result at an external recipient. This runbook takes one custom domain from baseline to verified signatures without changing mail routing or tightening DMARC at the same time.

Our recommendation: configure one known sending domain, keep both selector records, and save receiving-system evidence before expanding. A green portal toggle is a configuration check; it is not your delivery test.

Why this matters now

Make this a November 2026 hardening task if a new domain, acquisition, or sending subdomain has never had its outbound signatures checked. This is established functionality, not a new retirement deadline. Each custom domain or subdomain used to send mail from Microsoft 365 needs its own DKIM configuration.

DKIM signs important message headers and the body so a receiving service can verify their integrity. SPF authorizes sending sources, while DMARC connects authentication to the visible From domain. These controls complement mailbox protections; they do not replace the legacy-authentication blocking runbook or your plan for stronger user authentication.

The useful finish line is specific: fresh external mail has a passing signature for the intended domain, public DNS contains both expected selectors, and the change ticket contains enough evidence for another admin to repeat the check.

Before you start

The procedure below uses the portal for changes and PowerShell for optional repeatable checks. Replace placeholders before running any command. These are administrator instructions, not a script to execute unchanged across every domain.

Step-by-step: Microsoft 365 DKIM for one custom domain

1. Capture the baseline

Open Microsoft Defender portal > Email & collaboration > Policies & rules > Threat policies > Email authentication settings > DKIM, the documented configuration path. Select the intended domain and record its toggle, status, and selector values. In the DNS provider, save any existing records at both selector names. Also record the current SPF and DMARC values without changing them.

List mail sources using that visible From domain: Exchange Online, ticketing, payroll, marketing, and any outbound gateway. Send a baseline message from the pilot mailbox to your external test account and retain its headers. Check it worked: the ticket identifies one domain, its current state, and the actual route of the test message. If signing is already enabled and external checks pass, verify and document it rather than recreate keys.

2. Get tenant selectors

For a domain showing NoDKIMKeys and a disabled toggle, follow the portal enablement sequence: try moving the domain toggle to Enabled. The documented Client error supplies the required CNAME values; acknowledge it, then reopen the domain details. The expected state is still disabled, now CnameMissing. Copy both targets from Publish CNAMEs.

If the domain already shows CnameMissing, copy its existing targets instead. For a repeatable read-only check, connect with modern authentication and inspect the configuration:

Import-Module ExchangeOnlineManagement
Connect-ExchangeOnline -UserPrincipalName <ADMIN_UPN>
Get-DkimSigningConfig -Identity <CUSTOM_DOMAIN> |
  Format-List Name,Enabled,Status,Selector1CNAME,Selector2CNAME

If no configuration is returned, confirm the domain exists with Get-AcceptedDomain. The documented PowerShell alternative creates a disabled configuration before publishing DNS:

New-DkimSigningConfig -DomainName <CUSTOM_DOMAIN> -Enabled $false

Re-run the read command afterward. Check it worked: Name matches your domain and both Selector1CNAME and Selector2CNAME are recorded. Do not construct the targets from an example: new-domain target formatting changed in May 2025, while older domains can retain the earlier format. Your tenant values decide which applies.

3. Publish both CNAMEs

In the authoritative DNS provider’s record editor, add a CNAME named selector1._domainkey pointing to the captured Selector1CNAME, and another named selector2._domainkey pointing to Selector2CNAME. Follow the provider’s hostname and fully qualified target conventions; some consoles append the zone automatically. Microsoft’s DNS troubleshooting guidance covers duplicated domain suffixes and requires Cloudflare records to be DNS only.

Check public DNS from your workstation, not just the provider’s saved-record screen:

nslookup -type=CNAME selector1._domainkey.<CUSTOM_DOMAIN>
nslookup -type=CNAME selector2._domainkey.<CUSTOM_DOMAIN>

Check it worked: both answers contain the exact corresponding tenant targets. One active selector does not make the second optional: the alternate selector is needed for key rotation. If the answers are absent or stale, resolve the DNS issue before proceeding.

4. Enable signing

Return to the same DKIM domain flyout and enable Sign messages for this domain with DKIM signatures. Acknowledge the synchronization notice and refresh. The expected flyout status is Signing DKIM signatures for this domain. The equivalent change in Exchange Online PowerShell is:

Set-DkimSigningConfig -Identity <CUSTOM_DOMAIN> -Enabled $true

Check it worked: repeat the Step 2 read command and confirm Enabled: True and Status: Valid. If Microsoft has not detected both CNAMEs, examine the returned error and DNS answers. Do not treat repeated toggle attempts as a substitute for correct records.

5. Test external mail

Allow a few minutes after the change, then send a fresh message from the pilot mailbox to your controlled mailbox at another email service. Open the original message headers at the receiver. Microsoft’s verification procedure requires an external recipient; mail within the same organization can omit the signature even when signing is configured.

Find DKIM-Signature: its d= identifies the signing domain and s= identifies the selector. Then read that receiver’s Authentication-Results for dkim=pass or its equivalent. Check it worked: the passing result corresponds to your intended domain’s signature, not an unrelated service signature. Retain the timestamp, From domain, signing domain, selector, and receiver result.

If DMARC is already configured, check its result too. DMARC requires aligned SPF or aligned DKIM; a DKIM pass alone does not prove alignment with the visible From address. Test the real outbound gateway route if it differs from direct Exchange Online delivery.

6. Record the handoff

Attach the final configuration output, both public DNS answers, and fresh receiver headers to the change ticket. Name the DNS owner and mail-service owner, then record other domains and senders that remain unverified. A third-party sending service needs its own provider-specific DKIM setup; enabling Exchange Online signing does not configure its messages.

Check it worked: another admin can identify the tested domain, reproduce the external check, and tell which senders are outside this change. Schedule remaining domains as separate scoped work, rather than close a tenant-wide task after testing one mailbox.

Verify the result

• Both public CNAME answers match the tenant-generated targets.
• The domain is enabled with a Valid configuration status.
• A fresh external message passes DKIM for the intended signing domain.
• Existing DMARC results are checked, not inferred from a generic pass.
• Baseline, final evidence, owners, and untested senders are recorded.

Keep full headers in your controlled operational record. Share only the necessary excerpts with stakeholders; they can contain addresses and routing details. The test evidence supports this domain and route, not every application that happens to use the same brand name.

Roll back

Repair incorrect DNS or a modifying gateway first. Disable signing only when the change owner approves a temporary rollback: turning off custom-domain DKIM stops that signature, and it can remove the aligned authentication path that mail relied on.

1. For a domain newly enabled in this change, return to its DKIM flyout and set the signing toggle to Disabled. The command alternative is shown below.
2. Re-run the configuration read and confirm Enabled is False. Preserve the new CNAMEs unless an approved restoration requires returning a changed record to its captured baseline.
3. Send another fresh external message, check delivery and authentication, and record the remaining risk. Do not weaken an existing DMARC policy as an unapproved shortcut.

Set-DkimSigningConfig -Identity <CUSTOM_DOMAIN> -Enabled $false

Troubleshooting

Use the DKIM setup and troubleshooting reference to separate DNS detection from message-path failures.

FAQ

Should I rotate keys during initial setup?

Keep rotation separate from the first enablement test. Manual rotation takes four days, or 96 hours, before the alternate key signs messages; another rotation cannot start while one is in progress. If upgrading from 1024 to 2048 bits, the documented process requires a subsequent rotation to upgrade the other selector too.

Can I copy the parent domain’s setup to a subdomain?

No. Retrieve the configuration for the exact sending subdomain. Its own selector records and signing configuration are required; do not reuse the parent’s targets merely because the names look similar.

Should I switch DMARC to reject after one successful test?

No. One Exchange Online message does not validate payroll, marketing, or application mail. Follow the gradual DMARC rollout with sender inventory and report review as a separate change. Keep any existing enforcement in place while fixing this scoped configuration.

Last reviewed: November 2026

Sources

• Configure and verify DKIM for custom domains (Microsoft Learn)
• Configure DMARC and plan a gradual rollout (Microsoft Learn)
• How email authentication works (Microsoft Learn)
• Connect to Exchange Online PowerShell (Microsoft Learn)
• Email protection deployment roles and prerequisites (Microsoft Learn)