DKIM fail : body hash did not verify, et comment corriger
ChatGPT
Claude
Gemini
Perplexity
GrokL’essentiel
Cette erreur signifie que le corps du message a changé après la signature. Voici cinq causes de modification en transit, et comment trouver la vôtre.
DKIM fail body hash did not verify signifie que le destinataire a calculé pour le corps canonisé un hachage différent de la valeur bh= de la signature DKIM. Partez du message brut en échec, identifiez où la signature DKIM a eu lieu, puis comparez avec le chemin suivant. Réparez la modification confirmée du corps, ou signez après elle, et renvoyez par la même route de production.
En bref
Points clés
bh=contient le hachage du corps canonisé, etb=les données de signature DKIM.dkim=fail (body hash did not verify)signale un écart de hachage du corps pour une signature, pas le système fautif.- Une clé publique DKIM valide ne répare pas un corps modifié après signature.
- Pieds de page, réécritures MIME, changements d’encodage, listes de diffusion : causes possibles tant que le message brut n’en confirme pas une.
- Le champ
Authentication-Resultsajouté par le destinataire et l’en-têteDKIM-Signaturecorrespondant sont les meilleures preuves de départ. - Validez la correction avec un nouveau message par la même application, la même route et le même format.
Que signifie l’échec ?
La RFC 6376 définit bh= comme le hachage du corps canonisé et impose au vérificateur de comparer son propre calcul à cette balise. Si les valeurs diffèrent, la signature DKIM échoue. Une discussion de support Microsoft Learn documente le résultat exact dkim=fail (body hash did not verify). Ce fil illustre le symptôme chez ce fournisseur, sans expliquer chaque message en échec.
Authentication-Results: mx.receiver.example;
dkim=fail (body hash did not verify) header.d=example.com header.s=selector1;
spf=pass smtp.mailfrom=example.com
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=example.com; s=selector1;
h=from:to:subject:date;
bh=BASE64_BODY_HASH_EXAMPLE=;
b=BASE64_SIGNATURE_EXAMPLE=
Exemple illustratif et expurgé. Ne publiez pas d’en-têtes réels, de sélecteurs générés par un compte, de clés privées, de jetons ni de contenu client.
Les balises bh= et b= ont des rôles distincts. bh= est calculé sur le corps canonisé. b= porte la signature des en-têtes choisis. Un écart de hachage signifie que le vérificateur n’a pas reçu le corps canonisé haché par le signataire. C’est distinct d’un problème d’alignement DMARC, où le domaine d= d’une signature DKIM valide n’est pas aligné avec le domaine From visible.
Pour les protocoles associés, voir la rubrique authentification des e-mails.
Causes habituelles
Contenu modifié après signature
Un changement du corps après signature peut causer cet échec, car DKIM hache le corps canonisé. Un avertissement légal, un pied de page, un suivi, un lien réécrit ou une transformation de modèle compte s’il intervient après le signataire. Les règles de canonisation et de hachage de la RFC 6376 expliquent le mécanisme.
Conclure qu’un relais précis a modifié un message donné reste une déduction. Confirmez-la en comparant les messages bruts avant et après ce relais. Les champs Received aident à tracer la route, sans prouver une modification du corps.
Un intermédiaire a réécrit MIME ou encodage
Une passerelle, une liste de diffusion, un service de transfert ou d’analyse de contenu peut modifier les limites MIME, l’encodage de transfert, les fins de ligne ou le contenu. Ces changements peuvent toucher les octets hachés même si l’e-mail affiché semble identique.
La discussion de support Microsoft relie l’échec à un avertissement ajouté après signature. Voyez-y un scénario documenté, pas un diagnostic universel.
Le signataire a haché autre chose que ce qu’il a transmis
La RFC 6376 définit les algorithmes de canonisation simple et relaxed et inscrit celui choisi dans c=. Si le système hache un message sérialisé mais en envoie un autre, le destinataire obtient un autre résultat.
Cette cause est plus probable si des captures contrôlées montrent qu’aucun service ultérieur n’a touché le message. Vérifiez le code de signature, la génération MIME, les fins de ligne et les octets exacts remis au signataire.
La signature limite la longueur du corps
La balise facultative l= indique combien d’octets du corps canonisé entrent dans le hachage. La RFC 6376 avertit des risques de sécurité d’une longueur limitée. N’ajoutez pas l= pour tolérer un pied de page ou une autre réécriture. Retirez la réécriture confirmée ou placez-la avant la signature.
La preuve vient d’un autre chemin
Une copie transférée, renvoyée ou modifiée par une liste peut différer du message de production en échec. Utilisez la source brute complète qui contient le résultat exact. L’affichage d’un client peut masquer espaces, contenu encodé et structure MIME qui influent sur DKIM.
Comment diagnostiquer l’échec ?
1. Conservez les preuves du destinataire
Gardez la source brute du message en échec. La RFC 8601 définit Authentication-Results comme un champ de service d’authentification dans une frontière de confiance : privilégiez le résultat ajouté par le destinataire à un ancien en-tête recopié.
Notez le Message-ID, l’heure de livraison, l’application d’envoi, la route sortante, d=, s=, c=, bh= et toute balise l=. Gardez le résultat exact dkim=fail (body hash did not verify) dans le dossier d’incident.
Expurgez destinataires, contenu, jetons et données clients avant de partager hors de l’équipe.
2. Situez la signature et chaque relais suivant
Identifiez le système qui a ajouté la DKIM-Signature concernée. Listez ensuite chaque service qui a traité le message après lui.
application -> outbound MTA -> disclaimer gateway -> recipient
signs? changes body? verifies?Lisez les champs Received de bas en haut, puis vérifiez la route avec les journaux et la configuration. Un échec propre à une route peut indiquer une modification ultérieure, mais la comparaison contrôlée des messages bruts confirme la cause.
3. Tests contrôlés par le même chemin
Envoyez un nouveau message minimal par le chemin de production normal et gardez la source brute reçue. Si c’est approuvé, envoyez le même contenu par une route qui contourne un modificateur suspect.
Comparez les sources brutes, pas des captures d’écran. Ajoutez une variable de production à la fois : modèles HTML, avertissements, liens réécrits, pièces jointes, encodage habituel. Un message texte qui réussit ne prouve pas que le modèle de production réussit.
4. Vérifiez le sélecteur publié à part
Utilisez le test DKIM de Palisade avec le domaine d= et le sélecteur s= de la signature en échec. Il vérifie si un enregistrement DKIM public existe pour ce sélecteur.
Un enregistrement de sélecteur absent ou erroné est un autre problème de DNS ou de clé. Il ne prouve pas que l’écart de hachage a disparu. Une requête DKIM publique ne peut inspecter le corps livré, la clé privée, l’implémentation de signature, les modifications intermédiaires, le filtrage privé d’un destinataire ni les livraisons futures.
Comment corriger ?
Signez après la dernière modification requise
Si une passerelle requise ajoute un avertissement, transforme les liens ou modifie le corps de façon confirmée, placez la signature DKIM après cette dernière modification. La nouvelle valeur bh= couvre alors le corps transmis.
N’assouplissez pas la politique DMARC pour contourner le problème. Changer p= change l’application DMARC demandée. Cela ne change pas le corps et ne répare pas DKIM.
Vérifiez que chaque route sortante prévue atteint le signataire final. Déplacer la signature vers une passerelle peut laisser sans signature une autre application qui la contourne.
Retirez la réécriture post-signature avérée
Si la modification du corps est inutile, désactivez uniquement la transformation post-signature confirmée. Retestez avec le modèle de production, pas seulement un message texte.
Gardez l’ancienne configuration pour un plan de repli. Si retirer la transformation touche un avertissement légal, un contrôle de sécurité ou un modèle client, associez-en le responsable avant le changement.
Corrigez l’implémentation de signature
Si le signataire crée l’écart avant tout système en aval, vérifiez sa canonisation, sa génération MIME, ses fins de ligne, son encodage de transfert et sa gestion de longueur au regard des exigences de signature et de vérification de la RFC 6376.
Changez un composant à la fois. Remplacer ou reconfigurer un signataire exige un plan de repli, surtout si plusieurs applications sortantes en dépendent.
Traitez à part la politique DMARC
Changer p= touche l’application DMARC demandée par le propriétaire du domaine. Cela ne répare pas l’écart du corps et ne fait pas réussir la signature DKIM. Concentrez la correction sur le signataire ou la transformation post-signature confirmée.
Comment valider la correction ?
Reprenez la route qui a produit l’échec. Utilisez la même application, la même passerelle sortante, le même fournisseur destinataire et le même format. Testez le modèle de production, avec pied de page, pièce jointe, réécriture de liens et encodage présents sur le message en échec.
Quatre vérifications :
- DNS : confirmez que l’enregistrement du sélecteur se résout via le DNS faisant autorité et au moins un résolveur public.
- Fournisseur : confirmez que l’expéditeur ou la passerelle indique l’état DKIM attendu, si ce statut existe.
- Message : inspectez la nouvelle source brute et confirmez que le résultat fiable du destinataire indique
dkim=passpour la signature voulue. - DMARC : une fois les rapports accumulés, examinez les données agrégées de cette source et confirmez que la signature réussie peut s’aligner avec le domaine From visible si DMARC dépend de DKIM.
Vérifiez le sélecteur DKIM après le nouveau test
Après la réparation du corps, vérifiez le sélecteur DKIM publié utilisé par la signature en échec. Cela écarte un problème distinct de clé publique ou de DNS pendant que vous comparez le nouveau message.
Une requête DKIM ne peut identifier le système qui a modifié ce corps, inspecter la clé privée, surveiller chaque route d’envoi ni garantir le comportement futur des destinataires. Si le chemin compte plusieurs expéditeurs ou si une dérive DNS vous inquiète, Palisade est un logiciel DMARC agentique qui analyse les rapports agrégés DMARC, identifie les problèmes d’authentification et d’alignement et crée des tickets de correction priorisés pour examen humain. En savoir plus sur la surveillance et les rapports DMARC.
Preuve
Sources et pour aller plus loin
Questions des lecteurs
Questions fréquentes
La propagation DNS peut-elle causer cet échec ?
Non. Une clé publique DKIM absente ou périmée cause un problème de récupération de clé ou de vérification de signature. body hash did not verify décrit un écart entre le corps canonisé reçu et la valeur bh=.
Passer DMARC à p=none répare-t-il DKIM ?
Non. Changer p= change l’application DMARC demandée. Cela ne change ni le corps, ni la signature DKIM, ni le résultat de vérification du hachage.
Un pied de page de liste casse DKIM ?
Oui. Le pied de page d’une liste de diffusion peut casser DKIM s’il modifie du contenu couvert par la signature. Confirmez-le en comparant le message brut avant et après la liste.
Faut-il d’abord régénérer la clé DKIM ?
Non. Régénérer une clé ne répare pas une modification confirmée du corps. Ne remplacez une clé que si d’autres preuves montrent qu’il le faut.
Une requête DKIM réussie prouve-t-elle la correction ?
Non. Une requête DKIM peut confirmer qu’une clé publique est publiée pour un sélecteur. Elle ne prouve pas que l’expéditeur de production a utilisé ce sélecteur ni que le corps livré est resté intact après signature.
Vérifiez la clé publique DKIM du sélecteur
Entrez le domaine et le sélecteur.
Rédigé par
Samuel ChenardCEO et cofondateur, Palisade
Samuel Chenard est CEO et cofondateur de Palisade, logiciel DMARC agentique pour équipes IT et MSP, d’un domaine à des milliers.
Lire Samuel →