Why are Microsoft Office 365 DKIM signatures failing and how to fix it?
Published 14 Jun 2025
Updated 22 Jul 2026
13 min read
Summarize with
Updated on 22 Jul 2026: We updated this guide with Microsoft's current CNAME format, key rotation timing, and signed-header troubleshooting.
Microsoft Office 365 DKIM signatures fail when Microsoft 365 does not sign the custom From domain, either selector CNAME is missing or points to the wrong tenant-specific target, a DNS lookup fails, or a gateway changes signed headers or body content. A receiver can also report a failure because of an older or incompatible verifier. The fix is to separate sender-side configuration errors from route and receiver-side verification errors before changing DNS.
Start with the raw message headers, confirm the two Microsoft selector records in DNS, then send a fresh test message through the exact route that users use. A DKIM check helps confirm the public key side, but the header tells you whether Microsoft signed the message and what the receiver actually verified.
- No signature: Microsoft 365 did not add a DKIM-Signature header for the custom From domain.
- Bad DNS: The selector points to an old, missing, mistyped, or wrong tenant CNAME target.
- Changed content: A disclaimer, security gateway, relay, or mailing tool modified signed parts after Microsoft signed them.
- Verifier issue: One receiver reports fail while another verifier reports pass for the same message.
What an Office 365 DKIM failure means
A DKIM failure means the receiver could not verify the signature with the public key returned by DNS. The cause can be a missing or mismatched key, a malformed signature, a DNS lookup error, or a signed header or body that changed in transit. Office 365 adds a DKIM-Signature header that contains the signing domain in d=, the selector in s=, the signed header list in h=, the body hash in bh=, and the signature in b=. The c= tag states the header and body canonicalization rules used during verification.
What the failure result means
- dkim=none: No signature was found, or the receiver ignored it because it was malformed.
- dkim=fail: A signature was present, but the DNS key or signed message content did not verify.
- dkim=temperror: Verification hit a temporary problem, commonly a DNS timeout or unavailable key lookup.
- dkim=pass: The signature verified, but DMARC still needs the signing domain to match the visible From domain.
A common mistake is treating every Office 365 DKIM failure as a DNS issue. DNS is the right first check, but a valid CNAME cannot repair a signature broken by a relay that appends a banner, rewrites links, changes MIME boundaries, or rewrites a header listed in the signature's h= tag.
Flowchart showing the Office 365 DKIM troubleshooting sequence.
Check the Microsoft 365 DKIM configuration first
For a custom domain, Microsoft 365 uses two DKIM selector CNAME records. Microsoft says custom domains need DKIM configured so mail is signed by the visible From domain, and the exact CNAME targets should be copied from the Defender portal or Exchange Online PowerShell. Microsoft introduced a newer target format for newly added custom domains in May 2025. It includes a tenant-specific dynamic partition character, while existing domains can still use the earlier onmicrosoft.com target pattern. The old and new target formats cannot coexist for the same selector.
Use the Microsoft DKIM setup page for the current portal path and PowerShell commands. Do not construct the target from a blog example. Get the values generated for your tenant and domain.
Publish both records as CNAMEs, even though only one selector signs at a time. The inactive selector is required for key rotation. Use a TTL of at least 3600 seconds, do not publish a TXT key for Microsoft 365, and check whether your DNS provider automatically appends the domain to the selector hostname.
Microsoft Defender portal DKIM tab showing domain status and selector CNAME values.
Example DKIM CNAME patterndns
selector1._domainkey.example.com. 3600 IN CNAME selector1-example-com._domainkey.example.n-v1.dkim.mail.microsoft. selector2._domainkey.example.com. 3600 IN CNAME selector2-example-com._domainkey.example.n-v1.dkim.mail.microsoft.
Confirm selectors with PowerShellpowershell
Get-DkimSigningConfig -Identity example.com | Format-List Name,Enabled,Status,Selector1CNAME,Selector2CNAME
DKIM checker
Check selector records and public key configuration.
?/7tests passed
Match the symptom to the fix
A clean fix depends on the symptom. Use the result code, signing domain, selector, and route history together. A single header line rarely tells the whole story, especially with Microsoft 365 because messages can have both a Microsoft service signature and a customer-domain signature.
|
|
|
|---|---|---|
dkim=none | Not signed | DKIM toggle |
CnameMissing | DNS missing | Selector host |
dkim=temperror | DNS timeout | TTL and DNS |
body hash | Content changed | Relay path |
One receiver | Verifier issue | Second test |
DMARC fail | Domain mismatch | From domain |
Office 365 DKIM failure symptoms and next checks.
If the domain shows CnameMissing in Microsoft 365, fix DNS before testing anything else. If Microsoft shows signing enabled and the header has a customer-domain DKIM signature, move to route inspection. If one receiver fails but another passes the same message, keep the sending setup stable and test with a second verifier before rotating keys.
- Header first: Inspect Authentication-Results, DKIM-Signature, Received, and ARC headers together.
- Selector second: Check whether the selector in the message matches selector1 or selector2 in DNS.
- Route third: Find every system between Microsoft 365 and the final recipient.
- Policy last: Only tighten DMARC after legitimate Microsoft 365 mail passes consistently.
Sender-side fixes for Microsoft 365
When the problem is on the sender side, enable DKIM for the custom domain, publish both selector records, wait for DNS propagation, then verify that fresh outbound mail has a DKIM-Signature header where d= matches the visible From domain or an accepted subdomain strategy.
Do not rotate keys as the first move
Key rotation is useful when the published key is stale or compromised. It is the wrong first move when the message body or a signed header is changing after signing. Rotating a clean key produces a new clean key, then the next relay breaks the signature again.
Microsoft 365 key rotation takes four days (96 hours) before the new selector signs mail, and another rotation cannot start during that period. Changing key size from 1024 to 2048 bits updates only the next active selector on the first rotation. A later second rotation updates the other selector.
Sender-side failure
- Portal status: Microsoft shows disabled, NoDKIMKeys, or CnameMissing.
- Header result: No customer-domain DKIM-Signature appears on fresh external mail.
- Fix path: Publish the exact CNAMEs, enable signing, and retest with new mail.
Route or receiver failure
- Portal status: Microsoft shows signing enabled and the selector exists.
- Header result: A signature exists, but one receiver reports verification failure.
- Fix path: Compare headers across receivers and remove post-signing changes.
If the message is not signed at all, first confirm the test went to an external email system. Microsoft can omit the DKIM signature when sender and recipient addresses use the same domain or different domains controlled by the same Microsoft 365 organization. For external mail, confirm the domain is listed on the DKIM tab and the toggle is enabled after both CNAMEs are detected. A third-party platform that sends directly using your domain needs its own DKIM setup because Microsoft 365 cannot sign mail that never exits through Microsoft 365.
Receiver-side verification failures
A receiver-side failure is real in the sense that a receiver reports dkim=fail, but it does not always prove the sender made a bad signature. The same Office 365 signature can fail in one verification stack and pass in another. That points to verifier behavior, parser behavior, or a local library issue.
Header pattern to investigatetext
Authentication-Results: mx.example.net; dkim=fail reason="signature did not verify" header.d=example.com DKIM-Signature: v=1; a=rsa-sha256; d=example.com; s=selector1; bh=abc...; b=def...
Older DKIM verification libraries remain in some receiving stacks, and older builds have produced confusing results with Microsoft signatures. If your own mail server marks every Microsoft-signed message as DKIM failed, but other mailbox providers verify the same fresh message, update the verifier before changing the sender setup. For a deeper related case, see intermittent Office 365 DKIM failures.
- Retest fresh mail: Forwarded samples can have changed bodies and misleading header history.
- Compare receivers: Send the same message to two independent mailboxes and compare results.
- Update verifiers: Patch older DKIM libraries before treating Microsoft signing as broken.
Fix signed header failures
A "signature did not verify" result can mean an intermediary changed a header that Microsoft included in the signature. Read the h= tag to identify the protected headers, then compare those fields before and after each gateway. Common examples include From, Subject, Date, Message-ID, Content-Type, and MIME-Version.
Signed header fields to comparetext
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=example.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=abc...; b=def...
Microsoft 365 uses relaxed header and body canonicalization by default for new configurations. Relaxed canonicalization tolerates common whitespace and header case changes, but it does not make a substantive subject, address, MIME, or body edit safe. The durable fix is to stop changing signed content, make the change before Microsoft signs, or have the final modifying gateway add its own DKIM signature using a domain that matches the visible From domain.
- Read h=: Only headers listed in the signature need comparison for this failure path.
- Trace each hop: Use Received headers and gateway logs to locate the first substantive change.
- Re-sign last: If a gateway must edit mail, apply a matching DKIM signature after that edit.
- Use ARC carefully: Trusted ARC can preserve earlier authentication through complex inbound routes, but it does not change a broken DKIM result into dkim=pass.
Fix body hash failures and message changes
A body hash failure means the body received by the verifier differs from the body Microsoft signed. Common causes include footers, legal disclaimers, antivirus rewrites, URL rewriting, content-transfer encoding changes, and altered MIME boundaries. The fix is to stop the downstream system from changing signed content or configure the last modifying system to add a DKIM signature using a domain that matches the visible From domain.
Infographic showing how post-signing changes break an Office 365 DKIM signature.
The right test is a route-controlled test. Send one message directly out of Microsoft 365 with no outbound gateway, then send an identical message through the normal route. If the direct route passes and the routed message fails, DNS is not the problem. The problem is downstream of Microsoft signing.
- Disable edits: Turn off disclaimers and content rewrites for one controlled test.
- Move signing: If a gateway must edit messages, apply a matching DKIM signature after that gateway edits them.
- Check forwarding: Forwarding can preserve, add, or damage authentication evidence.
- Use raw source: Screenshots of Outlook results are useful, but raw headers are decisive.
For a broader troubleshooting sequence across DKIM tools and headers, see how to troubleshoot DKIM failures.
How Suped fits into the fix
Suped is our DMARC reporting and email authentication platform. The setup fix still happens in Microsoft 365 and DNS, while Suped supports the ongoing workflow by grouping failures by source, flagging authentication issues, sending alerts, and connecting DKIM, SPF, DMARC, blocklist (blacklist), and deliverability signals.
Issue steps to fix dialog showing the issue overview, tailored fix steps, and verification action
For Office 365, Suped tracks whether Microsoft 365, gateways, and third-party senders are producing authenticated mail for the expected domain. The public domain health check is a quick starting point, while Suped's DMARC reports show results across real traffic.
Practical monitoring workflow
- Detect issues: Use Suped alerts when DKIM pass rates drop or new unverified sources appear.
- Fix DNS: Use Microsoft-generated selector values, then verify the public records.
- Monitor traffic: Use aggregate reports to confirm legitimate Office 365 mail keeps passing.
- Stage policy: Move DMARC policy forward only after authentication is stable.
?
What's your domain score?
Deep-scan SPF, DKIM & DMARC records for email deliverability and security issues.
Monitoring targets after the fix
After a fix, do not judge success from one test email. Check real sending paths, including user mail from Outlook, shared mailbox mail, application mail routed through Exchange Online, and marketing or transactional platforms using your domain. Microsoft explains the broader SPF, DKIM, and DMARC relationship in its Microsoft authentication overview.
Operational DKIM pass-rate bands
Use these internal triage bands after changing Office 365 DKIM records or message routing. They are not Microsoft or DKIM protocol requirements.
Healthy
99%+
A practical target for stable Microsoft 365 sender paths.
Needs review
95-98.9%
Investigate by source and route before policy changes.
Active issue
<95%
Treat as a configuration or routing problem.
No data
0
Send controlled test mail and wait for reports.
This is where DMARC monitoring becomes operationally useful. A raw header proves one sample. DMARC aggregate data shows whether authentication is improving across the domain.
- Daily review: Look for new Microsoft 365 failures after DNS, gateway, or routing changes.
- Source review: Separate user mail, app mail, bulk senders, and forwarded mail.
- Policy review: Move toward quarantine or reject only when legitimate sources pass.
Views from the trenches
Best practices
Compare the same Microsoft 365 message across receivers before changing DNS records.
Keep raw headers for every DKIM failure so route changes and selector values stay visible.
Verify Microsoft-generated CNAME targets after tenant changes and key rotations.
Common pitfalls
Treating every Office 365 DKIM failure as a DNS issue wastes troubleshooting time.
Relying on forwarded samples hides the original signed body and authentication path.
Ignoring older verifier libraries can make valid Microsoft signatures appear broken.
Expert tips
Test direct Microsoft 365 delivery and normal routed delivery as separate samples.
Check whether a gateway strips Microsoft DKIM and replaces it with its own signature.
Track display changes in Outlook separately from cryptographic DKIM verification.
Expert from Email Geeks says Microsoft-signed mail can fail in one DKIM verifier while passing in another, so teams should confirm with a second verification path before declaring the sender broken.
2020-11-20 - Email Geeks
Marketer from Email Geeks says some organizations strip the Office 365 signature at the gateway and apply their own signature, which changes where the DKIM fix needs to happen.
2020-11-20 - Email Geeks
What to fix first
Fix the Microsoft 365 selector CNAMEs first if DKIM is disabled, missing, or stuck at CnameMissing. Fix the mail route first if direct Microsoft 365 mail passes but routed mail fails. Update or replace the verifier first if the same message passes elsewhere but your local checker rejects every Microsoft signature.
After that, monitor real traffic rather than trusting one test. Suped helps connect ongoing DMARC, SPF, DKIM, blocklist (blacklist), and deliverability evidence to source-level issues, alerts, and fix steps. This workflow helps teams keep Office 365 authentication stable after the initial DNS correction.
