Comment résoudre les erreurs « Signature DKIM non valide » et « Hachage du corps du message non vérifié »

Si vous avez reçu le message d'erreur « La signature DKIM n'est pas valide », cela signifie qu'il y a un problème au niveau de votre configuration DKIM qui doit être résolu. Ces erreurs sont généralement dues à une entrée incorrecte dans l'enregistrement DNS DKIM, à des retards dans la propagation DNS, à des erreurs lors de l'évaluation de la signature DKIM ou à des modifications apportées au message après sa signature. 

Ce guide passe en revue chaque cause et sa solution, avec une section dédiée à l'erreur étroitement liée « Hash du corps de la signature DKIM non vérifié », qui renvoie à un problème spécifique et très facile à résoudre.

À propos des signatures DKIM

Le protocole DKIM ajoute une signature cryptographique aux en-têtes de vos e-mails, et le serveur destinataire vérifie cette signature par rapport à une clé publique publiée dans votre DNS. Si les deux ne correspondent pas, vous obtenez l'erreur « La signature DKIM n'est pas valide ». Pour une explication détaillée du fonctionnement de ce protocole, consultez notre guide sur ce qu’est DKIM.

Étant donné que la plupart des personnes confrontées à cette erreur ont déjà configuré DKIM et ont simplement besoin de corriger ce qui ne fonctionne plus, le reste de cette page se concentre sur le diagnostic et les solutions plutôt que sur les principes de base.

Dans quels cas le DKIM peut-il échouer avec le message d'erreur « Votre signature DKIM n'est pas valide » ?

Le message « Votre signature DKIM n'est pas valide » s'affiche lorsque la vérification de l'authentification DKIM échoue. Voici les causes les plus courantes :

• Le domaine de la signature DKIM et le domaine de l'expéditeur ne correspondent pas.
• L'enregistrement de la clé publique DKIM publié dans le DNS n'est pas correct.
• L'enregistrement de la clé publique DKIM n'est pas du tout publié dans le DNS.
• Le serveur ne parvient pas à accéder à la zone DNS du domaine de l'expéditeur pour effectuer la recherche, une situation courante chez les hébergeurs peu fiables.
• La longueur de la clé DKIM est insuffisante. Les fournisseurs modernes exigent des clés de 2 048 bits ; les anciennes clés de 1 024 bits sont de moins en moins considérées comme fiables, tandis que les clés très courtes sont purement et simplement rejetées.
• Le message a été modifié lors du transfert automatique.

Tous ces problèmes, à l’exception du dernier, sont des problèmes techniques que vous pouvez résoudre directement. Le cas du transfert est différent, car vous ne pouvez pas contrôler si le serveur du destinataire ajoute un pied de page de conformité ou modifie le message d’une autre manière. Que se passe-t-il donc lorsque ces messages transférés automatiquement échouent à la fois aux vérifications SPF DKIM, et que votre politique DMARC est configurée pour rejeter les messages ?

Cela constituait autrefois un véritable problème pour les serveurs de réception chargés de traiter des e-mails transférés légitimes mais non authentifiés. La solution provisoire actuelle est la protocole ARC (ARC), qui permet à chaque serveur de messagerie de la chaîne d’enregistrer les résultats d’authentification qu’il a constatés, de sorte que le destinataire final puisse toujours reconnaître que le message a été authentifié avant que le transfert ne le modifie. L’ARC a toutefois toujours été une solution expérimentale, et le secteur est désormais en train de s’en détourner. Un autre projet de l’IETF datant d’avril 2026 a proposé de reclasser l’ARC en norme historique, car ses enseignements sont intégrés dans DKIM2, une nouvelle version de DKIM en cours de développement à l’IETF (draft-ietf-dkim-dkim2-spec) qui corrige le problème du transfert au sein même du protocole de base plutôt que d’y ajouter un deuxième mécanisme par-dessus. Au lieu de demander aux destinataires de se fier au compte rendu d’un intermédiaire sur ce qu’il a observé, DKIM2 impose à chaque maillon de la chaîne d’enregistrer précisément les modifications qu’il a apportées sous la forme d’une recette réversible, afin que le vérificateur puisse annuler ces modifications et revérifier la signature de l’expéditeur d’origine. Ce processus est encore en cours de normalisation ; ARC reste donc la solution pratique à l’heure actuelle, mais il est bon de savoir qu’une véritable solution au problème du transfert est en passe d’être mise en place.

Comment résoudre l'erreur « La signature DKIM n'est pas valide »

Même si des enregistrements DKIM sont en place, il peut arriver que vous rencontriez une erreur de signature non valide. Voici les solutions, classées en fonction de chacune des causes énumérées ci-dessus.

