Vérificateur d’enregistrement DKIM

Qu’est-ce qu’un enregistrement DKIM ?

Un enregistrement DKIM est un enregistrement TXT de votre DNS qui contient la moitié publique de la clé avec laquelle votre serveur de messagerie signe. Il se trouve à un nom construit à partir d’un sélecteur — quelque chose comme mail._domainkey.exemple.com — et c’est une liste de paires balise=valeur. Celle qui compte est p=, qui porte la clé publique elle-même en base64.

Le serveur destinataire récupère cet enregistrement, se sert de la clé pour vérifier la signature de votre message et décide s’il vient bien de votre domaine. Si l’enregistrement manque, est mal formé ou révoqué, la vérification échoue et votre courrier est traité comme non signé.

Ce vérificateur DKIM lit un enregistrement collé et vous dit ce qu’il contient réellement : le type de clé, sa taille effective en bits, et chaque règle des spécifications que l’enregistrement met en jeu — y compris les deux qu’il est très facile de laisser activées par inadvertance.

Comment s’en servir

1. Récupérez votre enregistrement et collez-le. C’est l’enregistrement TXT situé à selecteur._domainkey.votredomaine.com. Votre hébergeur DNS en affiche la valeur ; un navigateur ne peut pas résoudre le DNS, cet outil lit donc ce que vous collez au lieu d’aller le chercher. Les quatre boutons d’exemple couvrent une clé de 1024 bits, une de 2048, un enregistrement oublié en mode test et une clé révoquée.
2. Regardez la taille de la clé. C’est la taille réelle du module, décodée depuis la clé elle-même et non devinée d’après la longueur du base64. Une clé plus petite qu’elle ne devrait l’être est ce qui cloche le plus souvent dans une configuration DKIM par ailleurs fonctionnelle.
3. Parcourez les constats. Chacun indique s’il s’agit d’une erreur, d’un avertissement ou d’une simple remarque, et de quelle spécification il provient. Les remarques sont des choses bonnes à savoir qui ne sont pas fautives : une balise inconnue est une remarque précisément parce que la norme impose d’ignorer les balises non reconnues.

1024 ou 2048 bits, et pourquoi la réponse est les deux

Le RFC 8301 dit deux choses différentes sur la taille des clés dans la même courte section, et cette distinction est ce qu’il y a de plus utile sur cette page. Les signataires DOIVENT employer des clés RSA d’au moins 1024 bits. Les signataires DEVRAIENT employer des clés RSA d’au moins 2048 bits. Ce sont des mots différents dans un document de normalisation et ils veulent dire des choses différentes : un DOIVENT est une exigence, un DEVRAIENT est une recommandation forte que l’on peut avoir de bonnes raisons d’écarter.

Une clé DKIM de 1024 bits n’est donc ni cassée ni invalide : elle satisfait l’exigence et manque la recommandation. Et cela compte parce que c’est extrêmement répandu. En sondant les plus grands domaines avec dix des noms de sélecteur habituels, 25 sur 30 publiaient un enregistrement seulement trouvable, et 14 de ces 25 — nette majorité — étaient encore en 1024 bits. C’est exactement pour cela que cet outil traite ce cas comme un avertissement et non comme une erreur.

L’argument pratique pour passer à 2048 n’est pas que quelqu’un factorise votre clé cet après-midi. C’est que les enregistrements TXT sont pénibles à modifier, que la rotation est une tâche que personne ne planifie, et que la clé publiée aujourd’hui y sera encore dans cinq ans. L’argument pratique pour ne pas se précipiter est que de très vieux vérificateurs supportaient mal les clés de plus de 2048 bits, ce qui explique que la norme recommande au lieu d’exiger.

Le même RFC met SHA-1 à la retraite sans nuance : il ne doit pas être utilisé. Si votre balise h= liste sha1 à côté de sha256, vous n’y gagnez rien et proposez une option plus faible ; si elle ne liste que sha1, l’enregistrement est tout bonnement dépassé.

Les deux drapeaux qui ne coûtent rien et coûtent tout

Une balise p= vide n’est pas un enregistrement cassé : c’est ainsi qu’on révoque une clé. Publier p= sans rien derrière est la façon documentée de dire que cette clé ne vaut plus, et les signatures faites avec elle cessent d’être vérifiées. C’est exactement ce que vous voulez en retirant une clé, et exactement ce que vous ne voulez pas quand un copier-coller a mangé la valeur.

t=y place la clé en mode test, et son effet est plus fort que le nom ne le laisse croire : un vérificateur ne doit pas traiter une signature en échec comme une raison de faire quoi que ce soit. C’est prévu pour publier une clé et observer ce qui se passe sans risquer de vrai courrier, et il est très facile de l’oublier activé ensuite. Un domaine en mode test ne tire presque aucun bénéfice de DKIM tout en paraissant, dans n’importe quel tableau de bord, entièrement configuré.

Ni l’un ni l’autre ne rend l’enregistrement invalide : un vérificateur qui ne signale que les erreurs vous dira donc que tout va bien. Les deux apparaissent ici comme des avertissements, parce que l’enregistrement est bien formé et que l’effet n’est pas celui que presque personne recherche.

Limites assumées

Un navigateur ne peut pas résoudre le DNS : cet outil ne peut donc pas aller chercher votre enregistrement ni vous dire s’il existe au nom que vous croyez. Il vérifie ce que vous collez. C’est la même contrainte que celle du vérificateur SPF de ce site, et c’est une contrainte réelle plutôt qu’un choix de conception.

Il ne peut pas non plus vous dire si la clé correspond à la clé privée avec laquelle votre serveur signe réellement. C’est l’autre moitié d’un DKIM qui fonctionne, et elle ne se teste qu’en envoyant un message et en lisant les en-têtes à l’arrivée. Un enregistrement parfaitement valide peut se trouver devant une clé qui ne correspond pas.

Les sélecteurs ne sont pas découvrables. Il n’existe aucun moyen de demander à un domaine quels sélecteurs il publie, et c’est pourquoi tout outil DKIM vous en réclame un, et pourquoi le sondage cité plus haut a dû deviner dix noms courants. Si vous ignorez le vôtre, l’en-tête de n’importe quel message signé que vous avez envoyé le porte dans le champ s=.

La taille de la clé est lue en parcourant la structure DER de la clé publique, soit une poignée de blocs imbriqués précédés de leur longueur, sans aucune bibliothèque de cryptographie. Elle est confrontée aux tailles que rapporte le module crypto de Node lui-même pour de vraies clés générées à 1024, 2048, 3072 et 4096 bits. Déduire la taille de la longueur de la chaîne base64 — raccourci fiable pour les clés RSA standard — ne sert que de contre-vérification dans les tests, jamais de réponse.

Pourquoi est-ce gratuit ?

L’analyse et le décodage de la clé s’exécutent dans votre navigateur. Aucun serveur n’intervient : rien à facturer, aucun compte à créer.

Rien n’est envoyé et rien n’est conservé. Votre enregistrement est de toute façon une valeur DNS publique, mais il ne quitte pas la page : rechargez et il a disparu.