Microsoft: Body hash did not verify error

If you're seeing intermittent DKIM authentication failures at Microsoft domains (,, etc.) -- meaning you're seeing "dkim=fail (body hash did not verify)" instead of "dkim=pass (signature was verified)" in your "Authentication Results" email headers -- then what likely has happened is that Microsoft has modified one or more characters in your email message.

See, there's multiple ways to encode email messages for sending them via the Internet -- the oldest, default way of just plain text (7-bit ASCII text) doesn't allow for emojis, accented characters, special character sets, Kanji, anything beyond just the simple characters used to write English-language text. And to allow email to be transmitted in this simplistic character set, but allow for additional, extended characters and alternative character sets, methods of encoding were created that allowed email platforms to do things like specify complicated multi-byte characters by "encoding" them into Quoted-Printable or Base64, to allow them to be transmitted via 7-bit ASCII while still preserving special characters.

Encoding is complex, and decoding that data is complex. It's possible for some platforms to get it wrong at the send preparation step, and it's possible for mailbox providers to get it wrong at the inbound decoding and mailbox delivery step.

DKIM email authentication applies a cryptographic signature essentially attempting to assert that a message's body (and some other bits) were not changed in transit; that they truly represent what was intended to be sent. But if a sending platform misconfigures encoding a bit, and/or a receiving platform attempts to correct an encoding issue ... you've effectively changed the message body, and that's going to give you a "body hash did not verify" DKIM failure.

It's one of those things that highlights the complexity of email systems, layering special character support on top of systems designed long ago, and then layering email authentication on top of that.

Back to Microsoft -- essentially, what's happening here, is that Microsoft changed the encoding of one or more characters upon receipt of the email message and before checking the DKIM authentication signature. Most folks would call this a bug. The truth could be a bit more complex than that, but what it boils down to is you've got a message that fails DKIM only at Microsoft, and probably not at other domains. Send the same message to a Gmail mailbox, and check the headers. DKIM will pass just fine.

So what to do? Test the content, in little pieces, sending each piece as its own email to your test mailbox, and look for DKIM failures. You might be able to find that it's a certain emoji or HTML entity or something like that. In one case, years ago, I found that it was tabs being converted into spaces. And according to this discussion board thread, it can happen when improperly encoding 8-bit characters using certain email sending tools.

This has been going on for years (I've written about it before and so has Steve Atkins), and it's not a fun thing to have to troubleshoot. But know that you're not alone and that it is possible to break down and test the content (and potentially the content encoding) and get it fixed. So go forth and fix it! And good luck.



  1. if you are under Adobe campaign, just force UTF8 encoding (it is not the default one) in the delivery (if your html content is utf8 and the same for the subject line).
    This will solve the DKIM issue + the issue of clipped messages in Gmail even when the html code size is under 102K


Comments policy: Al is always right. Kidding, mostly. Be polite, please and thank you.