Confirm that the body hash failed

Start with a trusted verifier result and the relevant DKIM-Signature. Record d=, s=, a=, c=, bh=, and l= if present. Do not label every dkim=fail as a body-hash failure; a missing key, malformed signature, or signed-header change can also fail verification.

Preserve the raw message exactly as received. Copying it through a word processor, normalizing line endings, or forwarding it as inline text can create a different body and destroy the evidence. Store it only in an approved restricted location and remove unnecessary personal content from the incident record.

Understand what can change

DKIM hashes a canonicalized body. simple body canonicalization tolerates only the changes described by RFC 6376, while relaxed normalizes specified whitespace patterns. Neither permits arbitrary additions. Gateways, mailing lists, footers, security products, line wrapping, character-set conversion, and broken transport can modify bytes after signing.

The optional l= tag signs only a declared initial body length and has security tradeoffs; its presence should be recorded rather than used as a general repair.

Locate the transforming hop

Build a path with copies captured at controlled boundaries: after the application renders, after the sender signs, after an outbound gateway, and at the recipient. Compute verification using an approved local tool at each available point. Do not compare visual rendering alone; invisible whitespace and MIME transfer encodings matter.

Change one component at a time. If disabling a footer insertion in a staging route makes the signature verify, repeat the test to establish causality. If the application modifies the message after the provider signs it, move the signing step to the final outbound representation or stop the later mutation.

Verify the remedy

Send a new representative message through the complete normal route. Confirm that the intended d= domain verifies at the trusted receiver and that the message still renders and functions correctly. Test multipart and non-ASCII examples if those are normal traffic.

Do not weaken authentication merely to accommodate an unexplained mutation. The useful incident conclusion names the transforming boundary, the affected message types, and the verified fix. If the pre-signing copy is unavailable, keep the cause as unconfirmed rather than inventing one from the final HTML.