DKIM « Body Hash Did Not Verify » — qu'est-ce qui a modifié votre message, et comment corriger (2026)

Publié 2026-07-08

Chiffres au 2026-06-29 · méthodologie v7. Données de recensement agrégées sur 261 millions de domaines évalués. Voir comment nous notons.

« Body hash did not verify » signifie que votre signature DKIM était valide au moment où le message vous a quitté — et que quelque chose a réécrit le corps du message ensuite. La signature n’est pas cassée ; le message a été modifié en transit. Seuls 3,87 % des domaines — 10 092 481 — complètent la triade SPF-DKIM-DMARC, selon le recensement Defaults.Exposed portant sur 261 086 232 domaines (2026-06-29).

Le correctif est une traque, puis une décision. Trouvez le saut qui modifie votre courrier — une passerelle qui ajoute un avertissement légal, un boîtier qui réécrit les liens, une liste de diffusion qui ajoute un pied de page. Puis signez après ce saut, supprimez la modification, ou rendez la signature tolérante à celle-ci — dans cet ordre.

Que signifie réellement « body hash did not verify » ?

Une signature DKIM (RFC 6376) porte deux hachages : bh=, un hachage du corps du message tel que signé, et b=, qui signe les en-têtes plus ce hachage du corps. Le vérificateur recalcule le hachage du corps à partir du message reçu ; s’il ne correspond pas à bh=, la vérification s’arrête avec la chaîne que tout le monde colle dans un moteur de recherche — un en-tête côté réception du type :

Authentication-Results: …; dkim=fail (body hash did not verify)

C’est la chaîne de diagnostic documentée par Microsoft ; Gmail rend souvent le même verdict sous la forme dkim=neutral (body hash did not verify). Dans les deux cas, le verdict resserre énormément le problème. Votre clé DNS, votre sélecteur et votre configuration de signature sont tous corrects. La cryptographie a fait son travail : le corps a changé entre la signature et la vérification — une ligne ajoutée, une URL réécrite, un caractère ré-encodé suffisent. (Un message différent — signature did not verify, no key for signature — signifie un échec différent ; commencez par « DKIM signature not valid ».) Et c’est urgent, car une signature en échec ne peut pas donner à DMARC un pass aligné : à moins que SPF ne passe avec alignement sur le même message, le courrier échoue à DMARC purement et simplement.

Qu’est-ce qui a modifié votre message ? Les suspects habituels

Quelque chose sur le chemin de livraison a édité le corps après que votre signataire l’a scellé. En pratique, c’est l’une de ces quatre choses :

Qui l’a modifié	Ce qu’il change	Signe typique
Passerelle sortante / smart host (règles de transport Exchange, Mimecast, Proofpoint, Barracuda…)	Ajoute l’avertissement légal, le pied de page marketing ou la bannière « EXTERNAL: » après que le serveur de messagerie a déjà signé	Tous les messages sur cette route échouent ; les envois directs contournant la passerelle passent
Boîtier de sécurité / protection des liens	Réécrit les URL vers des redirections d’analyse, ajoute des enveloppes de suivi	Seuls les messages contenant des liens échouent
Liste de diffusion (Google Groups, Mailman…)	Ajoute un tag de sujet et un pied de liste, reformate parfois le corps	Seul le courrier envoyé via la liste échoue
Transfert / relais ré-encodant le MIME	Transcode le jeu de caractères, recoupe les lignes — invisible pour un humain, fatal pour un hachage	Les échecs se concentrent sur un destinataire ou une adresse de transfert

Vérifiez d’abord la ligne en gras — le serveur de messagerie signe, l’équipement de bordure édite, et chaque message part avec une signature qui a été vraie pendant trente millisecondes.

Comment trouver le saut qui modifie mon courrier ?

Diagnostic différentiel — comparez un chemin qui fonctionne au chemin qui échoue :

