The "DKIM body hash did not verify" error, especially when it occurs exclusively with Outlook.com and Hotmail.com, indicates a critical issue with your email's authenticity that can severely impact deliverability. This specific error signifies that the content of your email, or certain parts of its structure, were altered after the DKIM signature was applied, but before the message reached Microsoft's servers. While seemingly a minor technical glitch, it can lead to your emails being marked as spam or rejected entirely by Microsoft mailboxes, despite other authentication checks like SPF and DMARC passing.
Key findings
Encoding issues: A common cause for DKIM body hash failures is improper character encoding (e.g., non-ASCII characters) or malformed message structures that cause Microsoft's systems to modify the email body in transit.
In-transit modification: The error explicitly means the email body content, or specific headers included in the DKIM signature, did not match the hash recorded when the email was signed. This suggests a modification occurred after signing but before Microsoft's servers verified it.
Microsoft's unique handling: Microsoft's mail servers (Outlook.com, Hotmail.com, Office 365) can sometimes be more sensitive or have specific quirks that lead to email body rewrites, even if other mail clients accept the DKIM signature. This makes troubleshooting the specific issue for Microsoft email deliverability challenging.
Canonicalization method: The DKIM canonicalization method (e.g., relaxed/relaxed versus simple/simple) determines how strictly the email body and headers are processed for hashing. If the sender uses a 'simple' canonicalization, even minor changes can break the signature. However, 'relaxed' canonicalization should tolerate some common modifications.
Impact on spam placement: A failed DKIM signature significantly degrades your email's trustworthiness, leading to high spam scores and poor inbox placement, even if SPF and DMARC pass. This is crucial for preventing emails from going to spam at Microsoft.
Key considerations
ESP involvement: Given that the ESP typically handles DKIM signing, engaging with your Email Service Provider is often the first and most critical step. They have insights into their signing mechanisms and potential platform-specific issues.
Header and body inspection: Obtain the raw email source as sent by your ESP and as received by Outlook.com. Compare them meticulously for any discrepancies, especially focusing on encoding, line breaks, and non-ASCII characters. Pay close attention to the DKIM-Signature header's c= tag, ensuring it's relaxed/relaxed.
MIME and message structure: Investigate how the email's MIME encoding and overall message structure are handled. Microsoft may rewrite certain elements, causing the hash to fail. This could involve issues with multipart messages, quoted-printable encoding, or base64 encoding.
Content validation: Review email content for unusual characters, excessively long lines, or malformed HTML that might trigger Microsoft's content modification filters. More on this can be found in a guide about DKIM body hash did not verify errors.
Sender reputation: While fixing DKIM is paramount, address any underlying sender reputation issues that might also contribute to spam placement. This includes list hygiene and sending practices, as covered in our guide on diagnosing deliverability issues.
Email marketers often encounter the "DKIM body hash did not verify" error as a perplexing issue, especially when it is specific to certain mailbox providers like Outlook.com. Their perspectives tend to focus on troubleshooting steps, confirming common misconceptions (e.g., about subject lines breaking DKIM), and emphasizing collaboration with their Email Service Providers (ESPs) who handle the technical aspects of email sending and signing.
Key opinions
ESP responsibility: Many marketers believe that since the ESP applies the DKIM signature, they are best equipped to diagnose and resolve a body hash verification failure, particularly if the issue is isolated to a specific receiver like Microsoft.
Subject line myth: There's a common misconception among marketers that a "bad character" in the subject line could break DKIM, but experts often clarify that this is unlikely, as the subject line's impact on the body hash is typically minimal if canonicalization is relaxed.
Outlook.com specific: Marketers frequently note that issues like DKIM failures, or general email deliverability problems, can be uniquely persistent or pronounced with Microsoft's email services compared to others.
Encoding and structure: Some marketers suggest that the way an email's body (HTML content) or message structure is encoded might be causing Microsoft to alter it, leading to the hash mismatch.
Key considerations
Initial ESP contact: Marketers should prioritize reaching out to their ESP with the full email headers showing the DKIM failure, as the ESP controls the DKIM signing process.
Audience and network: If fixing the DKIM signature doesn't resolve spam placement, marketers should investigate their audience engagement and the reputation of their sending IP (network neighbors), a key component of Outlook deliverability troubleshooting.
Detailed information for ESP: When contacting the ESP, provide all available details, including the full authentication results header, raw email content, and specific examples of emails failing verification.
Monitor spam placement: Even after resolving DKIM issues, continuous monitoring of inbox placement, particularly for Outlook.com, is essential to ensure long-term deliverability. It's also important to understand why emails bounce back more generally.
Marketer view
A marketer from Email Geeks explains that the "DKIM body hash did not verify" error typically means something was modified during transit or there's an encoding problem. This is a common challenge that needs careful examination of the email's raw content.
28 Nov 2019 - Email Geeks
Marketer view
A marketer from Email Geeks indicates that the subject line itself is unlikely to be the cause of a DKIM signing breakage. They recall similar issues being related to the specific way DKIM records were being signed by their ESP.
28 Nov 2019 - Email Geeks
What the experts say
Email deliverability experts highlight that a "DKIM body hash did not verify" error primarily indicates that the email body or certain signed headers were modified in transit. This is often attributed to encoding issues, malformed messages, or unique processing by receiving mail servers, particularly Microsoft's. Experts advise a thorough comparison of the raw email as sent and received to pinpoint the exact point of modification.
Key opinions
Modification in transit: Experts agree that the error signals the email body was altered after signing. This is the core interpretation of "body hash did not verify."
Encoding issues: Encoding problems, especially with non-ASCII characters or malformed MIME structures, are frequently cited as the root cause of these in-transit modifications.
Microsoft's behavior: Microsoft's mail servers are notoriously particular and may rewrite email content or headers in ways that break DKIM signatures, even if other providers do not. This often makes DKIM failures specific to Outlook.com.
Separate issues: Experts recommend treating the DKIM failure and subsequent spam placement as two potentially distinct but related issues. Fixing the DKIM is step one, then addressing any remaining spam filtering.
Canonicalization's role: The DKIM canonicalization method is key. While 'relaxed/relaxed' should tolerate minor modifications, its presence doesn't automatically rule out all canonicalization issues if a server is particularly aggressive in its rewrites.
Key considerations
Raw email comparison: The most effective diagnostic step is to compare the raw email (including headers) as it leaves the sender's system and as it's received by the problematic mailbox provider (Outlook.com). This direct comparison helps identify what was changed.
Focus on MIME and structure: Beyond simple HTML, look at the MIME encoding and overall message structure for anomalies. This includes long lines or special characters within the payload that could trigger rewrites.
Mitigation strategies: Even if the issue is arguably a Microsoft 'bug,' senders can often mitigate it by adjusting their email composition or ESP settings. This could involve simplifying HTML or adjusting encoding. More on this can be found in our article how to fix DKIM body hash mismatch failures.
Consulting ESP: While self-diagnosis is good, the ESP has the most direct control and visibility into the signing process. Collaboration is essential.
Beyond DKIM: If DKIM is fixed and emails still land in spam, attention must shift to other deliverability factors like sender reputation, content quality, and recipient engagement, as highlighted by DKIM authentication guides.
Expert view
An expert from Email Geeks states that the DKIM signature breaking is likely due to an encoding issue with how the mail is sent and how Microsoft handles, or fails to handle, that encoding. This suggests a common problem with character representation.
28 Nov 2019 - Email Geeks
Expert view
An expert from Email Geeks suggests that if the DKIM signature is no longer breaking, but mail is still going to spam, the sender should investigate their audience and network neighbors. These factors are crucial for overall deliverability.
28 Nov 2019 - Email Geeks
What the documentation says
Technical documentation on DKIM outlines the specifications for signing and verifying email messages to ensure integrity and authenticity. The "body hash did not verify" error, as per RFC 6376 (DKIM Signatures), explicitly means the computed hash of the message body at the receiving end does not match the hash provided in the DKIM signature header. This is a clear indicator of post-signing alteration. Documentation also details canonicalization algorithms that dictate how strictly messages are processed for hashing.
Key findings
RFC 6376 definition: The DKIM specification (RFC 6376) defines the body hash (bh) as a cryptographic hash of the message body. A failure in verification means the body content has changed since the signature was applied.
Canonicalization methods: DKIM supports 'simple' and 'relaxed' canonicalization for both headers and the body. 'Simple' is highly sensitive to any change, including whitespace, while 'relaxed' is more tolerant, handling common transit modifications like line ending changes or redundant whitespace.
MIME implications: Changes to MIME structure, encoding, or transfer encoding (e.g., from 8bit to quoted-printable) by intermediate mail transfer agents (MTAs) can alter the body in a way that breaks a 'simple' canonicalization, or even a 'relaxed' one if the changes are significant.
Header inclusion: The 'h=' tag in the DKIM-Signature header specifies which headers are included in the signature hash. If any of these headers are modified in transit, it can also lead to a signature failure, even if the body itself remains untouched in a way that impacts its hash.
Key considerations
Verify canonicalization: Ensure your ESP is signing emails using 'relaxed/relaxed' canonicalization. This is generally recommended to minimize failures due to minor transit modifications. You can check your DMARC reports for common issues, as described in understanding and troubleshooting DMARC reports.
Adhere to RFC standards: Ensure email construction adheres strictly to RFCs (e.g., RFC 5322 for message format, RFC 2045 for MIME) to reduce the likelihood of modifications by compliant MTAs. Barracuda Campus documentation provides insights into sender authentication best practices.
Inspect content and headers: Review email content for any elements that might be prone to modification by email security gateways or Microsoft's internal processing, such as large images, non-standard HTML, or problematic character sets.
Review ESP's signing process: Understand which headers your ESP includes in the DKIM signature using the 'h=' tag. If unnecessary or volatile headers are included, they could cause verification failures. For more technical details, refer to decoding DKIM temperror.
Technical article
Documentation from Barracuda Campus indicates that a DKIM verification failure can lead to messages being blocked by default. It highlights the importance of successful DKIM authentication for email gateway defense mechanisms.
14 Apr 2023 - Barracuda Campus
Technical article
Documentation from Itechtics suggests that verifying email forwarders and gateway configurations is crucial when encountering DKIM body hash errors. Such intermediate systems can inadvertently modify email content.