Comment vérifier DKIM pour les e-mails applicatifs ?

Traitez une vérification DKIM comme quatre tests distincts

Une requête DNS seule ne constitue pas une vérification DKIM complète. Premièrement, confirmez que le message contient un champ DKIM-Signature et identifiez la signature que vous voulez tester. Deuxièmement, récupérez et analysez l’enregistrement de clé publique désigné par cette signature. Troisièmement, vérifiez que les en-têtes signés et le corps canonicalisé correspondent toujours à la signature cryptographique. Quatrièmement, déterminez si un domaine de signature valide est aligné sur le domaine From visible pour DMARC. Ces couches répondent à des questions différentes. Un enregistrement publié peut être inutilisé, un message peut référencer un sélecteur absent, une signature peut échouer après une modification du contenu, et une validation cryptographique peut rester non alignée sur le domaine de l’auteur. Consignez chaque résultat au lieu d’afficher un seul badge vert. Séparez aussi les états de transport et de boîte aux lettres : l’acceptation par le fournisseur, l’acceptation par le serveur de réception et le placement en boîte de réception ne sont pas des résultats de vérification DKIM.

Partez de la signature d’un vrai message

Récupérez le message brut auprès d’un destinataire contrôlé, atteint par le chemin applicatif normal. Pour chaque champ DKIM-Signature, notez le domaine de signature `d=`, le sélecteur `s=`, l’algorithme `a=`, les modes de canonicalisation `c=`, la liste des en-têtes signés `h=`, le hash du corps `bh=`, les données de signature `b=` et les horodatages le cas échéant. La RFC 6376 définit les balises de domaine de signature et de sélecteur, et s’en sert pour localiser la clé publique. Ne devinez pas le sélecteur à partir d’un tableau de bord fournisseur et n’interrogez pas `_domainkey` sans lui. Un message peut porter plusieurs signatures provenant d’un expéditeur, d’un intermédiaire ou d’un système de listes de diffusion : conservez le résultat de chaque signature. Évitez de coller des messages de production dans des vérificateurs publics : les en-têtes et corps bruts peuvent exposer des destinataires, des identifiants de message, des détails de routage, des jetons de désinscription et du contenu applicatif. Utilisez un stockage à accès restreint et une copie de diagnostic expurgée lorsque le contenu complet n’est pas nécessaire.

Interrogez le sélecteur et le domaine de signature exacts

Construisez le nom DNS à partir de la signature sous la forme `<selector>._domainkey.<signing-domain>`. Si l’en-tête contient `s=app2026` et `d=notify.example.test`, interrogez l’enregistrement TXT à `app2026._domainkey.notify.example.test`. Notez le nom d’origine, le résolveur, la réponse, le TTL et l’éventuelle chaîne de CNAME. Analysez l’enregistrement balise-valeur obtenu au lieu d’y rechercher un fragment de texte. L’enregistrement peut déclarer sa version, le type de clé, une restriction de service, des flags, les algorithmes de hash et les données de la clé publique. Une valeur de clé publique vide révoque la clé. Distinguez NXDOMAIN, une réponse vide, un contenu malformé, un algorithme non pris en charge, une clé inutilisable et un échec transitoire du résolveur. Après une modification, refaites la requête une fois le TTL expiré via un résolveur indépendant, mais ne supposez pas que tous les destinataires sont immédiatement à jour. Un succès DNS prouve seulement qu’un enregistrement a été renvoyé à cet instant ; il ne prouve pas que le message testé est vérifié ni que le fournisseur signe le trafic actuel avec ce sélecteur.

Vérifiez les en-têtes, le hash du corps et la signature

