DKIM fail : comprendre l’échec et le corriger

DKIM fail indique qu'un destinataire n'a pas pu valider une signature DKIM. Ce résultat mérite une enquête, mais ne constitue pas à lui seul un verdict de confiance et ne détermine pas l'arrivée dans la boîte de réception. Pour coordonner SPF, DKIM, DMARC, routage et boîtes, commencez par notre guide de messagerie professionnelle.

Le message paraît normal au départ, mais Gmail, Microsoft ou Yahoo affiche dkim=fail. Cela peut influer sur le filtrage ou l'acceptation, avec d'autres signaux. Il faut déterminer si l'erreur vient du DNS, du système d'envoi ou d'un équipement qui modifie le message en transit.

Traitez le problème comme un incident d'authentification : lisez le résultat, classez l'échec, contrôlez le sélecteur et la clé, puis recherchez les interventions après signature. Corrigez le point identifié plutôt que de modifier les réglages au hasard.

Que signifie vraiment DKIM fail ?

Un échec DKIM signifie que la signature n'a pas été validée. Une modification du contenu peut produire fail ; une clé absente ou invalide peut produire permerror ; une erreur DNS temporaire, temperror. Distinguez ces résultats et vérifiez aussi la correspondance des clés publique et privée.

La RFC 6376 définit l'empreinte du corps dans bh= et la signature dans b=. Si leur vérification échoue, la signature ne passe pas. Cela ne démontre pas nécessairement une usurpation : signature trop tôt dans le parcours, mauvaise clé ou modification ultérieure sont aussi possibles.

Voyez DKIM comme un sceau : s'il ne peut être vérifié, il faut en chercher la cause. Un sceau invalide ne prouve pas à lui seul que tout le colis est malveillant.

Examinez d'abord Authentication-Results dans le message reçu. L'exemple suivant combine des résultats illustratifs incohérents comme situation normale : avec SPF valide et aligné sur le même domaine From, DMARC devrait généralement passer malgré l'échec DKIM.

Authentication-Results: mx.google.com;
  dkim=fail (body hash did not verify) header.i=@example.com header.s=tm1;
  spf=pass smtp.mailfrom=example.com;
  dmarc=fail header.from=example.com

Avant de modifier l'expéditeur, comparez vos données aux enregistrements DNS requis de TrekMail.

Quatre catégories courantes d'échecs DKIM

Le diagnostic porte souvent sur l'empreinte du corps, le sélecteur ou la clé, le format DNS et les modifications par un transfert ou un relais. Classer le problème évite de remplacer des clés qui n'étaient pas en cause.

Ce tableau oriente le tri initial. Confirmez ensuite la cause avec les données du message et du DNS.

Type d'échec 1 : empreinte du corps différente

L'empreinte recalculée sur le corps reçu, après la canonicalisation prévue par la signature, ne correspond pas à l'empreinte signée. Ce n'est pas toujours une comparaison octet par octet, et ce résultat ne prouve pas que le DNS est correct.

Selon la RFC 6376, si l'empreinte recalculée ne correspond pas à bh=, cette vérification échoue de façon permanente. Examinez les modifications après signature, la configuration du signataire et l'intégrité de l'échantillon analysé.

Causes fréquentes :

• Microsoft 365, Exchange ou une passerelle ajoute une mention légale après la signature.
• Mimecast, Barracuda, Proofpoint ou un autre filtre réécrit les liens.
• Un relais modifie les espaces ou les fins de ligne au-delà de ce que tolère la canonicalisation.
• Une application signe avant qu'une passerelle modifie les séparateurs MIME ou ajoute un avertissement tel que [External].

Contrôlez c=. Le mode c=simple/simple tolère moins de changements que le mode relâché. La canonicalisation relâchée du corps décrite dans la RFC 6376 ignore les espaces en fin de ligne et regroupe les espaces successifs dans les lignes. Elle tolère certains changements de présentation, pas les modifications substantielles du contenu.

DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=example.com; s=tm1; h=from:to:subject:date:mime-version;
 bh=...; b=...

Une amélioration consiste à signer à la fin du parcours que vous contrôlez, après pieds, réécritures et règles de conformité. Cela limite les modifications internes ultérieures, sans garantir la conservation des données signées par les intermédiaires externes.

Si vous transférez des messages, consultez configuration du transfert de messages et transférer la messagerie d'un domaine vers Gmail. Une route testée peut se comporter différemment lorsque d'autres intermédiaires interviennent.

Type d'échec 2 : sélecteur ou clés incorrects

La signature peut mentionner un sélecteur sans clé utilisable, ou une clé DNS différente de la privée de l'expéditeur. Il s'agit alors d'un problème de configuration ; d'autres échecs de signature peuvent provenir d'en-têtes signés modifiés.

Repérez le domaine et le sélecteur dans la signature :

DKIM-Signature: v=1; a=rsa-sha256; d=example.com; s=k1; ...

Interrogez exactement ce sélecteur :

dig txt k1._domainkey.example.com +short

Une réponse vide peut venir d'un enregistrement absent, d'un nom incorrect, de caches ou d'erreurs de requête. Vérifiez l'état DNS avant de conclure. Si une clé apparaît, comparez-la à celle attendue par l'expéditeur actuel. Lors d'une migration ou dans un environnement mixte, un autre système peut continuer à utiliser l'ancienne privée.

Cela arrive avec plusieurs expéditeurs pour un domaine : applications via SES, support via Microsoft 365 et campagnes via un autre ESP. Une rotation mal coordonnée peut provoquer des échecs intermittents.

Avec l'envoi géré TrekMail, consultez Managed TrekMail SMTP et vérifiez où la signature est appliquée dans le parcours disponible. Avec Nano ou un expéditeur externe, consultez SMTP personnalisé (BYO) : le service qui envoie réellement doit être configuré pour signer.

Type d'échec 3 : mauvaise publication des clés longues

Une clé de 2048 bits peut être mal publiée si l'interface traite incorrectement le TXT. Vous pouvez obtenir permerror, une erreur de format ou une clé incomplète dans la réponse.

La RFC 8301 exige des clés RSA d'au moins 1024 bits et recommande au moins 2048 bits. Ce choix cryptographique ne garantit pas la compatibilité avec tous les panneaux DNS.

Vérifiez que les chaînes TXT forment un seul enregistrement, sans troncature ni guillemets incorrects. L'exemple illustre la structure ; ses fragments ne constituent pas une clé utilisable.

; Good DKIM TXT record pattern
k1._domainkey.example.com IN TXT (
  "v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQE..."
  "restOfThePublicKeyContinuesHere..."
)

Interrogez le DNS et examinez toutes les chaînes, pas seulement le premier fragment :

dig txt k1._domainkey.example.com +short

Contrôlez particulièrement ce point après un changement de fournisseur DNS, un déplacement de zone ou une copie manuelle des enregistrements. Comparez la réponse complète à la clé attendue.

Type d'échec 4 : transferts, relais et défaut d'alignement

Un intermédiaire peut invalider DKIM en modifiant des données signées, tandis que SPF peut échouer avec la nouvelle route. DMARC échoue s'il ne reste aucune authentification valide et alignée ; l'acceptation dépend aussi de la politique du destinataire.

Imaginez un message de example.com envoyé à une université qui le transfère vers Gmail. SPF peut échouer, car le serveur de transfert n'est pas autorisé par le domaine original. DKIM peut survivre si les données signées restent intactes. Un pied ajouté, un lien réécrit ou un objet signé modifié peut l'invalider. DMARC échoue si aucun autre résultat valide et aligné n'est disponible.

