Échec DKIM : signification de chaque erreur et comment y remédier

Le protocole DKIM (DomainKeys Identified Mail) est l'un des piliers fondamentaux de l'authentification des e-mails. En ajoutant une signature cryptographique aux messages sortants, le protocole DKIM permet aux serveurs de messagerie destinataires de vérifier qu'un e-mail a bien été autorisé par le propriétaire du domaine et que son contenu n'a pas été altéré pendant le transit.

Cependant, lorsqu'un serveur destinataire analyse un e-mail entrant et détecte un statut « dkim=fail » dans l'en-tête, l'authentification échoue. Un échec DKIM indique aux passerelles de réception telles que Google Workspace, Microsoft 365 ou Apple Mail que soit le corps du message a été modifié après avoir quitté l'expéditeur, soit la clé publique n'a pas pu être récupérée via le DNS, soit la signature cryptographique elle-même n'est pas valide.

En fonction de la politique DMARC de votre domaine et des paramètres de sécurité du destinataire, les échecs DKIM peuvent entraîner l'acheminement d'e-mails professionnels légitimes vers les dossiers de spam, voire leur rejet pur et simple. Ce guide sert de référence détaillée aux messages d'erreur afin de vous aider à diagnostiquer la chaîne d'erreur exacte figurant dans les en-têtes de vos e-mails, à identifier la cause première du problème et à le résoudre rapidement.

Raisons courantes de l'échec de DKIM

Si les échecs de validation DKIM sont en fin de compte dus à une non-correspondance de hachage ou à un échec de récupération de clé, les causes opérationnelles concrètes se répartissent généralement en plusieurs catégories prévisibles. En recoupant ces causes sous-jacentes avec la chaîne d'erreur spécifique figurant dans les en-têtes de vos e-mails, vous trouverez directement la solution.

1. Modifications apportées aux messages par les passerelles de messagerie et les dispositifs de sécurité

La cause la plus fréquente d’échec de la validation DKIM dans les environnements d’entreprise est l’intervention d’un service intermédiaire qui modifie le contenu d’un message après l’application de la signature DKIM. Les dispositifs de sécurité, les passerelles sortantes, les filtres anti-spam et les outils de prévention des pertes de données (DLP) modifient souvent les messages sortants en y ajoutant des pieds de page d’entreprise, en y insérant des liens de suivi, en réencodant les jeux de caractères ou en modifiant les limites MIME. 

Si la signature est effectuée au niveau du serveur de messagerie principal avant le passage par ces appareils, le hachage du corps du message calculé par le destinataire ne correspondra pas à la signature d'origine, ce qui déclenchera une erreur « dkim=fail » (hachage du corps du message non vérifié).

2. Listes de diffusion et transfert automatique des e-mails

Lorsqu'un e-mail est envoyé à une liste de diffusion ou transféré automatiquement via des agents de transfert de courrier (MTA) intermédiaires, le serveur de transfert modifie souvent les en-têtes du message (tels que « Objet » ou « À ») ou y ajoute des pieds de page relatifs à la gestion de la liste de diffusion (tels que des liens de désabonnement ou des mentions légales de la liste). La signature cryptographique couvrant ces éléments, toute modification apportée après la signature invalide le contrôle de vérification. 

Si les protocoles modernes tels que l'Authenticated Received Chain (ARC) aident les relais à préserver l'état d'authentification, les vérifications DKIM brutes effectuées sur les messages transférés échouent fréquemment.

3. Enregistrements TXT DNS manquants, mal configurés ou tronqués

Les serveurs de réception doivent récupérer votre clé publique à partir d'un enregistrement DNS de type TXT spécifique situé à l'adresse selector._domainkey.votredomaine.com. Si cet enregistrement DNS est absent, publié sous un nom de sélecteur incorrect ou retardé par la propagation DNS, le destinataire ne peut pas récupérer la clé, ce qui génère une erreur « dkim=fail » (aucune clé pour la signature).