La vérification DKIM suit les règles de canonicalisation déclarées par la signature. Le vérificateur canonicalise le corps, calcule son hash et le compare à `bh=`. Il canonicalise aussi les en-têtes signés listés dans `h=`, intègre le champ DKIM-Signature comme spécifié, puis vérifie `b=` avec la clé publique. Utilisez une bibliothèque de vérification maintenue ou le résultat d’authentification d’un destinataire de confiance plutôt que de recréer ces transformations avec des opérations sur les chaînes. Une non-concordance du hash du corps signifie souvent que le corps a changé après la signature, tandis qu’un échec de signature des en-têtes peut indiquer une modification d’un en-tête signé, une mauvaise clé, des données de signature corrompues ou une erreur d’implémentation. Notez quelle phase a échoué. Vérifiez si des champs importants comme From, Subject, Date et Message-ID ont été signés, mais n’inventez pas de politique universelle d’en-têtes signés. La canonicalisation tolère des changements de mise en forme définis ; elle ne rend pas sûrs l’injection arbitraire de pieds de page, la réécriture MIME, l’altération des fins de ligne ou les modifications en cours de transport.

Lisez les résultats du destinataire dans leur périmètre de confiance

La RFC 8601 définit l’en-tête Authentication-Results et les résultats DKIM, notamment none, pass, fail, policy, neutral, temperror et permerror. Un pass signifie que le destinataire a trouvé une signature acceptable qui a réussi les tests de vérification. Un temperror peut refléter une condition susceptible d’évoluer, comme un échec temporaire de récupération de la clé ; un permerror a peu de chances de réussir lors d’une tentative ultérieure sans correction. Notez le service d’authentification émetteur du résultat, le domaine de signature, le sélecteur et l’algorithme lorsqu’ils sont fournis. Ne faites confiance qu’aux résultats insérés à l’intérieur du périmètre documenté du système de réception, car un expéditeur peut ajouter un faux champ Authentication-Results avant la transmission. Examinez le résultat de confiance le plus haut pour l’environnement de réception final et tenez compte des sauts intermédiaires. Si différents destinataires ne sont pas d’accord, comparez la version exacte du message, la vue DNS, l’heure d’évaluation, les algorithmes pris en charge et la politique locale. Ne transformez pas `dkim=pass` en affirmation selon laquelle le fournisseur de messagerie a approuvé le contenu ou l’a placé en boîte de réception.

Vérifiez l’alignement DMARC indépendamment du pass DKIM

Un pass DKIM authentifie le domaine de signature figurant dans `d=` ; il n’exige pas que ce domaine soit identique au domaine From visible au sens de la RFC 5322. La RFC 9989 n’utilise un identifiant authentifié par DKIM valide pour DMARC que s’il est aligné sur le domaine de l’auteur selon le mode d’alignement strict ou relaxed applicable. Par exemple, un message de `billing.example.test` signé avec `d=provider.test` peut réussir DKIM tout en restant non aligné. Une signature valide de `d=example.test` peut être alignée en mode relaxed, selon le calcul du domaine organisationnel et la politique. Rapportez trois champs : le résultat DKIM, le domaine de signature et la décision d’alignement. Un message peut aussi réussir DMARC grâce à un SPF aligné lorsque DKIM échoue ou n’est pas aligné : un pass DMARC ne prouve donc pas que la signature DKIM concernée a réussi. Les consignes actuelles de Gmail pour les expéditeurs incluent des exigences d’authentification et d’alignement pour le trafic concerné, mais les respecter ne garantit toujours ni l’acceptation par le serveur de réception ni le placement en boîte de réception.

Vérifiez les algorithmes actuels et la rotation des clés

La RFC 8301 met à jour les exigences cryptographiques de DKIM : les signataires doivent utiliser `rsa-sha256`, les vérificateurs doivent le prendre en charge, et `rsa-sha1` ne doit pas être utilisé. Elle exige aussi des clés de signature RSA d’au moins 1024 bits, tout en expliquant pourquoi des clés plus longues sont préférables lorsque c’est possible sur le plan opérationnel. Un vérificateur doit identifier l’algorithme et signaler le matériel obsolète ou inutilisable, sans prétendre que la longueur de la clé suffit à rendre un flux d’e-mails digne de confiance. Les workflows des fournisseurs diffèrent. Amazon SES documente qu’Easy DKIM utilise par défaut des clés de 2048 bits et avertit que changer de méthode de signature sans étape intermédiaire peut créer une période pendant laquelle les messages ne sont pas signés DKIM. Planifiez la rotation avec deux sélecteurs valides ou le mécanisme de chevauchement documenté par le fournisseur, confirmez que les nouveaux messages utilisent le nouveau sélecteur, conservez l’ancienne clé publique tant que des e-mails retardés peuvent encore arriver, et ne la supprimez qu’après la période de chevauchement. Ne publiez jamais la clé privée de signature dans le DNS, des logs, des tickets ou des prompts.