Solution 1 : Résolution des problèmes liés à des entrées DNS DKIM incorrectes

Une fois que vous avez créé l'enregistrement TXT DKIM et que vous l'avez ajouté à votre configuration DNS, une erreur de signature non valide est souvent due à une erreur dans cet enregistrement. Pour la repérer :

• Utilisez la fonctionnalité de PowerDMARC fonctionnalité de recherche DKIM de PowerDMARC pour vérifier votre enregistrement.

• Saisissez votre nom de domaine et votre sélecteur, ou laissez le champ du sélecteur vide pour que la plateforme le détecte automatiquement, puis cliquez sur « Vérifier ».

• Cet outil analyse votre enregistrement DNS DKIM et signale les éventuelles erreurs de syntaxe dans votre enregistrement.

Pour corriger l'enregistrement, connectez-vous à cPanel ou à la console de gestion DNS que vous utilisez, ouvrez l'« Éditeur avancé de zone DNS » dans la section « Domaines », sélectionnez votre domaine, accédez à « Modifier les enregistrements DNS », corrigez la valeur de l'enregistrement DKIM, puis enregistrez.

Solution n° 2 : attendre la fin des délais de propagation DNS

Il se peut également que vous constatiez des erreurs immédiatement après avoir modifié vos paramètres DNS. C'est tout à fait normal : la propagation DNS peut prendre entre 24 et 48 heures, et la durée exacte dépend de la valeur TTL définie dans l'enregistrement. Patientez quelques jours pour que la propagation soit complète et, en attendant, suivez l'état de la propagation à l'aide de notre outil de vérification de la propagation DNS.

Solution n° 3 : Réalignez le domaine de signature DKIM avec votre domaine d'envoi

Ouvrez l'en-tête « DKIM-Signature » d'un message rejeté et vérifiez la valeur de valeur « d= » par rapport à votre adresse « De » visible. Si elles ne correspondent pas, cela signifie que votre service d’envoi signe avec son propre domaine plutôt qu’avec le vôtre, ce qui rompt l’alignement et entraîne l’échec de la vérification. Pour y remédier, il suffit de configurer ce service pour qu’il signe avec votre domaine. La plupart des plateformes de messagerie disposent d’un paramètre « DKIM personnalisé » ou « authentifier votre domaine » prévu exactement à cet effet, et notre guide sur la configuration de DKIM explique la procédure à suivre.

Solution n° 4 : régénérer une clé trop courte

Si votre fournisseur utilise encore une clé de 1 024 bits (ou moins) pour la signature, régénérez-la à 2 048 bits, ce qui correspond à la norme actuelle exigée par Google et d’autres grands fournisseurs. Vous pouvez générer une nouvelle paire de clés dans la console d’administration de votre ESP ou à l’aide de notre générateur DKIM, publier la nouvelle clé publique dans votre DNS, puis vérifier qu’elle se résout correctement à l’aide de notre outil de recherche d’enregistrements DKIM.

Solution n° 5 : résoudre le problème d'un serveur DNS inaccessible

Si le serveur destinataire ne parvient pas à accéder à votre DNS pour rechercher la clé publique, la validation DKIM échouera, quelle que soit la qualité de la configuration des autres éléments. Vérifiez si votre enregistrement est accessible à l'aide d'un outil de vérification de la propagation DNS. Si le DNS de votre hébergeur est lent ou peu fiable, envisagez de transférer l'hébergement DNS vers un fournisseur dédié tel que Cloudflare ou Amazon Route 53.

Solution n° 6 : gestion des messages modifiés lors du transfert automatique

Les modifications apportées lors du transfert compromettent la validité du DKIM, et il n’existe pas toujours de solution du côté de l’expéditeur. Si vous contrôlez le serveur de transfert, activez la signature ARC (et, dans Microsoft 365, ajoutez les serveurs de transfert fiables à votre liste « Trusted ARC Sealers » dans Defender) afin que les e-mails transférés légitimes ne soient pas rejetés. Si vous ne le contrôlez pas, il s’agit d’un comportement normal et non d’une erreur de configuration : vos rapports agrégés DMARC indiqueront ces échecs, et la bonne approche consiste à en tenir compte dans votre politique et à poursuivre la surveillance plutôt que de courir après tout le monde.

Note: ARC is a temporary fix and not a permanent solution. DKIM2 is being designed to fix forwarding at the protocol level, so this whole category of failure should shrink as it rolls out. Keep any existing ARC setup running to support legacy gateways in the meantime, but there's little reason to invest heavily in new ARC engineering now.

