Tester un DKIM : le DNS d’un côté, le message reçu de l’autre

Ce qu’un test DKIM vérifie réellement

Un message signé transporte un en-tête DKIM-Signature qui contient tout sauf la clé. Version réduite d'un cas réel : v=1; a=rsa-sha256; c=relaxed/relaxed; d=exemple.fr; s=mars2026; h=from:to:subject:date; bh=uoq1oCg...; b=Hk3Zt2... Le serveur destinataire lit d= et s=, va chercher la clé publique en DNS sous mars2026._domainkey.exemple.fr, recalcule le hachage du corps pour le comparer à bh=, puis vérifie la signature b= sur les seuls en-têtes énumérés dans h=. Tout le mécanisme est décrit par la RFC 6376.

Un test sérieux couvre donc deux terrains séparés. Le DNS : la clé est-elle publiée, complète, d'une taille acceptée. Le message : le corps et les en-têtes signés sont-ils arrivés intacts. Beaucoup d'outils en ligne présentés comme des DKIM testers ne font que le premier travail. Ils affichent un vert rassurant pendant que vos factures partent en dkim=fail parce qu'une passerelle antivirus ajoute une mention légale au bas de chaque courriel.

Le champ h= mérite un regard. La RFC 6376 impose d'y inclure From, et lui seul est obligatoire. Si Subject n'y figure pas, un intermédiaire peut réécrire l'objet sans casser la signature. Un vérificateur qui vous rend un simple pass sans vous montrer h= vous cache la moitié de l'information.

Tag	Rôle	Valeur typique
a=	algorithme de signature	rsa-sha256 (rsa-sha1 interdit par la RFC 8301)
d=	domaine signataire	exemple.fr
s=	sélecteur, désigne la clé	mars2026, google, selector1
c=	canonicalisation en-têtes/corps	relaxed/relaxed
h=	en-têtes couverts par la signature	from:to:subject:date
bh=	hachage du corps	base64, la cause n°1 des échecs
l=	longueur de corps signée	à éviter, autorise l'ajout de contenu
t= / x=	horodatage et expiration	optionnels

Interroger le sélecteur avec dig

La commande tient sur une ligne : dig +short TXT mars2026._domainkey.exemple.fr. Vous devez récupérer une chaîne qui commence par v=DKIM1; k=rsa; p= suivie du base64 de la clé publique. Si la réponse est vide, le sélecteur n'existe pas et aucun réglage côté serveur d'envoi n'y changera rien.

Le piège arrive avec les clés de 2048 bits. Le DNS limite chaque chaîne de caractères d'un TXT à 255 octets, or le base64 d'une clé RSA 2048 tourne autour de 390 caractères. L'enregistrement doit donc être découpé en deux chaînes entre guillemets que le résolveur reconcatène. Une interface de registrar qui refuse le découpage, ou un copier-coller qui laisse traîner un guillemet au milieu du base64, produit une clé que personne ne sait parser. dig vous montre la réalité publiée, pas ce que le formulaire prétendait enregistrer.

Encore faut-il connaître le sélecteur. Deux méthodes : lire le tag s= dans l'en-tête DKIM-Signature d'un message déjà envoyé, ou consulter la documentation du prestataire. Il n'existe aucun moyen d'énumérer les sélecteurs d'un domaine depuis l'extérieur, le DNS ne permet pas de lister les sous-noms.

Pour vérifier que la clé publiée correspond bien à la clé privée de votre serveur : openssl rsa -in dkim.private -pubout -outform der | openssl base64 -A. Le résultat doit être identique, caractère pour caractère, à la valeur de p=. Sous OpenDKIM, opendkim-testkey -d exemple.fr -s mars2026 -vvv fait la même comparaison et répond key OK.

• Google Workspace : sélecteur google par défaut, clé générée dans la console d'administration
• Microsoft 365 : selector1 et selector2, publiés en CNAME vers selector1-exemple-fr._domainkey.votretenant.onmicrosoft.com
• Mailchimp : k1, en CNAME vers dkim.mcsv.net
• SendGrid : s1 et s2, en CNAME vers sendgrid.net
• Amazon SES : trois CNAME dont les jetons sont générés par domaine

Lire le verdict sur un message réellement reçu

Envoyez-vous un message depuis le service concerné vers une boîte Gmail, ouvrez le menu Afficher l'original. La ligne Authentication-Results donne le résultat brut, du type dkim=pass header.i=@exemple.fr header.s=mars2026 header.b=Hk3Zt2. C'est le seul test qui compte, parce qu'il fait tourner la chaîne complète : signature, transport, vérification.

Attention à ne lire que le bon en-tête. Authentication-Results est ajouté par chaque serveur qui vérifie, et un expéditeur malveillant peut en insérer un faux dans son propre message. Seul celui déposé par votre serveur d'entrée, le plus haut dans la pile, fait foi. Les autres sont des affirmations non vérifiées.

Il existe des services par réflexion : vous écrivez à une adresse, un rapport d'authentification revient par retour de courrier. Pratique, mais ces adresses changent au fil des années et certaines ne répondent plus. Vérifiez celle affichée sur le site du service le jour où vous l'utilisez plutôt que de recopier une adresse trouvée dans un tutoriel de 2019.

Les pannes qu’un test met au jour