Par ailleurs, un problème spécifique et courant se pose avec les clés RSA de 2 048 bits. Conformément à la norme RFC 1035, la longueur d’une chaîne de caractères au sein d’un enregistrement TXT DNS est limitée à 255 octets. Une clé RSA de 2 048 bits encodée en Base64 compte environ 392 caractères. Si votre fournisseur DNS ou votre administrateur colle une clé de 2 048 bits sous la forme d'une seule chaîne de caractères sans guillemets, les anciens outils de gestion DNS peuvent tronquer le contenu de la clé, ce qui entraîne une clé publique incomplète dans le DNS et provoque une erreur « dkim=fail » (signature non vérifiée).

4. Incohérences au niveau des clés, rotation des clés non annoncée et migrations de fournisseurs

Pour que la vérification DKIM aboutisse, la clé privée utilisée par le serveur de messagerie émetteur pour générer la signature doit correspondre mathématiquement à la clé publique publiée dans votre DNS. Une incompatibilité cryptographique se produit si :

• Le serveur de messagerie de signature génère une nouvelle clé privée, mais l'enregistrement DNS n'est pas mis à jour simultanément.
• Un fournisseur de services de messagerie (ESP) renouvelle ses clés de signature sans mettre à jour votre enregistrement TXT publié ni la cible de votre enregistrement CNAME.
• Un domaine est migré vers une nouvelle plateforme d'hébergement tandis que le serveur de messagerie continue de signer à l'aide d'un ancien sélecteur ou d'une paire de clés retirée.

5. Erreurs de syntaxe dans les enregistrements DNS et paramètres de canonisation stricte

De petites erreurs de formatage dans l'enregistrement de la clé publique (telles que des points-virgules manquants, des espaces superflus dans le contenu de la clé en base64 ou des noms de balises incorrects) rendent la clé publique impossible à analyser par les MTA destinataires. 

De même, si votre serveur de signature utilise la canonicalisation simple pour les en-têtes ou le contenu du corps (c=simple/simple), même des conversions mineures de fins de ligne (CRLF vs LF) ou des ajustements d'espaces blancs en fin de ligne introduits par les relais de transit empêcheront la vérification.

Avis Syntaxe de l'enregistrement DKIM.

6. Vous n'avez pas configuré DKIM pour vos fournisseurs de messagerie tiers

Si vous faites appel à plusieurs prestataires tiers pour envoyer des e-mails au nom de votre organisation, vous devez les contacter afin d'obtenir des instructions sur la manière d'activer le protocole DKIM pour vos e-mails sortants. Si vous utilisez vos propres domaines ou sous-domaines personnalisés enregistrés auprès de ce prestataire tiers pour envoyer des e-mails à vos clients, veillez à demander à votre prestataire de se charger de la mise en place du protocole DKIM pour vous.

Dans l'idéal, si votre prestataire tiers vous aide à externaliser la gestion de vos e-mails, il devrait configurer votre domaine en publiant un enregistrement DKIM sur son DNS à l'aide d'un sélecteur DKIM qui vous est propre, sans que vous ayez à intervenir.

Alternativement, 

Vous pouvez générer une paire de clés DKIM, puis transmettre la clé privée à votre fournisseur de messagerie tout en publiant la clé publique sur votre propre DNS. 

Une mauvaise configuration peut entraîner un échec du DKIM. Vous devez donc communiquer ouvertement avec votre fournisseur de services au sujet de votre configuration DKIM. 

Remarque : certains serveurs de messagerie tiers insèrent des pieds de page formatés dans le corps du message. Si ces serveurs font office d'intermédiaires dans un processus de transfert d'e-mails, la fusion des pieds de page peut contribuer à l'échec de la validation DKIM. 

7. Problèmes de communication avec le serveur

Dans certaines situations, l'e-mail peut être envoyé depuis un serveur sur lequel le protocole DKIM est désactivé. Dans ce cas, la validation DKIM échouera pour cet e-mail, même si les autres serveurs de votre infrastructure sont correctement configurés. Il est important de s'assurer que les parties communicantes ont correctement activé le protocole DKIM. 

8. Panne du DNS / Indisponibilité du DNS