Envoyez un message de test direct vers une boîte que vous contrôlez chez un grand serveur de réception (Gmail convient bien), en contournant autant que possible votre chaîne sortante.
Envoyez un second message le long du chemin en échec — via la passerelle, via la liste, vers le domaine du destinataire concerné.
Comparez les lignes Authentication-Results dans les deux en-têtes complets. Envoi direct dkim=pass, chemin en échec dkim=fail (ou dkim=neutral) avec body hash did not verify : le modificateur vit entre ces deux routes.
Regardez le corps reçu : un avertissement, une bannière ou un pied de page que vous n’avez pas tapés ? Des liens réécrits vers un domaine d’analyse ? Voilà votre saut, nommé — et la chaîne des Received: montre quel relais n’apparaît que sur le chemin en échec.

Vos rapports agrégés DMARC racontent la même histoire à grande échelle : une source qui rapporte systématiquement DKIM en échec avec SPF en pass est généralement une modification en transit sur votre propre route, pas un attaquant.

Comment corriger ?

Lancez le scan gratuit sur defaults.exposed avant de toucher à quoi que ce soit. Il confirme que vos clés DKIM publiées et votre politique DMARC sont saines, pour ne déboguer que le seul vrai problème — la modification — au lieu de chasser des fantômes dans le DNS. La page corriger DKIM couvre les vérifications côté enregistrements.
Signez après le saut modificateur. Le correctif architecturalement correct : déplacez la signature DKIM vers l’équipement le plus externe qui touche le message. Les configurations Exchange-plus-passerelle devraient signer à la passerelle (Mimecast, Proofpoint et consorts le permettent tous) et désactiver la signature en amont. Si Google Workspace ou Microsoft 365 est votre dernier saut, signez là et ne laissez rien éditer le courrier après — voir configurer DKIM sur Google Workspace ou Microsoft 365.
Ou supprimez la modification. Sortez l’édition du chemin de transport : l’avertissement légal dans la signature du client de messagerie ou dans le modèle plutôt que dans une règle de transport ; la bannière « EXTERNAL: » limitée au courrier entrant uniquement (marquer votre propre courrier sortant comme externe est une double erreur de configuration) ; le courrier sortant authentifié exempté de la réécriture de liens.
Utilisez la canonicalisation relaxed/relaxed (c=relaxed/relaxed). La canonicalisation de corps simple échoue sur une seule ligne recoupée ; relaxed tolère les changements d’espaces et de fins de ligne. Soyons honnêtes sur la limite : relaxed pardonne le formatage, jamais le contenu — un pied de page ajouté échoue toujours, et c’est normal.
Retestez les deux chemins, puis relancez le scan. Les deux routes doivent désormais montrer dkim=pass avec votre domaine dans d=, et le rapport de scan doit être propre.

Dois-je utiliser le tag l= pour que DKIM ignore le contenu ajouté ?

Non — et méfiez-vous de tout guide qui le suggère. Le tag l= ne hache que les N premiers octets du corps, si bien qu’un pied de page ajouté ne casse plus la signature. Ça « marche » en laissant la fin de votre message non signée : quiconque détient un message légitimement signé peut y ajouter du contenu arbitraire, et votre signature valide se vérifie toujours sur le résultat. C’est un trou d’usurpation déguisé en correctif — l’abus a été démontré en pratique, et certains serveurs de réception pénalisent ou ignorent l= pour exactement cette raison. Résolvez la modification ; ne dé-signez pas une partie de votre courrier.

Et les listes de diffusion — puis-je les corriger ?

Le plus souvent, non — et le savoir vous épargne des semaines. Une liste qui ajoute un tag de sujet ou un pied de page casse votre hachage de corps par conception, et vous ne contrôlez pas la liste. Deux choses aident :