Diagnostiquez les échecs en partant du message

Lorsqu’une vérification échoue, conservez le message brut et le résultat du destinataire avant de modifier le DNS. Confirmez que le message a bien été produit par l’application et le fournisseur attendus. S’il n’y a pas de signature, vérifiez si la signature était activée pour cette identité, cette région, ce tenant ou cette catégorie de message. Si la requête sur le sélecteur échoue, comparez les valeurs exactes de `d=` et `s=`, la zone DNS, la cible CNAME, le TTL et une éventuelle rotation récente. Si la clé est analysée correctement mais que le hash du corps échoue, examinez les passerelles, les pieds de page de listes, les réécritures de suivi, les transformations MIME, les fins de ligne et les produits de sécurité susceptibles de modifier le contenu après la signature. Si la signature cryptographique échoue alors que le hash du corps concorde, examinez les modifications d’en-têtes signés, une non-concordance de clé et l’implémentation de la signature. Si DKIM réussit mais que DMARC échoue, testez l’alignement au lieu de republier la même clé. Refaites le test via des destinataires contrôlés après expiration du TTL concerné ou propagation de la configuration, et consignez des preuves pour chaque catégorie de message au lieu de déclarer tout le domaine corrigé à partir d’un seul échantillon réussi.

Tenez un registre de vérification DKIM auditable

Pour chaque message contrôlé, conservez un identifiant de corrélation non sensible, le système d’envoi, le compte ou l’espace de travail du fournisseur, le domaine From visible, le système de réception, l’heure du message et le résultat complet de chaque signature. Incluez `d=`, `s=`, `a=`, la canonicalisation, les en-têtes signés, le nom de la requête DNS, l’heure et le TTL de la réponse DNS, le statut de l’enregistrement de clé, le résultat du hash du corps, le résultat de la signature, la valeur Authentication-Results de confiance, la décision d’alignement DMARC et le responsable de la correction. Ne stockez les messages bruts que là où les contrôles d’accès et de conservation sont appropriés. Ajoutez le scénario de test : envoi applicatif normal, migration de fournisseur, rotation de clé, passage par une passerelle ou cas de transfert. Les régressions deviennent ainsi comparables, et une capture d’écran ne devient pas une preuve permanente après un changement de sélecteurs ou de traitement des messages. Revérifiez après toute modification de la configuration du fournisseur, du DNS, de la méthode de signature ou du routage, ou après l’ajout d’une nouvelle catégorie de message. Un tableau de bord opérationnel doit afficher explicitement les états inconnus et indisponibles au lieu de les traiter silencieusement comme des pass ou des fail.

Comprendre la place de SendHQ dans la vérification

SendHQ exige un domaine From vérifié et fournit des événements de livraison. Pour une vérification DKIM, envoyez un message contrôlé par le chemin applicatif prévu, inspectez la signature reçue, interrogez les valeurs réelles `d=` et `s=`, et enregistrez l’alignement séparément. Ne déduisez pas un sélecteur, une longueur de clé, un algorithme de signature, le placement en boîte de réception ou une garantie de livraison de la seule documentation produit.

Questions fréquentes

Sources

• RFC 6376: DomainKeys Identified Mail (DKIM) Signatures — RFC Editor
• RFC 8301: Cryptographic Algorithm and Key Size Update to DomainKeys Identified Mail (DKIM) — RFC Editor
• RFC 8601 : Authentication-Results Header Field — RFC Editor
• RFC 9989: Domain-based Message Authentication, Reporting, and Conformance (DMARC) — RFC Editor
• Consignes de Gmail pour les expéditeurs d’e-mails — Google
• Easy DKIM dans Amazon SES — Amazon Web Services
• Contrat OpenAPI de SendHQ — SendHQ