Il s'agit d'une raison fréquente pour les échecs de DKIM. Les pannes DNS peuvent être dues à diverses raisons, notamment à des attaques par déni de service. La maintenance de routine de votre serveur de noms peut également être à l'origine d'une panne DNS. Pendant cette période (généralement courte), les serveurs destinataires ne peuvent pas effectuer de requêtes DNS. 

Comme nous savons que DKIM existe dans votre DNS sous la forme d'un enregistrement TXT/CNAME, le client-serveur effectue une recherche pour demander la clé publique au DNS de l'expéditeur pendant l'authentification. Lors d'une panne, cela est considéré comme impossible et peut donc casser DKIM. 

9. Utilisation d'OpenDKIM

OpenDKIM est une implémentation open source de DKIM qui peut être déployée sur votre propre serveur de messagerie pour signer et vérifier les e-mails sortants. Lorsque vous utilisez une installation OpenDKIM auto-hébergée, le service communique généralement avec le serveur de messagerie via le port 8891.

Pour vous assurer qu'OpenDKIM fonctionne correctement, vous pouvez utiliser un outil de vérification des ports en ligne afin de vérifier que le port 8891 est ouvert et accessible sur votre serveur. Vous devez également vérifier que les droits d'accès requis sont correctement configurés. Des droits d'accès incorrects peuvent empêcher OpenDKIM d'accéder à son socket ou de s'y connecter correctement.

Vérifiez la configuration de votre serveur ainsi que le répertoire contenant le socket OpenDKIM afin de vous assurer que ce répertoire existe et qu'il dispose des droits de propriété et des autorisations appropriés.

10. Vérification DKIM : erreur d'alignement

Si vous avez configuré DMARC configuré pour votre domaine en plus de DKIM, lors de la vérification DKIM, la valeur du domaine dans le champ d= de la signature DKIM dans l'en-tête de l'e-mail doit correspondre au domaine figurant dans l'adresse d'expéditeur. Il peut s'agir soit d'une correspondance stricte, dans laquelle les deux domaines doivent correspondre exactement, soit d'une correspondance souple, qui permet à une correspondance organisationnelle de passer le contrôle. 

Une erreur DKIM peut se produire si le domaine figurant dans l'en-tête de signature DKIM ne correspond pas au domaine indiqué dans l'en-tête « From », ce qui peut constituer un cas typique d’ usurpation de domaine ou d'une attaque par usurpation d'identité. 

