Comment vérifier la signature DKIM d'un email

Authentication-Results: mx.google.com;
  dkim=pass header.d=exemple.fr;
  spf=pass ...; dmarc=pass ...

Vérifier sans attendre un email

La moitié de l'équation se contrôle sans même envoyer de message : la clé publique. Il suffit d'interroger le sélecteur en DNS :

dig TXT selecteur._domainkey.exemple.fr

La réponse doit contenir un enregistrement v=DKIM1; k=rsa; p=... avec une clé publique complète et non vide. Une clé absente, tronquée ou un p= vide (clé révoquée) garantit l'échec. Pour la vérification de bout en bout — signature comprise — un analyseur fait le tour : notre analyseur gratuit confirme la présence et la validité de la clé, et, couplé aux rapports, l'alignement réel des sources.

L'alignement : la seule chose qui compte pour DMARC

Le point mérite d'être répété, car c'est l'erreur n°1 : une signature DKIM valide n'est utile à DMARC que si elle est alignée. L'alignement DKIM signifie que le domaine d= de la signature correspond au domaine du From:. Beaucoup de plateformes signent par défaut avec leur domaine (d=plateforme.com) : dkim=pass, mais pas d'alignement, donc DMARC ne s'appuie pas dessus. La preuve définitive de l'alignement se lit dans les rapports agrégés, source par source. Pour le concept complet, voir comment les trois protocoles fonctionnent ensemble.

Pourquoi une signature légitime échoue parfois

Une signature peut échouer alors que le message est parfaitement légitime. Les causes classiques :

• Le corps du message a été modifié en transit. Une liste de diffusion qui ajoute un pied de page, une passerelle qui réécrit le contenu : le hash bh= ne correspond plus, la signature casse. C'est fréquent avec les listes et certains transferts.
• La clé publique est absente ou tronquée au sélecteur indiqué (faute de publication, clé coupée au copier-coller).
• Le sélecteur ne correspond à rien — typiquement après une rotation où l'ancien sélecteur a été retiré trop tôt.
• La clé est révoquée (p= vide) ou la propagation DNS n'est pas terminée pour une clé fraîchement publiée.

Bonne nouvelle : DKIM survit mieux au transfert que SPF (la signature voyage avec le message), ce qui en fait l'ancrage le plus fiable pour l'alignement DMARC — quand le corps n'est pas modifié.

Le cas des transferts et des listes

Un point qui déroute : un message transféré ou passé par une liste de diffusion peut voir sa signature DKIM casser si le contenu est altéré. Ce n'est pas un défaut de la configuration d'origine — c'est la liste qui modifie le message après signature. Pour ces cas, des mécanismes complémentaires existent (comme ARC, qui préserve le résultat d'authentification à travers les intermédiaires), mais l'essentiel à retenir est qu'il ne faut pas paniquer devant des échecs DKIM isolés provenant manifestement de transferts : le volume et la source se regardent avant de conclure à un problème.

Décortiquer un Authentication-Results complet

Cet en-tête condense le verdict des trois mécanismes, et savoir le lire évite bien des suppositions. Un exemple :

Authentication-Results: mx.exemple.com;
  dkim=pass header.d=entreprise.fr header.s=mail2025;
  spf=fail smtp.mailfrom=routeur.com;
  dmarc=pass (p=reject) header.from=entreprise.fr

Le décodage est immédiat. dkim=pass header.d=entreprise.fr : la signature est valide et alignée sur le domaine expéditeur — parfait. spf=fail : ici SPF échoue, parce que l'enveloppe appartient au routeur, pas à entreprise.fr ; ce n'est pas grave, car DMARC n'a besoin que d'un seul alignement. dmarc=pass (p=reject) : malgré l'échec SPF, le message satisfait DMARC grâce à DKIM aligné. C'est l'illustration concrète de pourquoi l'alignement DKIM est le cheval de trait des déploiements réels : il sauve l'authentification là où SPF, à cause de l'enveloppe tierce, ne s'aligne pas. Lire cet en-tête en entier, plutôt que de s'arrêter au premier pass, dit exactement pourquoi un message passe ou échoue.

Quand un message porte plusieurs signatures

