Comment vérifier la signature DKIM d'un email

Tu as activé DKIM, publié ta clé, et maintenant tu veux la question qui compte vraiment : est-ce que ça marche ? Vérifier une signature DKIM, c'est confirmer qu'un message a bien été signé, que la signature est valide, et — pour DMARC — qu'elle s'aligne avec ton domaine. Ce guide montre où lire le résultat, comment interpréter les balises de la signature, comment vérifier toi-même, et pourquoi une signature légitime peut parfois échouer.

La méthode la plus simple : lire Authentication-Results

Tu n'as pas besoin de refaire les calculs cryptographiques à la main : le serveur destinataire l'a déjà fait, et il écrit son verdict dans un en-tête du message, Authentication-Results. Ouvre un email que tu as envoyé (dans une boîte de réception qui n'est pas la tienne) et affiche ses en-têtes complets (souvent « Afficher l'original » ou « Voir la source »). Cherche une ligne comme :

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

Trois informations clés ici : dkim=pass (la signature est valide), header.d=ton-domaine.fr (le domaine signataire — vérifie qu'il s'agit du tien), et dmarc=pass (le tout s'aligne et satisfait DMARC). Si dkim=pass mais que header.d est celui d'un prestataire, ta signature est valide mais non alignée — elle ne compte pas pour DMARC.

Lire l'en-tête DKIM-Signature

Pour aller plus loin, regarde directement l'en-tête DKIM-Signature du message. Il contient plusieurs balises :

• d= — le domaine signataire. C'est lui qui doit s'aligner avec ton From: pour DMARC.
• s= — le sélecteur, qui pointe vers la clé publique à utiliser (voir le sélecteur).
• h= — la liste des en-têtes couverts par la signature.
• bh= — le hash du corps du message.
• b= — la signature cryptographique elle-même.

Le destinataire récupère la clé publique à s=._domainkey.d=, recalcule le hash du corps et des en-têtes signés, et compare avec b=. Si tout correspond, dkim=pass. Cette mécanique explique la plupart des échecs (voir plus bas).

Vérifier toi-même, sans attendre un email

Tu peux contrôler la moitié de l'équation sans même envoyer de message : la clé publique. Interroge le sélecteur en DNS :

dig TXT selecteur._domainkey.ton-domaine.fr

Tu dois y trouver 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 ta clé, et, couplé à tes rapports, l'alignement réel de tes sources.

L'alignement : la seule chose qui compte pour DMARC

Répétons-le, 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 de ton 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 tes rapports agrégés, source par source. Pour le concept complet, vois 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 ta configuration — 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 de ne pas paniquer devant des échecs DKIM isolés provenant manifestement de transferts : regarde le volume et la source 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 t'évite bien des suppositions. Prends 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

Décodons. dkim=pass header.d=entreprise.fr : la signature est valide et alignée sur ton domaine — parfait. spf=fail : ici SPF échoue, parce que l'enveloppe appartient au routeur, pas à toi ; 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, te dit exactement pourquoi un message passe ou échoue.

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 ta politique. Autrement dit, vérifier que ta signature DKIM passe est nécessaire mais pas suffisant : tant que ta politique DMARC reste en p=none, un message usurpant ton domaine — sans aucune signature valide de ta part — atteint quand même les boîtes. La vérification DKIM est donc une brique d'un édifice plus large ; une fois tes 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 tes 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 ton From:. Vérifie toujours les deux.

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 ? Tu peux vérifier sa clé publique (le DNS est public) et lire le résultat dans les en-têtes d'un email qu'il t'a envoyé. C'est utile pour diagnostiquer un partenaire.

Une clé p= vide, c'est normal ? Non : un p= vide signale une clé révoquée. Si tes signatures pointent vers un sélecteur dont la clé est vide, elles échoueront — republie 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). Attends-toi à voir les premières signatures vérifiées 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 dans ta 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 tes rapports agrégés DMARC (confirmer que toutes tes 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 de tes sources d'envoi sans que tu aies à envoyer un email test vers chacune — ils te 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 ta délivrabilité ou ta posture DMARC.

Laisse Thomas confirmer tes signatures

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

Analyse ton domaine gratuitement → ou crée un compte pour des signatures DKIM vérifiées en continu.