Explication des erreurs DKIM (par message d'erreur)

Recherchez ci-dessous l'erreur qui correspond exactement à votre cas pour comprendre ce qui s'est produit sur le serveur destinataire et comment y remédier.

dkim=échec (le hachage du corps du message n'a pas été validé)

L'erreur « dkim=fail » (hachage du corps du message non validé) indique que la clé publique a bien été récupérée via le DNS et que l'en-tête de signature globale a été correctement formatée, mais que le hachage cryptographique du corps du message calculé par le destinataire ne correspond pas à la valeur de hachage stockée dans la balise « bh= » de la signature.

En termes simples, le corps de l'e-mail a été modifié après que le serveur d'envoi l'ait signé.

Causes principales :

• Les passerelles de sécurité sortantes, les outils de mention légale ou les plugins CRM ajoutaient des mentions légales, des pieds de page promotionnels ou des pixels de suivi après l'étape de signature.
• Les relais intermédiaires ont modifié les sauts de ligne, les jeux de caractères ou les espaces lors du transfert.
• Un logiciel de transfert d'e-mails ou de liste de diffusion a modifié le contenu du message.

Comment y remédier :

1. Réorganisez votre flux de courrier sortant de manière à ce que la signature DKIM soit effectuée en toute dernière étape avant que le message ne quitte votre infrastructure réseau, en veillant à ce que tous les pieds de page et liens de suivi soient ajoutés avant la signature.
2. Assurez-vous que votre serveur de messagerie utilise la canonicalisation « relaxed » du corps du message (c=relaxed/relaxed ou c=relaxed/simple), qui tolère les variations mineures au niveau des espaces et des fins de ligne lors du transit.
3. Si vous utilisez une balise « l= » (longueur) dans vos en-têtes DKIM, supprimez-la. La balise « l= » limite la partie du corps du message qui est signée et crée des failles de sécurité, sans pour autant résoudre les problèmes liés à la modification du corps du message.

dkim=échec (aucune clé pour la signature)

L'erreur « dkim=fail » (aucune clé de signature) survient lorsque le serveur destinataire extrait le domaine (d=) et le sélecteur (s=) de l'en-tête « DKIM-Signature » de l'e-mail et tente d'interroger le DNS à l'adresse s=._domainkey.d=, mais ne parvient pas à récupérer un enregistrement de clé publique valide.

Cette erreur permet de cerner le problème plus précisément : il s'agit soit d'un problème de configuration DNS, soit d'un décalage au niveau des sélecteurs.

Causes principales :

• Le nom du sélecteur spécifié par votre application émettrice ne correspond pas au préfixe du sélecteur publié dans le DNS.
• L'enregistrement TXT ou CNAME n'a jamais été publié sur le serveur DNS de référence.
• L'enregistrement DKIM a été publié récemment et ne s'est pas encore entièrement propagé parmi les résolveurs DNS du monde entier.
• L'enregistrement de la clé publique a été supprimé par inadvertance lors d'une migration de domaine ou d'un nettoyage des clés.

Comment y remédier :

1. Examinez l'en-tête brut de l'e-mail pour identifier la chaîne de sélection exacte dans la balise « s= ».
2. Vérifiez qu'un enregistrement DNS de type TXT ou CNAME existe à l'adresse selector._domainkey.votredomaine.com (pour savoir comment localiser les chaînes de sélection, consultez notre guide détaillé sur comment trouver votre sélecteur DKIM).
3. Vérifiez que l'enregistrement DNS contient les balises obligatoires « v=DKIM1; » et « k=rsa; » (ou « k=ed25519; »), ainsi que la charge utile de la clé publique « p= ».

dkim=échec (signature non vérifiée)

Contrairement à une erreur liée au corps du message, l'erreur « dkim=fail » (signature non vérifiée) signifie que l'évaluation cryptographique de la chaîne de signature principale (la balise « b= ») a échoué. Le destinataire a récupéré une clé publique via le DNS, mais cette clé n'a pas permis de déchiffrer ni de vérifier le contenu de la signature de l'en-tête.

Cette erreur indique clairement que la paire de clés n'est pas valide ou que les champs d'en-tête ont été modifiés.

Causes principales :

• Incohérence entre les clés: La clé privée utilisée par le serveur émetteur pour signer le message ne correspond pas à la clé publique publiée dans le DNS sous ce sélecteur.
• Clé DNS tronquée: Une clé de 2 048 bits a été publiée de manière incorrecte sous la forme d'une chaîne unique de plus de 255 octets, ce qui a conduit le serveur DNS à tronquer les données de la clé publique.
• Modification des en-têtes: un serveur de messagerie intermédiaire ou une passerelle a modifié les en-têtes explicitement inclus dans la balise h= de la signature (tels que « From », « To », « Subject » ou « Date ») après la génération de la signature.

Comment y remédier :

1. Vérifiez si votre enregistrement de clé publique de 2048 bits dans le DNS a bien été divisé en plusieurs chaînes de caractères entre guillemets, chacune ne dépassant pas 255 octets.
2. Vérifiez que votre clé privée sur le serveur de messagerie correspond bien à la clé publique publiée. En cas de doute, générez une nouvelle paire de clés, mettez à jour le DNS et vérifiez la correspondance.
3. Veiller à ce que les dispositifs de sécurité intermédiaires ne modifient pas les champs d'en-tête signés pendant leur transit.

Échec temporaire DKIM

Dans le cadre de l'authentification des e-mails, le « soft fail » n’est pas un statut natif du protocole DKIM. Alors que la norme SPF définit explicitement un résultat « SoftFail » (~all), la RFC 6376 définit strictement les résultats DKIM comme « pass », « fail », « policy », « neutral », « temperror » ou « permerror ».

Lorsque les administrateurs ou les outils de sécurité des e-mails signalent un « échec partiel DKIM », ils font généralement référence à l'un des deux scénarios suivants :

1. Évaluation DMARC avec p=none: Un message échoue à l'authentification DKIM, mais comme la politique DMARC du propriétaire du domaine est définie en mode surveillance (p=none), le fournisseur de messagerie destinataire achemine l'e-mail vers la boîte de réception tout en marquant le statut d'évaluation interne comme un échec mineur.
2. Classification spécifique aux passerelles: Les passerelles de sécurité de messagerie (telles que Cisco Secure Email ou Mimecast) génèrent parfois des étiquettes de diagnostic internes telles que « soft fail » lorsqu'un e-mail échoue au test DKIM, mais que la vérification « SPF » est réussie avec un alignement DMARC correct, ce qui signifie que la livraison du message dans son ensemble est autorisée.

Si vous rencontrez la mention « soft fail » dans les journaux, considérez-la comme un échec DKIM classique et vérifiez vos en-têtes pour identifier la chaîne d'erreur RFC sous-jacente (hachage du corps non validé ou absence de clé de signature).

Autres erreurs DKIM que vous pourriez rencontrer

Les serveurs de réception peuvent également afficher les codes de diagnostic DKIM normalisés suivants dans leurs en-têtes « Authentication-Results » :

Échec du DKIM mais réussite de l'SPF (et autres résultats mitigés)

Lorsque vous examinez les rapports de délivrabilité des e-mails, vous rencontrerez souvent des cas où les résultats des protocoles se contredisent. Il est essentiel, pour le dépannage, de comprendre comment les passerelles de réception évaluent ces combinaisons.

Conformément aux spécifications DMARC (RFC 7489), un e-mail est considéré comme validé selon le protocole DMARC dès lors que au moins un protocoles sous-jacents (SPF ou DKIM) renvoie un statut « PASS » et qu'il corresponde bien au domaine indiqué dans l'en-tête « From: » visible.

Voici comment les combinaisons de protocoles courantes sont mises en œuvre lors de la livraison :

Pourquoi mon message est-il bloqué à cause du DKIM ?

Si le test « SPF » est réussi mais que votre message est toujours bloqué ou marqué comme spam en raison d'un échec DKIM, l'une des deux situations suivantes se produit :

1. SPF N'est pas aligné: La vérification « SPF » a réussi pour un domaine de serveur tiers (par exemple, mail.mcsv.net), mais ne correspondait pas au domaine réel de votre en-tête « From: ». L'alignement « SPF » ayant échoué et le contrôle DKIM ayant échoué purement et simplement, le contrôle DMARC a échoué.
2. Application stricte des règles par les fournisseurs : Les principaux destinataires, tels que Google et Microsoft, appliquent des politiques de sécurité strictes à l’égard des expéditeurs en masse. Si un e-mail présente des failles d’authentification structurelles associées à des signaux indiquant un nombre élevé de plaintes pour spam, les algorithmes des destinataires peuvent bloquer le message, même s’il satisfait partiellement aux critères de validation.

Pour comprendre comment l'application de la politique affecte les e-mails non conformes, consultez notre guide sur ce qu'est une politique DMARC et testez votre domaine à l’aide de notre vérificateur d'enregistrements DMARC.

Comment interpréter les résultats DKIM dans les en-têtes de vos e-mails

Pour identifier le message d'erreur qui vous concerne, vous devez consulter les en-têtes Internet bruts d'un e-mail de test qui vous a été envoyé.

Étape 1 : Accéder aux en-têtes bruts dans votre client de messagerie

• Gmail : Ouvrez le message, cliquez sur les trois points verticaux situés à côté du bouton « Répondre », puis sélectionnez « Afficher l'original ».
• Microsoft Outlook (Web): Ouvrez le message, cliquez sur les trois points dans la barre d'actions, sélectionnez « Afficher », puis cliquez sur « Afficher les détails du message ».
• Apple Mail: Ouvrez l'e-mail, cliquez sur « Affichage » dans la barre de menu supérieure, passez la souris sur « Message », puis sélectionnez « Source brute ».

Étape 2 : Localiser l'en-tête « Authentication-Results »

Parcourez le texte brut de l'en-tête pour repérer le bloc « Authentication-Results ». Recherchez l'entrée « dkim= ».

Une entrée d'en-tête typique présentant une erreur se présente comme suit :

Résultats d'authentification : mx.google.com ;
dkim=échec (hachage du corps non validé) [email protected] header.s=s1 header.b=W8xKz2L ;
spf=pass (google.com : le domaine [email protected] désigne 192.0.2.1 comme expéditeur autorisé) [email protected];
dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=votredomaine.com

Balises d'en-tête clés à vérifier :

• dkim=: Affiche le statut de vérification immédiate (réussite, échec, erreur permanente, etc.) suivi de la chaîne d'erreur explicite entre parenthèses.
• header.i=: Affiche l'identité/le domaine qui a signé l'e-mail.
• header.s=: Identifie le sélecteur exact utilisé pour récupérer la clé publique à partir du DNS.
• header.d=: Indique le domaine organisationnel qui revendique la responsabilité de la signature.

L'analyse manuelle des en-têtes bruts des e-mails peut s'avérer complexe, chronophage et, dans l'ensemble, peu pratique. Vous pouvez éviter toutes ces étapes en utilisant notre outil gratuit outil d'analyse des en-têtes d'e-mails pour obtenir instantanément des informations claires et compréhensibles sur vos résultats d'authentification SPF, DKIM et DMARC. 

Comment corriger les échecs DKIM et empêcher leur réapparition

Suivez cette procédure systématique de correction pour résoudre les problèmes liés à DKIM au sein de votre infrastructure d'envoi :

1. Valider la clé publique dans le DNS

Utilisez un outil de recherche en ligne tel que notre Recherche d'enregistrements DKIM pour vérifier la clé publique publiée à l'adresse selector._domainkey.votredomaine.com.

• Assurez-vous qu'il n'y a pas d'erreurs de syntaxe, de fautes de frappe ou de doubles points-virgules.
• Vérifiez que le découpage de la clé est correct : si vous utilisez une clé de 2 048 bits, assurez-vous que votre éditeur DNS a divisé la charge utile en segments de chaînes de caractères entre guillemets ne dépassant pas 255 caractères (par exemple : « v=DKIM1; k=rsa; p=part1… » « part2… »). Ne créez jamais d’enregistrements TXT distincts pour un même sélecteur.

2. Déplacer la signature DKIM vers le dernier nœud de transit sortant

Si votre organisation achemine les e-mails via des passerelles de sécurité secondaires, des outils de mise en garde ou des solutions CRM, veillez à ce que la signature DKIM soit effectuée après que ces outils ont apporté leurs modifications. Si un appareil doit modifier le contenu, configurez-le de manière à ce qu'il effectue l'étape finale de signature DKIM au nom de votre domaine.

3. Mettre à jour les paramètres de canonicalisation

Modifiez les paramètres de canonicalisation de votre serveur de messagerie pour les définir sur « relaxed/relaxed » (ou « c=relaxed/relaxed » dans l'en-tête DKIM). Cela indique aux serveurs de messagerie destinataires de normaliser les espaces, les espaces de fin de ligne et le formatage des champs d'en-tête avant de recalculer le hachage, ce qui évite les faux échecs de vérification dus à des modifications mineures survenues pendant le transport.

4. Garantir l'alignement des paires de clés lors des rotations

Lors de la rotation des clés DKIM, veillez à toujours publier au préalable la nouvelle clé publique sous un nouveau nom de sélecteur dans le DNS. Prévoyez un délai de 24 à 48 heures pour la propagation du DNS avant de configurer votre serveur de messagerie afin qu’il signe les messages avec la nouvelle clé privée. Une fois la migration terminée, laissez l’ancien enregistrement de clé publique dans le DNS pendant plusieurs jours afin que les messages en cours de transmission ou en file d’attente, signés avec l’ancien sélecteur, puissent encore être vérifiés.

Notez que nous avons passé en revue certains messages d'erreur DKIM courants ainsi que leurs causes probables, tout en proposant une solution possible pour chacun d'entre eux. Cependant, des erreurs peuvent survenir pour diverses raisons sous-jacentes propres à votre domaine et à vos serveurs, qui n'ont pas été abordées dans cet article. 

Vous devez acquérir des connaissances suffisantes sur les protocoles d'authentification avant de les mettre en œuvre au sein de votre organisation ou d'appliquer vos politiques. Un échec de la validation DKIM, d'SPF ou DMARC peut nuire à la délivrabilité de vos e-mails. 

Foire aux questions

Que signifie « le hachage du corps n'a pas été vérifié » ?

« Le hachage du corps du message n'a pas pu être vérifié » signifie que la clé publique a été trouvée dans le DNS et que le format de l'en-tête était valide, mais que le contenu du message a été modifié après sa signature. Le corps du message ayant été modifié en cours de transmission (par des clauses de non-responsabilité, des passerelles de sécurité, un réencodage ou un transfert), le hachage calculé par le destinataire ne correspondait pas au hachage d'origine enregistré dans la balise « bh= » de la signature.

Comment résoudre un problème lié à DKIM ?

Pour résoudre un échec DKIM, identifiez la chaîne d'erreur exacte dans l'en-tête « Authentication-Results » de votre e-mail. Si l'erreur est liée à une clé manquante (aucune clé pour la signature), publiez ou corrigez l'enregistrement TXT de la clé publique dans le DNS sous le sélecteur approprié. Si l’erreur concerne une non-correspondance du hachage du corps du message (le hachage du corps n’a pas été vérifié), modifiez votre flux de messagerie de manière à ce que la signature DKIM intervienne en dernière étape, une fois tous les pieds de page et liens ajoutés, et définissez la canonicalisation sur « relaxed/relaxed ».

Que signifie « violation DKIM » ?

Une « violation DKIM » est un terme utilisé par certaines passerelles de sécurité de messagerie pour indiquer qu’un e-mail entrant n’a pas passé avec succès les contrôles de validation DKIM. Cela signifie généralement soit que la signature cryptographique n’était pas valide, soit que le message a été altéré pendant son acheminement, soit que l’expéditeur a tenté de signer l’e-mail en utilisant un domaine qui ne correspond pas à l’adresse d’expéditeur affichée.

Un échec DKIM signifie-t-il que mon e-mail ne sera pas remis ?

Pas nécessairement. Si votre domaine dispose d’un enregistrement « SPF » valide et conforme à l’alignement DMARC, l’e-mail passera tout de même la vérification DMARC globale et parviendra dans la boîte de réception dans la plupart des cas. Cependant, se fier uniquement à l’alignement « SPF » rend votre délivrabilité vulnérable lorsque les e-mails sont transférés. De plus, si la vérification DMARC échoue sur les deux protocoles et que la politique de votre domaine est définie sur « p=quarantine » ou « p=reject », l’e-mail non conforme sera acheminé vers le dossier spam ou rejeté purement et simplement.

• À propos de
• Derniers messages

Maitham Al Lawati

Expert en cybersécurité, PDG de PowerDMARC

Maitham est un entrepreneur technologique, expert en cybersécurité, PDG et fondateur de PowerDMARC avec plus de 15 ans d'expérience dans l'industrie. Maitham est titulaire d'un Global MBA de l'Université de Manchester et de diverses certifications professionnelles, notamment CISSP, CISM, CRISC et ISC2 CCSP.

Derniers messages de Maitham Al Lawati (voir tous)

• Échec DKIM : signification de chaque erreur et comment y remédier - 13 septembre 2026
• Méthodes d'authentification des e-mails : comment l'SPF, le DKIM et le DMARC protègent votre domaine - 9 août 2026
• Qu'est-ce qu'une politique DMARC ? « Aucune », « Quarantine » et « Rejet » - 27 juillet 2026