Aller au contenu principal

DKIM fail : toutes les causes et comment les corriger

Par CaptainDNS
Publié le 19 février 2026

Arbre de diagnostic des causes d'un échec DKIM avec les correctifs associés
TL;DR
  • Un résultat dkim=fail signifie que la signature DKIM de l'email n'a pas pu être vérifiée par le serveur de réception
  • Les 3 causes les plus fréquentes : body hash altéré (contenu modifié), clé publique introuvable dans le DNS, signature expirée (délai x= dépassé)
  • Le transfert d'email casse presque toujours la signature DKIM, c'est un comportement attendu que seul ARC peut compenser
  • Utilisez la commande dig TXT selecteur._domainkey.captaindns.com pour vérifier que votre clé publique est bien publiée
  • Couplez toujours DKIM avec DMARC et SPF pour une authentification complète

Vous ouvrez les en-têtes d'un email et vous tombez sur dkim=fail. Le message a été correctement envoyé, votre configuration semblait bonne, pourtant la vérification DKIM échoue. Ce scénario est fréquent et les causes sont multiples.

Ce guide passe en revue chaque cause d'un échec DKIM, explique comment la diagnostiquer et donne le correctif précis à appliquer. Que le problème vienne du DNS, de la signature, du transfert ou de l'alignement DMARC, vous saurez exactement quoi corriger.

Comment lire un résultat DKIM dans les en-têtes email ?

Chaque email reçu contient un en-tête Authentication-Results ajouté par le serveur de réception. C'est là que vous trouvez le verdict DKIM.

Les verdicts possibles

VerdictSignification
dkim=passSignature vérifiée avec succès
dkim=failLa signature existe mais la vérification a échoué
dkim=noneAucune signature DKIM trouvée dans le message
dkim=neutralSignature présente mais le vérificateur n'a pas pu conclure
dkim=temperrorErreur temporaire (timeout DNS, serveur indisponible)
dkim=permerrorErreur permanente (syntaxe DNS invalide, clé malformée)

Exemple d'en-tête avec échec

Authentication-Results: mx.google.com;
  dkim=fail (body hash did not verify) header.d=captaindns.com header.s=google header.b=abc12345;
  spf=pass smtp.mailfrom=captaindns.com;
  dmarc=fail

Le texte entre parenthèses (body hash did not verify) indique la raison précise de l'échec. C'est votre point de départ pour le diagnostic.

Les 7 causes d'un échec DKIM

Arbre de diagnostic des échecs DKIM avec les 7 causes principales

Cause 1 : body hash non vérifié

Message : body hash did not verify

C'est l'erreur la plus courante. Le serveur d'envoi calcule un hash du contenu de l'email et l'inclut dans la signature (balise bh=). Le serveur de réception recalcule ce hash. Si les deux ne correspondent pas, c'est un échec.

Causes fréquentes :

  • Un relais intermédiaire a modifié le contenu (ajout de footer, réécriture d'URL, antivirus)
  • Le serveur de mailing ajoute un pixel de tracking après la signature
  • Un proxy email ou un DLP (Data Loss Prevention) altère le corps du message

Diagnostic :

# Vérifier que l'enregistrement DKIM est bien publié
dig TXT google._domainkey.captaindns.com +short

Correctif : identifiez le service qui modifie le contenu après signature. Configurez-le pour agir avant la signature DKIM, ou excluez les modifications du corps signé.

Cause 2 : clé publique introuvable

Message : key not found ou no key for signature

Le serveur de réception ne trouve pas l'enregistrement DNS selecteur._domainkey.domaine. Sans clé publique, impossible de vérifier la signature.

Causes fréquentes :

  • Le sélecteur déclaré dans la signature (s=) ne correspond à aucun enregistrement DNS
  • L'enregistrement a été supprimé par erreur
  • Le CNAME vers le fournisseur (Google, Microsoft) n'est pas configuré
  • La propagation DNS n'est pas terminée

Diagnostic :

# Remplacez "selecteur" par la valeur du champ s= de la signature
dig TXT selecteur._domainkey.captaindns.com +short

Si la commande ne retourne rien, l'enregistrement est absent.

Correctif : publiez (ou republiez) l'enregistrement DNS TXT ou CNAME correspondant au sélecteur. Attendez la propagation DNS (jusqu'à 48h selon le TTL).

Cause 3 : signature expirée

Message : signature expired

La balise x= de la signature DKIM fixe un horodatage d'expiration. Si le serveur de réception vérifie la signature après cette date, c'est un échec.

Causes fréquentes :

  • L'email est resté en file d'attente trop longtemps (greylisting, serveur de réception lent)
  • La valeur x= est trop courte (ex: 1 heure au lieu de 7 jours)
  • Décalage d'horloge entre les serveurs