Pour les expéditeurs ordinaires vers Gmail personnel, Google demande SPF ou DKIM ; pour les expéditeurs en masse, les deux et DMARC, avec l'alignement applicable. Les transferts et listes ont leurs particularités ; ARC peut transmettre les résultats précédents. Le destinataire décide s'il fait confiance à ARC, qui ne garantit ni acceptation ni réparation de la signature originale.

Pour les transferts, envisagez SRS et un routage qui conserve les données signées. Selon la configuration disponible, TrekMail peut utiliser SRS pour valider SPF avec le nouvel expéditeur d'enveloppe. SRS ne rétablit pas l'alignement sur le From original et ne remplace pas DKIM.

Si vous utilisez beaucoup d'alias, lisez transfert des alias et messagerie avec son domaine. Le parcours réel de chaque message compte davantage que le nombre d'alias.

Où chercher lorsqu'un échec DKIM apparaît

Suivez une procédure reproductible : résultat d'authentification, recherche du sélecteur, parcours de signature, puis alignement. Cela aide à distinguer une erreur DNS d'une modification après signature.

1. Ouvrez le message brut et trouvez Authentication-Results. Notez le résultat DKIM exact.
2. Repérez d=, s= et c= dans DKIM-Signature.
3. Interrogez le sélecteur avec dig et vérifiez le nom selector._domainkey.example.com.
4. Confirmez quelle plateforme signe réellement. Plusieurs expéditeurs peuvent produire des échecs intermittents.
5. Vérifiez si une passerelle, un filtre ou un serveur de transfert modifie le corps ou les en-têtes signés.
6. Contrôlez l'alignement : d= doit s'aligner sur le domaine From: visible pour que DKIM permette à DMARC de passer, selon le mode souple ou strict.

Autre précaution : coller des fragments dans un vérificateur externe peut provoquer de faux échecs d'empreinte. Examinez le message original complet ou un fichier .eml exporté sans modification.

Corriger DKIM fail avec un parcours coordonné TrekMail

Corriger DNS, relais et pieds chez plusieurs prestataires exige de savoir qui signe et quand. Un parcours coordonné signe après les modifications contrôlées, vérifie le DNS et distingue l'envoi géré de votre propre SMTP.

TrekMail distingue Nano avec votre propre SMTP des offres payantes avec envoi géré, selon leurs conditions. À titre indicatif, ces dernières sont annoncées à partir de $3.50 par mois. Pour une signature gérée par TrekMail, vérifiez l'offre et le chemin disponibles. Si votre configuration SES, SendGrid ou Mailgun signe, diagnostiquez DKIM dans ce service. Les offres payantes peuvent proposer un essai de 14 jours nécessitant une carte. Consultez les conditions actuelles sur les tarifs TrekMail.

Avec votre propre SMTP, l'enquête porte souvent sur le sélecteur, les clés et les modifications de la route externe. Vérifiez les faits avant d'attribuer le problème à une boîte ou à un prestataire.

Liste finale pour un incident DKIM fail

Traitez DKIM fail comme une erreur précise de vérification, pas comme une explication universelle de la délivrabilité. Lisez le résultat, interrogez le sélecteur et examinez le parcours avant de modifier la configuration.

Avant de toucher à la production :

• Lisez l'en-tête complet, pas seulement le résumé d'un rejet.
• Distinguez empreinte du corps, vérification de signature, permerror et temperror.
• Interrogez le sélecteur exact dans le DNS.
• Vérifiez que la clé est complète et que les chaînes forment le bon enregistrement.
• Signez en fin de parcours contrôlé si des modifications surviennent ensuite.
• Envisagez c=relaxed/relaxed pour les variations de présentation compatibles, pas les changements substantiels.
• Vérifiez l'alignement DMARC entre d= et le domaine From: visible.

Si l'échec persiste, recherchez sa cause plutôt que d'attendre sans données. Corrigez le point de signature, le sélecteur ou l'intermédiaire responsable, puis confirmez le résultat sur de vrais messages.