Trouver plusieurs en-têtes DKIM-Signature sur un même message n'a rien de surprenant — c'est courant et parfaitement légitime. Beaucoup de plateformes signent deux fois : une fois avec leur propre domaine, pour le suivi de leur réputation, et une fois avec celui de l'expéditeur, pour l'alignement DMARC. Chaque signature est vérifiée indépendamment, et Authentication-Results affiche alors un verdict dkim= par signature. La règle à retenir : DMARC n'a besoin que d'une seule signature valide et alignée pour passer. Une signature en échec ou non alignée à côté d'un pass aligné n'est pas un problème à corriger — c'est simplement la signature propre de la plateforme qui fait son travail de son côté. À la lecture des en-têtes, la signature à repérer est celle dont le d= correspond au From: : c'est son sort qui compte.

Quand DKIM seul ne suffit pas

DKIM vérifie l'intégrité et l'origine, mais il ne dit rien, à lui seul, de ce qu'un destinataire doit faire d'un message non signé ou usurpé. C'est le rôle de DMARC, qui s'appuie sur l'alignement DKIM (ou SPF) et applique la politique publiée. Autrement dit, vérifier qu'une signature DKIM passe est nécessaire mais pas suffisant : tant que la politique DMARC reste en p=none, un message usurpant le domaine — sans aucune signature légitime — atteint quand même les boîtes. La vérification DKIM est donc une brique d'un édifice plus large ; une fois les signatures fiables et alignées, l'étape suivante est de durcir DMARC jusqu'à p=reject, pour que l'absence de signature valide ait enfin des conséquences réelles pour les usurpateurs.

Questions fréquentes

Où vois-je si DKIM passe ? Dans l'en-tête Authentication-Results du message reçu (dkim=pass/fail), et de façon agrégée dans les rapports DMARC. « Afficher l'original » dans la plupart des webmails donne accès aux en-têtes.

dkim=pass suffit-il ? Pour la validité de la signature, oui. Pour DMARC, non : il faut aussi que header.d (le domaine signataire) s'aligne avec le From:. Les deux se vérifient toujours ensemble.

Pourquoi mon DKIM échoue sur certains emails seulement ? Souvent parce que ces messages passent par une liste ou un transfert qui modifie le corps, cassant le hash. Les envois directs, eux, passent. Le profil (listes, faible volume dispersé) trahit la cause.

Puis-je vérifier le DKIM d'un domaine tiers ? Sa clé publique l'est (le DNS est public), et le résultat se lit dans les en-têtes d'un email reçu de sa part. C'est utile pour diagnostiquer un partenaire.

Une clé p= vide, c'est normal ? Non : un p= vide signale une clé révoquée. Des signatures pointant vers un sélecteur dont la clé est vide échoueront — il faut republier une clé valide.

Combien de temps faut-il pour que DKIM soit visible dans les rapports ? Les rapports DMARC sont envoyés à la fin de la période de rapport (souvent 24h). Les premières signatures vérifiées apparaissent donc le lendemain de l'activation. Si le volume d'envoi est faible, il faudra peut-être quelques jours pour avoir un échantillon représentatif.

Intégrer la vérification à une routine

La vérification DKIM ne devrait pas être un geste ponctuel qu'on fait au moment de la configuration, puis qu'on oublie. Trois moments clés méritent une vérification active : à l'activation (confirmer que la clé est publiée, la signature passe et s'aligne) ; après chaque rotation (confirmer que le nouveau sélecteur signe correctement et que l'ancien n'a laissé aucun raté) ; et périodiquement, via les rapports agrégés DMARC (confirmer que toutes les sources maintiennent leur alignement dans le temps, sans dérive silencieuse). Les rapports agrégés sont particulièrement utiles parce qu'ils couvrent l'ensemble des sources d'envoi sans qu'un email test doive partir vers chacune — ils donnent une vision systématique, domaine par domaine, source par source. Mettre la lecture des rapports dans une routine mensuelle — même rapide, même partielle — est le seul moyen de détecter une signature qui se dégrade avant qu'elle n'impacte la délivrabilité ou la posture DMARC.

Thomas confirme les signatures

Lire des en-têtes à la main pour chaque source, c'est fastidieux et incomplet. Thomas, le RSSI virtuel, vérifie que chaque source signe en DKIM, que la signature est valide et alignée avec le domaine, et signale les sources dont la signature casse — listes et transferts mis à part — avant qu'elles ne plombent la préparation à p=reject.

Analyser un domaine gratuitement ou créer un compte pour des signatures DKIM vérifiées en continu.