Correctif : augmentez la durée de validité de la signature. La plupart des fournisseurs utilisent 7 jours. Si vous contrôlez le serveur d'envoi, vérifiez que x= laisse un délai suffisant (minimum 72 heures recommandé).

Cause 4 : erreur de canonicalisation

Message : bad signature ou signature verification failed

La canonicalisation définit comment le serveur normalise le message avant de vérifier la signature. Deux modes existent : simple et relaxed. Si l'en-tête DKIM déclare c=simple/simple mais qu'un relais modifie des espaces ou la casse des en-têtes, la vérification échoue.

Diagnostic : dans la signature DKIM, cherchez la balise c=. Si elle vaut simple/simple, c'est probablement la cause.

Correctif : passez à c=relaxed/relaxed. Ce mode tolère les modifications mineures (espaces, casse) que les relais email effectuent couramment.

Cause 5 : clé trop courte

Message : key too short ou insecure key

Depuis 2024, Google et Yahoo refusent les clés RSA de 512 et 768 bits. La taille minimale acceptée est 1024 bits, et 2048 bits est recommandé.

Diagnostic :

# Récupérer la clé et vérifier sa taille
dig TXT google._domainkey.captaindns.com +short
# Copier la valeur p= et décoder en Base64 pour compter les bits

Correctif : générez une nouvelle paire de clés RSA 2048 bits (ou Ed25519) et publiez la nouvelle clé publique dans le DNS. Mettez à jour la configuration de votre serveur d'envoi avec la nouvelle clé privée.

Cause 6 : transfert d'email (forwarding)

Le transfert d'email est la cause la plus difficile à résoudre. Quand un serveur intermédiaire retransmet un message, il peut modifier le contenu (ajout d'en-têtes, réécriture de l'adresse de retour). La signature DKIM originale est alors invalide.

Cas typiques :

  • Transfert automatique Gmail/Outlook vers une autre boîte
  • Listes de diffusion (mailing lists) qui ajoutent un footer
  • Alias email qui relayent vers un autre domaine

Correctif : il n'existe pas de solution universelle. Le protocole ARC (Authenticated Received Chain, RFC 8617) a été conçu pour ce cas : chaque serveur intermédiaire ajoute sa propre signature ARC, formant une chaîne de confiance. Gmail et Microsoft supportent ARC. Côté expéditeur, vous ne pouvez pas empêcher la casse de signature lors du transfert.

Cause 7 : défaut d'alignement DMARC

Message : dmarc=fail (alors que dkim=pass)

Ce cas est particulier. La signature DKIM est techniquement valide (dkim=pass), mais DMARC échoue parce que le domaine d= de la signature ne correspond pas au domaine du From:. C'est un problème d'alignement, pas de signature.

Schéma de l'alignement DKIM dans le contexte DMARC

Exemple :

  • From: contact@captaindns.com
  • Signature DKIM : d=sendgrid.net (le fournisseur signe avec son propre domaine)

DKIM passe, mais l'alignement échoue car sendgrid.net ≠ captaindns.com.

Correctif : configurez votre fournisseur d'envoi pour signer avec votre domaine (d=captaindns.com). Chez la plupart des fournisseurs (SendGrid, Mailchimp, Brevo), cela passe par la création d'un CNAME selecteur._domainkey.captaindns.com pointant vers leur infrastructure.

Diagnostic rapide : tableau récapitulatif

SymptômeCause probableVérificationCorrectif
body hash did not verifyContenu modifié après signatureIdentifier le relais qui modifieSigner après modifications
key not foundEnregistrement DNS absentdig TXT s._domainkey.domainePublier le record
signature expiredDélai x= dépasséComparer x= avec l'heure de vérificationAugmenter la durée
bad signatureCanonicalisation trop stricteVérifier c= dans la signaturePasser en relaxed/relaxed
key too shortClé RSA <1024 bitsDécoder la clé publiqueRegénérer en 2048 bits
dkim=pass + dmarc=failAlignement domaineComparer d= et From:Signer avec votre domaine

Différence entre dkim=fail, dkim=none et dkim=temperror

Ces trois verdicts signalent des situations très différentes.

dkim=fail : une signature DKIM existe dans le message, mais sa vérification a échoué. C'est un problème actif à corriger.

dkim=none : aucune signature DKIM n'est présente dans le message. Le serveur d'envoi ne signe pas les emails. Configurez DKIM sur votre serveur ou votre fournisseur.

