Votre clé DKIM a peut-être quinze ans

par | Sep 7, 2026 | Emailing

DKIM signe vos messages. C’est la seule des trois authentifications qui survit à un transfert, la seule que Yahoo exige pour vous dire qui s’est plaint, et la seule sans laquelle votre bouton de désabonnement en un clic ne s’affiche pas.

C’est aussi celle qu’on installe une fois, en général au moment de la mise en service du serveur de messagerie, et qu’on ne relit plus jamais.

Depuis, la norme a bougé deux fois.

Le socle, et ses deux mises à jour

DKIM est défini par la RFC 6376, publiée en septembre 2011. C’est l’un des rares textes de l’écosystème email à porter le statut d’Internet Standard, le plus haut niveau normatif de l’IETF. À titre de comparaison, DMARC n’a atteint le statut inférieur de Proposed Standard qu’en mai 2026.

Ce socle a été mis à jour deux fois en 2018, et ce sont ces deux mises à jour qui comptent aujourd’hui.

La RFC 8301, en janvier 2018, a durci les règles cryptographiques. La RFC 8463, en septembre 2018, a ajouté un nouvel algorithme de signature.

Ce que dit la règle en vigueur sur vos clés

Le texte de 2011 demandait au moins 1024 bits pour les clés à longue durée de vie, et exigeait des vérificateurs qu’ils sachent valider de 512 à 2048 bits.

La RFC 8301 a remplacé cette formulation par une règle plus nette, en section 3.2 : « Signers MUST use RSA keys of at least 1024 bits for all keys. Signers SHOULD use RSA keys of at least 2048 bits. »

Et surtout, elle a fermé la porte par le bas : « Verifiers MUST NOT consider signatures using RSA keys of less than 1024 bits as valid signatures. »

Une clé de 512 bits, parfaitement acceptable en 2011 et encore présente dans bien des configurations anciennes, ne produit donc plus une signature valide. Le message part, la signature est là, elle ne compte pas.

Yahoo reprend exactement cette règle dans ses exigences aux expéditeurs : 1024 bits minimum, 2048 recommandé.

SHA-1 est interdit, pas déconseillé

Sur l’algorithme de hachage, la RFC 8301 ne laisse aucune marge : « Due to the recognized weakness of the SHA-1 hash algorithm […] the SHA-1 hash algorithm MUST NOT be used. »

Et en section 3.1 : « Signers MUST sign using rsa-sha256. Verifiers MUST be able to verify using rsa-sha256. rsa-sha1 MUST NOT be used for signing or verifying. »

Une signature en rsa-sha1 est aujourd’hui une signature nulle. Elle apparaît pourtant encore, produite par des équipements de messagerie qui n’ont pas été mis à jour depuis 2017, et dont personne ne regarde les en-têtes de sortie.

Ed25519, et pourquoi il ne remplace pas RSA

La RFC 8463 a introduit un second algorithme de signature, ed25519-sha256. Sa clé publique fait 256 bits, ce qui la rend infiniment plus compacte qu’une clé RSA de 2048 bits : elle tient sans difficulté dans un enregistrement TXT, là où une clé RSA longue impose parfois des contorsions de découpage.

La tentation est donc de basculer. Elle serait prématurée, et la RFC elle-même indique la marche à suivre, en section 6 : « For backward compatibility, signers can add multiple signatures that use old and new signing algorithms. »

Elle précise la contrainte technique associée : chaque signature doit utiliser un sélecteur différent, puisqu’un sélecteur ne porte qu’une clé dans le DNS, même si les identifiants d= et i= restent identiques.

Signer uniquement en Ed25519, c’est parier que tous vos vérificateurs le prennent en charge. Signer avec les deux, chacun sous son sélecteur, ne coûte que quelques octets d’en-tête et supprime le pari. C’est la lecture que nous retenons du texte, et elle vaut jugement d’ingénierie, pas obligation normative.

Ce qui casse une signature, et ce qui n’est pas de votre faute

Une signature DKIM couvre un corps de message et une liste d’en-têtes, désignée par le champ h=. Tout ce qui modifie l’un ou l’autre après signature la casse.

Le cas le plus fréquent n’est pas une erreur de configuration : c’est une liste de diffusion qui préfixe le sujet, ajoute un pied de page, ou réécrit les liens. Le message reste légitime, la signature ne vaut plus rien, et l’alignement DMARC disparaît avec elle.

ARC, la chaîne de réception authentifiée définie par la RFC 8617 en juillet 2019, existe pour transporter le verdict d’authentification d’origine à travers ces intermédiaires. Elle est restée au statut Experimental, ce qui décrit assez bien la situation : le problème est identifié, la solution n’est pas normalisée.

Ce que vous faites demain matin

Récupérez un message que vous venez d’envoyer et lisez l’en-tête DKIM-Signature. Trois champs vous intéressent.

a= doit valoir rsa-sha256 ou ed25519-sha256. S’il indique rsa-sha1, votre signature ne vaut rien depuis 2018.

s= vous donne le sélecteur : interrogez alors l’enregistrement TXT correspondant et mesurez la taille de la clé publique. En dessous de 1024 bits, elle est nulle.

h= vous donne la liste des en-têtes couverts. Vérifiez-y la présence de List-Unsubscribe et List-Unsubscribe-Post si vous envoyez des messages marketing.

Le tout prend un quart d’heure et se fait sans acheter d’outil. C’est aussi ce que fait Sestaro avant un envoi : contrôler vos enregistrements SPF, DKIM et DMARC, sans jamais fabriquer de clé à votre place, parce qu’une clé de signature qui n’est pas la vôtre signe en votre nom.

Sources

LaFactory travaille l’emailing sur pièces : en-têtes, enregistrements DNS, journaux de rejet. Aucune promesse de taux d’ouverture, jamais. Contactez-nous pour un audit de délivrabilité.