How to fix DKIM body hash did not verify errors on Outlook.com and prevent emails from going to spam?
Updated on 18 Oct 2026: We clarified how to isolate Outlook.com DKIM body hash failures and verify recovery.
Fix this by proving whether the message body changes after DKIM signing, then removing that change in the ESP or sending pipeline. A bad subject line is not the usual cause of a body hash did not verify result. The subject is a header that is usually signed, but the bh= value is calculated over the body. When Outlook.com is the only receiver reporting the failure, check MIME structure, transfer encoding, line wrapping, non-ASCII content, tracking rewrites, footers, and the point where DKIM signing happens.
After DKIM verifies again, treat any remaining Junk placement as a separate problem. DMARC can pass through SPF even while DKIM fails. Domains sending at least 5,000 messages per day to Microsoft consumer email services must also meet Microsoft's separate high-volume authentication requirements, covered below.
What the error means
DKIM signs selected headers and a canonicalized version of the body. The receiving server recalculates the body hash and compares it to the bh= value in the DKIM-Signature header. If the recalculated body hash differs, Outlook.com reports body hash did not verify. That points to changed serialized body bytes or a difference in body canonicalization. The body includes encoded MIME parts and attachment data, not just the visible text or HTML.
Typical Authentication-Results headertext
Authentication-Results: hotmail.com; spf=pass smtp.mailfrom=newsletter.example; dkim=fail (body hash did not verify) header.d=newsletter.example; dmarc=pass action=none header.from=newsletter.example
Do not chase the subject first
A malformed subject can break DKIM if the subject header is signed and the header bytes change, but that usually appears as signature verification failure, not a body hash mismatch. With this specific error, inspect the message body and MIME layer before changing subject text.
|
|
|
|---|---|---|
SPF pass | Sending IP was authorized for the MailFrom domain | Check DMARC alignment |
DKIM fail (body hash mismatch) | Canonicalized body hash did not match | Compare raw body bytes |
DMARC pass | SPF or DKIM passed with DMARC alignment | Check Outlook volume rules |
How to read the main authentication signals.
Read mixed DKIM pass and fail results
A message can have multiple DKIM signatures, so dkim=pass and dkim=fail in the same Authentication-Results header can refer to different signatures. Even the same signing domain can appear more than once, as in this Microsoft Q&A example.
- Read the Authentication-Results added by Microsoft at receipt, rather than assuming an earlier relay's result describes Outlook.com's verdict.
- Match each result to its DKIM-Signature using header.d and, where present, header.s or header.b. The signing domain alone is insufficient when multiple signatures use it.
- Inspect the failing signature's selector, bh= value and body canonicalization mode. Different signing hops or modes can explain different results on one message.
- Check which passing signature supplies DMARC alignment. A pass for an unrelated ESP domain does not authenticate the visible From domain for DMARC.
If a gateway re-signs after editing the message, confirm that the new signature passes at Outlook.com and its d= domain satisfies DMARC alignment. A failed older signature does not automatically invalidate a separate passing signature.
Fix sequence for Outlook.com
DKIM body hash troubleshooting: capture sent and received messages, compare bodies, fix signing and retest Outlook.com.
Use a fixed order because random DKIM record changes waste time. If the same selector and key pass at other receivers and fail at Outlook.com, a DNS key problem is less likely. The useful evidence is the exact raw MIME message immediately after signing and the full message Outlook.com received. A Sent folder copy or a regenerated message does not establish which bytes were signed.
- Save the exact raw message immediately after DKIM signing and before final handoff, including all DKIM-Signature headers, MIME boundaries, transfer encoding and body bytes.
- Send a controlled test to an Outlook.com or Hotmail.com seed address. Open the received message, select More actions, then Download, and keep the .eml file. View > View message details shows headers, which are useful for authentication results but insufficient for a body comparison.
- Compare the encoded MIME body after the header/body separator. Preserve CRLF line endings and do not decode quoted-printable or base64 before reproducing the body hash. Look for rewrapped encoded lines, changed transfer encoding, appended footers, tracking pixels or added bytes.
- Confirm DKIM is applied after personalization, unsubscribe blocks, tracking links, attachments and final MIME assembly.
- Send a small plain text test, then a minimal HTML test, then the production template. Change one variable per test and stop when the failure appears.
The strongest single clue is the complete DKIM-Signature header. Many senders use c=relaxed/relaxed. In c=header/body, the second value controls body canonicalization; an omitted c= defaults to simple/simple. Relaxed body canonicalization removes spaces and tabs at line ends, compresses their runs within a line, and ignores empty lines at the end of the body. It does not tolerate inserted footers, rewritten URLs, changed transfer encoding, or rewrapped encoded data. If the signature uses simple body canonicalization, ask the ESP whether relaxed body canonicalization fits the sending path. If it already uses relaxed/relaxed, inspect MIME encoding and post-signing changes. If the bodies still appear identical, ask the ESP to reproduce the bh= calculation using the exact signed bytes and declared canonicalization. The broader body hash fixes follow the same evidence-first pattern.
DKIM-Signature fields to inspecttext
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=example.com; s=s1; bh=BASE64BODYHASH; h=from:to:subject:date:mime-version:content-type; b=BASE64SIGNATURE
What to ask the ESP
If an ESP adds DKIM, the ESP owns the signing boundary. The practical request is not "fix DKIM". Ask for the point where DKIM is added, the exact message bytes signed, and every modification that occurs after signing. This matters even more when only Microsoft properties show the failure.
Microsoft's troubleshooting guidance identifies transport rules and intermediary services as causes of post-signing body changes. Authenticated Received Chain (ARC) can preserve earlier authentication results through a modifying intermediary, but it does not make the original DKIM signature valid again. Microsoft 365 trusted ARC sealer settings are controlled by the receiving organization; they are not an Outlook.com sender-side repair.
Send this evidence request
- Where exactly is DKIM applied in the pipeline, before or after final content, attachments, and MIME assembly?
- Are tracking links, open pixels, unsubscribe footers, compliance disclaimers, or security scanning changes added after DKIM signing?
- Do transport rules, outbound gateways, forwarders, or relays modify the body, and can the last modifying hop DKIM-sign with our domain after those changes?
- Can the ESP confirm stable CRLF line endings, Content-Transfer-Encoding, charset, MIME boundaries, and encoded line wrapping?
- Can the ESP provide the exact source immediately after signing and compare it with the complete .eml file received by Outlook.com?
- Can the ESP confirm the body canonicalization mode and stable signing across all campaign variants?
If the ESP cannot provide raw samples, simplify one element at a time: dynamic modules, compliance footers, attachments, embedded images, tracking wrappers, or multipart nesting. Non-ASCII text is safe when charset and transfer encoding remain consistent, so test the encoding path instead of removing the text by default. Once the failure disappears, add each element back until it returns. If an 8bit MIME part is being converted in transit, test quoted-printable or base64 encoding before DKIM signing. Apply the encoding to the bytes as well as the Content-Transfer-Encoding header, and keep encoded lines within the MIME limit of 76 characters, excluding CRLF. Changing only that header does not encode the body, and re-encoding after signing breaks the body hash.
Validate DNS but do not stop there
DNS validation is still worth doing because a stale selector, multiple conflicting TXT records, or an incorrectly copied public key can create a separate DKIM failure. Use Suped's DKIM checker to confirm the selector publishes the expected valid key. For the example signature, check s1._domainkey.example.com, using s= for the selector and d= for the signing domain, and follow any provider CNAME to its key. A key lookup error and a body hash mismatch require different fixes; valid DNS does not prove that the received body matches the signed body.
DKIM checker
Check selector records and public key configuration.
?/7tests passed
For a wider domain review, the domain health checker helps spot related SPF, DKIM, and DMARC issues. A clean DNS result does not fix a body hash mismatch. A valid key is necessary for verification, but it does not prove the received body matches the signed body. Once the selector and key are confirmed, raw message comparison is the decisive test.
DKIM checker sample results showing selector, DKIM DNS record, validation checks, parameters, and share link
Why DMARC can pass and mail still lands in Junk
The example header has SPF pass, DKIM fail, and DMARC pass. That combination occurs when SPF passes and its MailFrom domain satisfies DMARC alignment with the visible From domain. DMARC requires one authentication pass with that alignment. Microsoft's high-volume sender rules require both SPF and DKIM to pass as well.
Authentication problem
- Outlook.com reports DKIM body hash failure.
- The signed body bytes changed or were canonicalized differently.
- Compare raw source, then move signing after all message edits.
Placement problem
- Mail still lands in Junk after DKIM verifies.
- Domain or IP reputation, recipient engagement, complaints, or other senders sharing the same IP.
- Review Microsoft performance, list quality, and blocklist (blacklist) signals.
Do not assume one broken campaign permanently "poisoned" DKIM. DKIM does not have memory. Microsoft filtering does track reputation and recipient behavior, so a run of unwanted mail, complaints, low engagement, or other senders sharing the same IP can keep placement poor after the technical DKIM issue is fixed.
A clean recovery order
- Get Outlook.com to show DKIM pass on a controlled test and a production-like campaign.
- Use fresh Outlook.com message headers to confirm the repair, then check subsequent Microsoft aggregate reports for the affected source and reporting period.
- After authentication complies, reduce risky sends, segment engaged recipients, review blacklist and blocklist status, and rebuild sending consistency.
- Monitor recurring DKIM failures, accounting for aggregate report delays, and use fresh message samples when an alert appears.
Outlook.com high-volume sender requirements
Microsoft began enforcing stricter authentication for high-volume Outlook.com senders on May 5, 2025. A domain reaches this category when it sends at least 5,000 messages per day to Microsoft consumer email services using the same domain in the visible From address. These services include Outlook.com, Hotmail, Live.com, and MSN consumer addresses. See Microsoft's sender requirements. This threshold concerns consumer mailboxes; do not apply it automatically to every Microsoft 365 business tenant.
DMARC pass is not enough at high volume
- Publish both records and make sure both checks pass on the message.
- Publish a DMARC record with at least p=none and pass DMARC through SPF or DKIM with DMARC alignment.
- A noncompliant message can be rejected with 550 5.7.515 instead of reaching the Junk folder.
- If no DKIM signature passes, treat the message as noncompliant even when the Authentication-Results header says dmarc=pass.
Fix the body hash error before working on inbox placement. If messages still land in Junk after SPF, DKIM, and DMARC meet the requirement, continue with reputation, complaint, list-quality, and engagement analysis as a separate workflow.
Outlook.com-specific tests
Outlook.com headers showing SPF pass, DKIM body hash did not verify and DMARC pass.
The failure becomes visible after Microsoft verifies the received message. It does not prove Microsoft changed the body, and it does not prove the sender's application made the change. Compare the complete path. Investigate encoded line wrapping, multipart boundaries, attachments, embedded images, charset handling, forwarding, gateways, and edits made after DKIM signing. Non-ASCII text is valid when correctly encoded. Overlong encoded lines or inconsistent charset declarations are reasons to inspect MIME construction and any conversion before verification.
|
|
|
|---|---|---|
Plain text | Base signer | DKIM pass |
Minimal HTML | HTML encoding | DKIM pass |
Add attachment | Multipart assembly | DKIM pass |
Full template | Dynamic modules | Same pass |
Tracking on | Post-processing rewrites | No result change |
Direct route versus gateway | Post-signing relay or transport rule changes | DKIM pass on both routes |
Compact test matrix for isolating the failing part.
If the same selector passes for plain text and fails for the full template, investigate message construction or post-processing before changing the DNS key. If plain text fails too, inspect the sender or ESP signer before changing the template. For more Microsoft-specific symptoms, the Outlook.com DKIM failures checklist is the next place to compare patterns.
How Suped fits into the workflow
Suped's DMARC reporting platform organizes authentication results by sending source and reporting organization. Use it to find affected sources, check whether SPF is carrying DMARC, and compare Microsoft's reported results with other receivers. Standard aggregate reports do not include message bodies or campaign identifiers; they cannot prove which template changed or which bytes broke the body hash.
In Suped's product, DMARC monitoring groups aggregate reports by source and receiver. Compare reporting periods after the ESP changes its pipeline and check whether SPF continues to satisfy DMARC alignment. Reports commonly arrive daily, so monitoring and alerts based on them follow report arrival. Verify individual messages with fresh Outlook.com headers and correlate reporting trends with ESP logs to isolate a campaign or route.
Issue steps to fix dialog showing the issue overview, tailored fix steps, and verification action
Build the ESP evidence package with the failing source, affected domain, receiving organization and reporting period, then attach the raw signed and received messages. That connects the reporting trend to a specific authentication fault instead of a general complaint about spam placement.
Views from the trenches
Best practices
Compare raw sent and raw received source before changing DNS or blaming the subject line.
Ask the ESP to prove DKIM is added after tracking, footers, and MIME assembly finish.
Retest at Outlook.com after each template or encoding change, not only in generic inboxes.
Common pitfalls
Treating DMARC pass as proof of inbox placement leaves reputation issues uninvestigated.
Changing selectors repeatedly without inspecting MIME structure hides the real body change.
Blaming non-ASCII text alone misses the charset or transfer-encoding rewrite that changed bytes.
Expert tips
Check the body canonicalization mode, then inspect encoded wrapping when Microsoft still fails.
Keep a known-good seed message so every production template has a stable comparison.
Pair authentication checks with blocklist (blacklist) review when spam placement persists.
Marketer view
Marketer from Email Geeks says DKIM breakage and spam placement should be handled as separate problems. When DKIM stops failing, audience quality and nearby sending infrastructure still need review.
2019-11-28 - Email Geeks
Expert view
Expert from Email Geeks says a body hash error means the message body changed after signing or the receiver processed the encoding differently.
2019-11-28 - Email Geeks
Frequently asked questions
Usually no. A subject line is a header, while the DKIM body hash is calculated from the body. A malformed subject can affect the DKIM signature if that header is signed, but the body hash error points first to body or MIME changes.
DMARC passes when either SPF or DKIM passes with DMARC alignment to the visible From domain. SPF can supply that pass while DKIM fails. Outlook.com's separate high-volume rules still require both SPF and DKIM to pass.
Not first. Reserve selector changes for key or DNS problems. A genuine body hash mismatch requires comparing the exact signed and received MIME bodies, even when the public key is valid. Check signing order and encoding before rotating selectors.
Send the full Authentication-Results header, every DKIM-Signature header, the exact raw message immediately after signing, and the complete .eml file received by Outlook.com. Ask where signing happens and whether an ESP process, gateway, forwarder, or transport rule changes the body afterward.
Fixing DKIM removes an authentication fault and helps high-volume senders avoid 550 5.7.515 rejection. It does not guarantee inbox placement after Microsoft accepts the message. Reputation, recipient engagement, complaint history, list quality, and sending infrastructure still affect placement.