dkim=temperror : le serveur de réception n'a pas pu vérifier la signature à cause d'une erreur temporaire (timeout DNS, serveur surchargé). La vérification sera retentée. Si le problème persiste, vérifiez que vos serveurs DNS répondent rapidement (TTL bas, pas de SERVFAIL).

Plan d'action recommandé

  1. Identifiez le verdict exact : ouvrez les en-têtes email et relevez le texte entre parenthèses après dkim=fail
  2. Vérifiez votre enregistrement DNS : lancez une analyse avec le vérificateur DKIM pour confirmer que la clé publique est bien publiée et syntaxiquement valide
  3. Identifiez vos sélecteurs actifs : utilisez le DKIM Selector Finder pour scanner les sélecteurs connus sur votre domaine
  4. Corrigez la cause identifiée : appliquez le correctif correspondant à votre cas (voir tableau ci-dessus)
  5. Surveillez les résultats : après correction, envoyez des emails de test et vérifiez que dkim=pass apparaît dans les en-têtes

FAQ

Que signifie dkim=fail dans les en-têtes email ?

Le verdict dkim=fail indique que le message contient une signature DKIM, mais que le serveur de réception n'a pas pu la vérifier. Le texte entre parenthèses (ex: body hash did not verify) précise la raison de l'échec. Cela ne signifie pas forcément que l'email est frauduleux, une modification légitime du contenu en transit peut aussi provoquer cet échec.

Pourquoi mon DKIM échoue alors que l'enregistrement DNS est correct ?

Si votre enregistrement DNS est valide mais que DKIM échoue, le problème vient probablement du contenu du message. Un relais intermédiaire (antivirus, DLP, proxy) a pu modifier le corps après la signature. Vérifiez aussi que le sélecteur dans la signature (s=) correspond bien à celui publié dans le DNS.

Quelle est la cause du message 'body hash did not verify' ?

Ce message signifie que le hash du contenu calculé par le serveur de réception ne correspond pas au hash déclaré dans la signature (balise bh=). Le corps du message a été modifié entre la signature et la vérification. Les causes les plus fréquentes sont les relais qui ajoutent un footer, les systèmes antivirus et les outils de réécriture d'URL.

Un email peut-il être livré malgré un échec DKIM ?

Oui. DKIM seul ne détermine pas la livraison. C'est la politique DMARC du domaine qui décide : avec p=none, l'email est livré même si DKIM échoue. Avec p=reject, l'email est rejeté uniquement si SPF échoue aussi (DMARC exige que l'un des deux passe). De nombreux fournisseurs livrent le message en boîte spam plutôt que de le rejeter.

Quelle est la différence entre dkim=fail et dkim=none ?

dkim=fail signifie qu'une signature existe mais que sa vérification a échoué. dkim=none signifie qu'aucune signature DKIM n'est présente dans le message. Le premier est un problème de configuration, le second indique que DKIM n'est pas activé du tout sur le serveur d'envoi.

Le transfert d'email casse-t-il toujours la signature DKIM ?

Dans la plupart des cas, oui. Le transfert modifie souvent le contenu (ajout d'en-têtes, réécriture d'adresses), ce qui invalide la signature DKIM originale. Le protocole ARC (RFC 8617) a été conçu pour résoudre ce problème en créant une chaîne de confiance entre les serveurs intermédiaires. Gmail et Microsoft supportent ARC.

Comment vérifier que ma correction DKIM a fonctionné ?

Après avoir appliqué votre correctif, envoyez un email de test vers une adresse Gmail ou Outlook. Ouvrez les en-têtes du message reçu et cherchez Authentication-Results. Si vous voyez dkim=pass, la correction est effective. Vous pouvez aussi utiliser un outil de test en ligne qui affiche les résultats d'authentification détaillés.

📖 Glossaire

  • DKIM (DomainKeys Identified Mail) : protocole d'authentification email par signature cryptographique, vérifiant l'intégrité des messages sortants.
  • Body hash : empreinte SHA-256 du corps de l'email, incluse dans la signature DKIM (balise bh=).
  • Sélecteur : identifiant texte qui forme l'adresse DNS de la clé publique DKIM (selecteur._domainkey.domaine).
  • Canonicalisation : normalisation du message (espaces, casse) avant calcul de la signature. Modes : simple ou relaxed.
  • ARC (Authenticated Received Chain) : protocole RFC 8617 qui préserve les résultats d'authentification lors du transfert d'emails.
  • Alignement DKIM : vérification par DMARC que le domaine d= de la signature correspond au domaine du From:.

Générez vos clés DKIM en quelques secondes : utilisez le Générateur DKIM pour créer une paire de clés RSA 2048 ou Ed25519 avec l'enregistrement DNS prêt à publier.

📚 Guides DKIM connexes

Sources

Articles similaires