Le résultat body hash did not verify revient plus souvent que tous les autres réunis. La signature a été calculée, la clé a été trouvée, mais le corps du message reçu ne produit pas le même hachage que le corps signé. Quelqu'un a modifié le contenu en route : mention légale d'entreprise ajoutée par la passerelle sortante, réécriture des liens par un filtre anti-hameçonnage, conversion de l'encodage. Le correctif consiste presque toujours à signer après cette modification, pas avant.

Cas particulier des listes de diffusion : elles préfixent l'objet et ajoutent un pied de page, donc elles cassent la signature par construction. Rien à réparer de votre côté. C'est précisément le problème que la RFC 8617 tente d'adresser avec ARC, en conservant une trace des vérifications réussies avant modification.

Ce que renvoie le test	Cause probable	Correctif
dkim=none	aucun en-tête DKIM-Signature dans le message	activer la signature chez le prestataire d'envoi
dkim=permerror, no key for signature	sélecteur absent du DNS ou CNAME cassé	republier le TXT ou le CNAME, vérifier avec dig
dkim=fail, body hash did not verify	corps modifié après signature	déplacer la signature en fin de chaîne d'envoi
p= vide dans l'enregistrement	clé explicitement révoquée	regénérer la paire et republier
t=y encore présent	mode test laissé après la mise en service	retirer le tag t=y
clé de 512 ou 768 bits	en dessous du minimum de la RFC 8301	regénérer en 2048 bits
a=rsa-sha1	algorithme retiré par la RFC 8301	repasser en rsa-sha256

Un dkim=pass ne dit pas que le message est légitime

C'est la confusion la plus coûteuse. Un dkim=pass signifie que le domaine indiqué dans d= assume la responsabilité du message et que le contenu signé n'a pas bougé. Rien de plus. Un fraudeur qui achète un domaine, y publie sa propre clé et signe ses envois obtient un dkim=pass parfaitement valide.

DMARC ajoute la condition qui manque : l'alignement. Le domaine de d= doit correspondre au domaine affiché dans l'en-tête From, celui que voit le destinataire. En alignement relâché, un From facture@compta.exemple.fr signé avec d=exemple.fr passe. En alignement strict, il échoue, car les deux chaînes doivent être identiques. Un DKIM qui passe tous les tests techniques peut donc ne rien apporter à DMARC s'il signe avec le mauvais domaine, situation courante chez les plateformes d'emailing qui signent par défaut avec leur propre domaine.

Autre confusion à écarter : DKIM ne chiffre rien. Le message circule en clair, la signature garantit l'intégrité et l'origine, pas la confidentialité. Pour le contenu lui-même, il faut S/MIME ou OpenPGP, qui sont des mécanismes indépendants.

Ces tests ne relèvent plus du confort. Depuis février 2024, Google et Yahoo exigent SPF, DKIM et DMARC des expéditeurs qui dépassent 5 000 messages par jour vers leurs boîtes. En dessous de ce volume la règle est moins stricte, mais un domaine sans DKIM valide voit sa délivrabilité se dégrader progressivement.

Une limite honnête pour finir : aucun test extérieur ne vous dira si votre clé privée a fuité. La rotation régulière du sélecteur, tous les six à douze mois, reste la seule parade réaliste, et elle se teste exactement de la même façon.

Questions fréquentes

Un enregistrement DKIM valide suffit-il à passer DMARC ?

Non. DMARC exige en plus que le domaine du tag d= soit aligné avec celui de l'en-tête From. Une plateforme d'emailing qui signe avec d=sa-plateforme.com produira un dkim=pass sans jamais satisfaire DMARC pour votre domaine. Il faut configurer la signature sur votre propre domaine, ce que la plupart des prestataires proposent sous le nom de domaine authentifié ou domaine personnalisé.

Pourquoi mon DKIM passe en envoi direct et échoue via une liste de diffusion ?

La liste modifie le message : préfixe dans l'objet, pied de page ajouté, parfois réencodage du corps. Le hachage bh= ne correspond plus. Ce comportement est normal et ne vient pas d'une erreur de configuration. Certains gestionnaires de listes réécrivent l'expéditeur pour contourner le problème, d'autres s'appuient sur ARC.

Faut-il générer une clé de 1024 ou de 2048 bits ?

2048 bits. La RFC 8301 fixe 1024 comme plancher absolu et demande aux vérificateurs de savoir traiter jusqu'à 4096 bits. Au-delà de 2048, le gain de sécurité est théorique et la publication DNS devient pénible. Les clés Ed25519 de la RFC 8463 tiennent dans une seule chaîne TXT, mais tous les vérificateurs ne les gèrent pas, donc elles se publient en complément d'une clé RSA, pas à sa place.

Peut-on tester DKIM sans envoyer de message ?

Partiellement. dig vérifie la présence et la forme de la clé publique, openssl ou opendkim-testkey vérifient qu'elle correspond à la clé privée. Aucun des deux ne détecte une passerelle qui altère le corps du message en sortie. Pour cette famille de pannes, l'envoi réel est obligatoire.

Combien de temps après la publication le test devient-il fiable ?

Le temps du TTL de la zone, souvent 3600 secondes. Tant que d'anciennes valeurs sont en cache chez les résolveurs des destinataires, votre dig peut renvoyer la nouvelle clé pendant que Gmail utilise encore l'ancienne. En rotation de clé, publiez le nouveau sélecteur, attendez la fin du TTL, puis basculez la signature.

Testez vos connaissances

À lire aussi

commande dig · chiffrement asymetrique · chiffrement email · client email