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 sits in the signed header set, but the bh= value is calculated over the body. When Outlook.com is the only receiver reporting the failure, I look first at MIME structure, transfer encoding, line wrapping, non-ASCII characters, tracking rewrites, footers, and where DKIM signing happens.
After DKIM verifies again, treat Junk placement as a separate problem. DMARC can pass because SPF passes with the visible From domain, even while DKIM fails. That proves the message authenticated well enough for DMARC, but it does not prove Microsoft trusts the sending domain, IP, list quality, or recent engagement.
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 body content, body encoding, or body canonicalization.
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, the faster path is to inspect the message body and MIME layer before changing subject text.
|
|
|
|---|---|---|
SPF pass | Sending IP was authorized | Check match |
DKIM fail | Body changed or parsed differently | Compare source |
DMARC pass | Aligned SPF or DKIM passed | Separate placement |
How to read the main authentication signals.
Fix sequence for Outlook.com
A five-step flow from raw message capture to Outlook.com retesting.
I handle this in a fixed order because random DKIM record changes waste time. If the same message passes at other receivers and fails at Outlook.com, the public key is probably not the root cause. The useful evidence is the raw MIME source before sending and the raw MIME source after Outlook.com receives it.
- Capture source: Save the exact raw message generated by the ESP before final handoff, including MIME boundaries, headers, and body bytes.
- Save Outlook: Send the same campaign to an Outlook.com or Hotmail.com seed address, then export the received message source.
- Compare body: Diff the MIME body, not the rendered HTML. Look for changed line endings, folded long lines, rewritten transfer encoding, appended footers, tracking pixels, or whitespace added after the closing HTML.
- Check signing: Confirm DKIM is applied after personalization, unsubscribe blocks, tracking links, click tracking, and final MIME assembly.
- Retest safely: Send a small plain text test, then a minimal HTML test, then the production template. Stop when the failure appears.
The strongest single clue is the complete DKIM-Signature header. The canonicalization value should usually be c=relaxed/relaxed for marketing and newsletter mail, because it tolerates normal header folding and body whitespace changes. If the signature uses simple body canonicalization, ask the ESP to change it. If it already uses relaxed/relaxed, move deeper into MIME encoding and post-signing body changes. 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". It is a precise request for the point where DKIM is added, the exact message bytes signed, and any modifications that occur after signing. This matters even more when only Microsoft properties show the failure.
Receiver-specific cases have been discussed publicly in a Microsoft Answers thread and a Spam Resource post. The repeating pattern is simple: the message passes elsewhere, then Microsoft reports a body hash mismatch, so the sender needs byte-level evidence instead of guesses.
Send this evidence request
- Signing point: Where exactly is DKIM applied in the pipeline, before or after final HTML, text, and MIME assembly?
- Final changes: Are tracking links, open pixels, unsubscribe footers, headers, or compliance text added after DKIM signing?
- Encoding proof: Can the ESP confirm stable CRLF line endings, Content-Transfer-Encoding, charset, and MIME boundaries?
- Raw samples: Can they provide the raw signed source and compare it with the source received by Outlook.com?
- Signer config: Can they confirm relaxed/relaxed canonicalization and stable signing across all campaign variants?
If the ESP cannot provide raw samples, reduce the campaign until it passes. Remove dynamic modules, long legal copy, non-ASCII characters, deep tracking wrappers, and complex multipart nesting one by one. Once the failure disappears, add pieces back until it returns.
Validate DNS but do not stop there
DNS validation is still worth doing because a stale selector, split TXT record, or copied public key can create noise. Use the DKIM checker to confirm the selector publishes a valid key. If the same selector passes at other receivers, DNS is less likely to be the root cause, but this check clears the obvious mistakes before you push the ESP.
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. I still would not treat a clean DNS result as a fix for this error. Body hash failures happen after the key lookup succeeds, so the decisive test is still raw message comparison.
DKIM checker sample results showing selector, DKIM DNS record, validation checks, parameters, and share link
In Suped's product, this same workflow moves from DNS validation into ongoing authentication monitoring. That matters because a one-off seed test tells you what happened to one message, while aggregate reporting shows whether Microsoft failures are limited to one campaign, one sender, one template, or one ESP route.
Why DMARC can pass and mail still lands in Junk
The header in the question has SPF pass, DKIM fail, and DMARC pass. That combination is common when SPF matches the visible From domain. DMARC does not require both SPF and DKIM to pass. One matching pass is enough.
Authentication problem
- Symptom: Outlook.com reports DKIM body hash failure.
- Likely cause: MIME, encoding, or body content changed after signing.
- Fix path: Compare raw source, then move signing after all message edits.
Placement problem
- Symptom: Mail still lands in Junk after DKIM verifies.
- Likely cause: Reputation, engagement, complaints, or nearby sending traffic.
- Fix path: 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 poor network neighbors can keep placement poor after the technical DKIM issue is fixed.
A clean recovery order
- Fix DKIM: Get Outlook.com to show DKIM pass on a controlled test and a production-like campaign.
- Watch DMARC: Confirm Microsoft aggregate reports stop showing DKIM failures for that source.
- Repair placement: Reduce risky sends, segment engaged recipients, review blacklist and blocklist status, and rebuild sending consistency.
- Keep alerts: Set monitoring so a future DKIM body failure does not sit unnoticed for a full campaign cycle.
Outlook.com-specific tests
An Outlook.com message source view showing authentication results for a DKIM failure.
Outlook.com failures often show up only after the message hits Microsoft infrastructure. That does not prove Microsoft is wrong, and it does not prove the sender is wrong. It means the sender needs a message format Microsoft can verify consistently. The common triggers are long lines, unusual multipart nesting, unstable quoted-printable wrapping, non-ASCII body text, and changes made after DKIM signing.
|
|
|
|---|---|---|
Plain text | Base signer | DKIM pass |
Minimal HTML | HTML encoding | DKIM pass |
Full template | Modules | Same pass |
Tracking on | Rewrites | No change |
Compact test matrix for isolating the failing part.
If the plain text message passes and the full template fails, the DKIM key is not the problem. If plain text fails too, the sender or ESP signer is broken more broadly. 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 is the best overall DMARC platform for this workflow when a team needs more than a one-off header check. It does not change Outlook.com's filtering rules. It gives you the evidence layer: which sources send for the domain, where DKIM fails, whether SPF is carrying DMARC, and whether failures are isolated to Microsoft receivers or spread across the domain.
In Suped's product, DMARC monitoring pulls aggregate reports into a source-level view, then issue detection points at practical fixes. Hosted SPF, Hosted DMARC, Hosted MTA-STS, SPF flattening, real-time alerts, blocklist monitoring, and MSP dashboards are useful once the immediate DKIM error turns into a broader authentication and deliverability program.
Issue steps to fix dialog showing the issue overview, tailored fix steps, and verification action
The key advantage is operational: the person fixing the issue sees the failing source, the affected domain, the likely cause, and the next verification step in one place. That reduces the back-and-forth with an ESP because the request can include concrete failure evidence instead of a vague 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.
Ignoring long lines and non-ASCII payloads misses common Outlook.com body rewrites in mail.
Expert tips
Use relaxed/relaxed signing, then inspect line wrapping when failures stay with Microsoft.
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 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 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
The practical fix
The practical fix is to stop treating this as a DNS mystery. Validate the selector, then compare the raw sent message with the raw message Outlook.com received. If the body changed, move DKIM signing later or remove the post-signing change. If the body did not visibly change, ask the ESP to inspect canonicalization, transfer encoding, line endings, and signer behavior.
Once DKIM passes at Outlook.com, keep watching placement separately. DMARC pass means authentication policy passed. It does not guarantee inbox placement. Reputation, list quality, complaint rates, and Microsoft-specific engagement still decide where the message lands.