Pourquoi le message "DKIM-Signature Body Hash Not Verified" apparaît-il ?

L'erreur « DKIM-signature body hash not verified » signifie que le hachage du corps du message calculé par le serveur destinataire ne correspond pas à la valeur stockée dans la balise « bh= » de l'en-tête DKIM-Signature. En termes simples, le corps de l'e-mail vérifié par le destinataire n'est pas identique à celui que votre serveur a signé. Le message a subi une modification en cours de route.

Il est important de bien comprendre ce point, car c'est un problème malheureusement courant qui signifie généralement que votre configuration DKIM est par ailleurs correcte. La vérification du hachage du corps du message a lieu avant la vérification complète de la signature ; ainsi, lorsque le hachage du corps échoue, l'évaluation DKIM échoue dans son ensemble, et le destinataire ne passe même pas à la vérification de la signature cryptographique proprement dite.

Causes courantes des pannes du Body Hash

• Une passerelle de messagerie ou un filtre a ajouté du contenu après la signature DKIM : Les mentions légales, les pieds de page juridiques, les pixels de suivi, les blocs de désabonnement, les bannières antivirus et les pieds de page marketing insérés par une passerelle sortante après la signature du message modifient tous le corps du message et altèrent le hachage. Il s'agit de la cause la plus fréquente.
• Une liste de diffusion ou un serveur de transfert a modifié le corps du message : Les logiciels de liste de diffusion ajoutent systématiquement des pieds de page de désabonnement ou réécrivent l'objet, et les serveurs de transfert peuvent supprimer ou ajouter des en-têtes. Ces deux opérations modifient le contenu signé.
• Une incompatibilité entre le codage des caractères et le format des fins de ligne : Si le message est signé en utilisant un encodage (par exemple, UTF-8 avec un marqueur d'ordre des octets) et que le serveur destinataire l'interprète différemment, ou si les fins de ligne passent de CRLF à LF à un moment donné pendant le transfert, le contenu au niveau des octets ne correspond plus, et le calcul du hachage échoue.
• La signature DKIM est effectuée trop tôt dans le flux de messagerie sortant : C'est la cause principale de la plupart des problèmes mentionnés ci-dessus. Si votre système signe le message avant qu'un composant en aval ne le modifie, le hachage du corps du message échouera à chaque fois.
• Une clé privée incorrecte ou pivotée : Si la clé de signature ne correspond plus à la clé publique publiée dans le DNS, la vérification échoue.

Comment diagnostiquer une défaillance du système de hachage de données

Suivez ces étapes pour identifier l'endroit précis où la modification a lieu :

1. Envoyez le même message de test à Gmail, Outlook ou Hotmail, ainsi qu'à une boîte mail interne. Veillez à ce que le contenu, les liens et l'acheminement soient identiques pour les trois destinataires.
2. Vérifiez l'en-tête « Authentication-Results » au niveau de chaque destinataire. Si le hachage du corps du message échoue sur les trois, le problème provient de votre côté (côté expéditeur). S'il échoue uniquement sur l'un d'entre eux (Outlook en est généralement la cause), le problème est plus probablement lié à la structure MIME ou à l'encodage des caractères qu'à votre configuration de signature.
3. Vérifiez l'ordre de traitement de vos e-mails et assurez-vous que la signature DKIM est effectuée avant ou après toute modification du contenu sortant.
4. Vérifiez l'enregistrement DNS DKIM afin de vous assurer que le sélecteur et la clé publique correspondent bien à ceux figurant dans la signature rejetée, à l'aide de notre outil de recherche d'enregistrements DKIM.
5. Envoyez un message test en texte brut, sans suivi, sans pied de page ni pièces jointes. Si ce message parvient à passer là où votre courrier habituel échoue, vous aurez identifié la modification par élimination.

Comment résoudre les erreurs liées au hachage du corps

• Signez le message en dernier, après chaque modification du contenu : C'est la solution la plus courante et la plus efficace. Modifiez l'ordre des étapes : passez de « rédiger, signer avec DKIM, ajouter la clause de non-responsabilité, envoyer » à « rédiger, ajouter la clause de non-responsabilité, signer avec DKIM, envoyer », afin de signer exactement le message que le destinataire recevra.
• Configurez les passerelles sortantes pour qu'elles ne modifient pas le corps du message : Ou configurez-les pour qu'elles signent à nouveau avec DKIM une fois les modifications effectuées.
• Normalisez votre encodage en UTF-8 sans marque d'ordre des octets et veillez à ce que les fins de ligne CRLF restent constantes tout au long du parcours d'envoi. Ceci est particulièrement important pour les environnements Exchange et Microsoft 365.
• Utiliser la canonicalisation assouplie (c=relaxed/relaxed) : Cette option tolère les espaces et les différences de mise en forme mineures qui, autrement, invalideraient une signature en cas de canonicalisation « simple » stricte. Elle ne permettra pas de sauver une signature lorsqu’une clause de non-responsabilité ou un pied de page complet est ajouté, mais elle élimine les échecs causés par des modifications de mise en forme mineures.

Échecs liés au hachage du corps du message spécifiques à Outlook et Microsoft 365

Un problème récurrent, qui envahit d'ailleurs les forums d'assistance de Microsoft, concerne les e-mails qui passent le contrôle DKIM sur Gmail et Yahoo, mais échouent sur Outlook ou Hotmail. Ce problème survient généralement avec les e-mails contenant des pièces jointes ou des images intégrées, et il est davantage lié à la manière dont le système de Microsoft gère la structure MIME et l'encodage des caractères qu'à un problème de configuration de votre signature.

Le moyen le plus simple de le vérifier consiste à comparer l'en-tête « Authentication-Results » du même message sur les deux récepteurs. Voici à quoi ressemblent les cas de réussite et d'échec :

Aucun

# Sur Gmail (passes)

Authentication-Results: mx.google.com;
dkim=pass [email protected] header.s=selector1;
spf=pass; dmarc=pass

# Dans Outlook (échec avec le même message)

Authentication-Results: protection.outlook.com;
dkim=fail (body hash did not verify)
header.d=yourdomain.com header.s=selector1;
spf=pass; dmarc=fail (p=none)

Lorsque vous constatez un échec DKIM, le moyen le plus rapide de comprendre ce qui s'est passé est de consulter les en-têtes d'authentification du message lui-même, plutôt que d'essayer de deviner la cause du problème.

Comment interpréter l'en-tête « Authentication-Results »

Dans Gmail, ouvrez le message, cliquez sur le menu à trois points, puis sélectionnez «Afficher l'original». Repérez l’en-tête « Authentication-Results » et recherchez le résultat « dkim= ». Il indiquera « pass », « fail » ou « neutral », et sera généralement suivi d’une chaîne de texte expliquant la raison, telle que « body hash did not verify », « signature did not verify » ou « key too short ». Cette chaîne de texte vous indique de quel type de problème il s’agit et, par conséquent, quelle solution parmi celles proposées ci-dessus s’applique.

Pendant que vous lisez l'en-tête, les balises « DKIM-Signature » constituent des repères utiles :

v= version DKIM (par exemple, v=1)

aa = algorithme de signature (par exemple, a=rsa-sha256)

d= domaine de signature (vérifiez qu'il correspond à votre adresse d'expéditeur)

s= sélecteur, utilisé pour localiser la clé publique dans le DNS

h= les en-têtes inclus dans la signature

bh= le hachage du corps (la valeur qui provoque l'erreur « hachage du corps non vérifié »)

b= la signature cryptographique elle-même

La comparaison de la valeur « d= » avec le domaine « From » visible permet de vérifier la cohérence ; le sélecteur « s= » vous indique quel enregistrement DNS vérifier ; enfin, une divergence au niveau de « bh= » confirme que le corps du message a été modifié après la signature.

Si l'expéditeur s'avère être une adresse que vous ne reconnaissez pas, vérifiez s'il figure parmi vos expéditeurs autorisés, puis comparez-le à vos rapports d'échec DMARC pour voir quel type de messages elle envoie, et vérifiez si l'adresse IP figure sur une liste noire. 

S'il s'agit d'un expéditeur légitime, configurez DMARC correctement pour l'autoriser. Si ce n'est pas le cas, il s'agit d'un signe d'usurpation d'identité qui justifie une intervention.

J'ai corrigé l'erreur « Signature DKIM non valide ». Et maintenant ?

Pour renforcer votre configuration DKIM à partir de là :

1. Inscrivez-vous à notre service DKIM hébergé pour suivre l'évolution de vos résultats d'authentification DKIM au fil du temps.
2. Activez SPF DMARC pour renforcer la sécurité et améliorer la précision de l'authentification.
3. Renouvelez régulièrement vos clés DKIM pour bénéficier d'une protection renforcée.

Je n'arrive toujours pas à corriger l'erreur

Si l'erreur « Signature DKIM non valide » persiste, contactez votre fournisseur de messagerie pour obtenir de l'aide, ou contactez-nous pour bénéficier de conseils d'experts sur tout ce qui concerne l'authentification des e-mails.

Foire aux questions

Que signifie « Le hachage du corps de la signature DKIM n'a pas été vérifié » ? 

Cela signifie que le hachage du corps du message calculé par le serveur destinataire ne correspond pas à la valeur « bh= » enregistrée par votre serveur lors de la signature du message. Concrètement, le corps de l'e-mail a été modifié après la signature, le plus souvent par l'ajout d'une clause de non-responsabilité, d'un pied de page, d'un pixel de suivi ou d'une modification apportée par une passerelle à un stade ultérieur du processus d'envoi.

Pourquoi le hachage du corps du message DKIM échoue-t-il uniquement dans Outlook alors qu'il est validé dans Gmail ? 

Lorsqu'un message est transmis correctement sur Gmail mais échoue sur Outlook ou Hotmail, cela est généralement dû à la manière dont le système de Microsoft gère la structure MIME et l'encodage des caractères, plutôt qu'à votre configuration de signature. Ce problème survient le plus souvent avec les messages comportant des pièces jointes ou des images intégrées. Comparez le code source brut sur les deux destinataires, uniformisez votre encodage de transfert et utilisez une canonisation assouplie.

Comment puis-je activer la signature DKIM une fois les mentions légales ajoutées ? 

Réorganisez le flux de votre courrier sortant de manière à ce que la signature soit la dernière étape modifiant le contenu. Au lieu de signer puis d'ajouter une clause de non-responsabilité, ajoutez d'abord la clause de non-responsabilité, puis signez. Pour ce faire, exécutez votre signataire DKIM après les filtres de contenu et les services de clause de non-responsabilité ou de signature, afin qu'il signe le message final que le destinataire reçoit effectivement.

Quelle est la différence entre « le corps du message n'a pas pu être vérifié » et « la signature n'a pas pu être vérifiée » ? 

Le message « Body hash did not verify » signifie que le corps du message a été modifié après la signature ; la solution consiste donc à corriger le corps du message ou le flux de messagerie. Le message « Signature did not verify » est plus général et indique souvent une modification de l’en-tête signé, une incompatibilité de clé, ou un problème lié au DNS ou à la clé. La chaîne de caractères indiquant la raison dans l’en-tête « Authentication-Results » vous permet de déterminer de quel cas il s’agit.

Le protocole DKIM filtre-t-il les e-mails ? 

Le protocole DKIM ne filtre pas directement les e-mails. Il fournit un signal d'acceptation ou de rejet que les serveurs destinataires prennent en compte dans leurs propres décisions d'évaluation du spam. Les e-mails provenant d'un domaine de confiance et validés par DKIM peuvent se voir attribuer un score de spam plus faible, tandis qu'un échec à la validation DKIM peut contribuer à ce qu'un message soit marqué comme spam ou mis en quarantaine.

Puis-je ignorer les échecs DKIM si DMARC est configuré sur p=none ? 

Lorsque p=none est défini, les e-mails présentant des erreurs sont tout de même remis ; ainsi, un échec DKIM n’entraîne pas de blocage immédiat. Cependant, ignorer ce problème va à l’encontre de l’objectif de mise en place d’une politique stricte et vous empêche de vous fier à vos propres données d’authentification. Il est préférable de résoudre ces erreurs tant que p=none est défini, afin de pouvoir passer en toute sécurité à quarantine puis à p=reject par la suite.

À quelle fréquence dois-je changer mes clés DKIM? 

Une pratique courante consiste à renouveler les clés tous les six mois à un an. Ce renouvellement régulier permet de limiter les dégâts si une clé privée venait à être divulguée. Il est essentiel, dans le cadre de ce renouvellement, de mettre à jour la clé publique publiée dans le DNS, car une clé renouvelée qui ne serait pas prise en compte dans le DNS entraînerait elle-même des échecs de signature.

• À propos de
• Derniers messages

Yunes Tarada

Expert en sécurité des domaines et des e-mails chez PowerDMARC

Yunes est chef d'équipe des opérations chez PowerDMARC et possède des connaissances approfondies en matière d'authentification et de sécurité des courriels. Yunes est certifié Microsoft Azure Administrator Associate et possède des certifications CompTIA A+ et bien d'autres encore.

Derniers messages de Yunes Tarada (voir tous)

• Comment résoudre les erreurs « Signature DKIM non valide » et « Hachage du corps du message non vérifié » - 16 juillet 2026
• Guide SPF de DKIM, DMARC et SPF - 6 juillet 2026
• NIST SP 800-81r3 : Recommandations de sécurité DNS pour la messagerie électronique - 25 juin 2026