Ce résidu est exactement la raison pour laquelle le déploiement DMARC se fait par étapes. Passer de p=none à p=quarantine avec une montée en pct=, tout en lisant les rapports agrégés, signifie que les messages abîmés par les listes sont mis en quarantaine plutôt que détruits pendant que vous évaluez l’impact — le sujet de de p=none à p=reject sans perdre d’e-mail légitime.
ARC est le mécanisme du serveur de réception, pas le vôtre. Authenticated Received Chain permet à la liste d’attester de l’état de l’authentification à l’arrivée et au serveur de réception de décider s’il lui fait confiance. Il n’y a rien à configurer pour vous, l’expéditeur. Les listes bien gérées atténuent le problème en réécrivant l’en-tête From ; les mal gérées cassent simplement votre courrier.

Le transfert est le cas voisin — il casse SPF de façon fiable mais DKIM seulement parfois, et c’est pourquoi un DKIM aligné est votre pilier résistant au transfert quand le corps survit : voir l’e-mail transféré échoue à SPF — pourquoi vous ne pouvez pas le corriger.

Pourquoi DKIM casse-t-il si souvent alors que si peu de domaines ont même la pile complète ?

Parce que DKIM est l’enfant fragile du milieu de la triade : SPF est un enregistrement DNS statique, DMARC une déclaration de politique, mais DKIM doit survivre au voyage. Seuls 51,84 % des domaines évalués publient une clé DKIM découvrable dans le DNS, selon le recensement Defaults.Exposed, et seuls 10 092 481 domaines — 3,87 % des 261 086 232 évalués — détiennent SPF, DKIM et une politique DMARC contraignante ensemble (le modèle de maturité de l’adoption SPF décompose l’échelle). Réussir ce correctif est la partie la plus dure pour rejoindre ces 3,87 %.

Questions fréquentes

« Body hash did not verify » est-il le signe que quelqu’un usurpe mon domaine ? Généralement non — un usurpateur ne peut typiquement pas produire votre signature DKIM du tout, donc son courrier ne montre aucune signature ou no key. Un hachage de corps en échec signifie qu’un message authentiquement signé par votre infrastructure a été édité ensuite. Vérifiez votre propre passerelle avant de supposer un attaquant.

SPF passe sur ces messages — suis-je quand même tranquille ? Pour l’instant, peut-être : DMARC n’a besoin que d’un seul pass aligné. Mais le pass de SPF s’évapore dès que quelqu’un transfère le message, et s’il n’est pas aligné avec votre domaine From, il n’a de toute façon jamais compté pour DMARC. Avec seulement 3,87 % des domaines détenant la triade complète (recensement au 2026-06-29 sur 261 086 232 domaines), « un pilier qui boite » est l’état normal — et celui qui se corrige.

Passer à la canonicalisation relaxed/relaxed corrigera-t-il mon problème d’avertissement légal ? Non. Relaxed ne tolère que les changements d’espaces et de coupures de ligne. Un avertissement ajouté est un changement de contenu, et le hachage doit échouer dessus — c’est DKIM qui fonctionne correctement. Déplacez le point de signature ou déplacez l’avertissement.

L’échec ne se produit que vers le domaine d’un seul client. Pourquoi ? Son côté modifie presque certainement le courrier entrant — un boîtier de sécurité qui réécrit les liens ou appose des bannières avant que son vérificateur ne s’exécute, ou un transfert interne qui ré-encode le corps. Envoyez-lui la section diagnostic de cette page ; le correctif est sur sa passerelle, pas dans votre DNS.

Envoyez le rapport au propriétaire

Si vous corrigez cela pour un client ou votre employeur, bouclez la boucle avec une preuve. Une fois le saut modificateur corrigé, relancez le scan gratuit et transmettez le rapport noté au chef d’entreprise : daté, en langage clair, l’état de DKIM et DMARC sur une seule page. C’est la pièce dont il aura besoin au renouvellement de la cyberassurance et au prochain questionnaire fournisseur — la preuve que le courrier qui quitte l’entreprise est désormais le courrier qui arrive.

Vérifiez votre domaine → · Guide « DKIM signature not valid » → · Corriger DKIM → · Comment nous notons → · Données agrégées uniquement. Données stockées et traitées dans l’UE.