Une clé DKIM de 1024 bits tient dans une seule chaîne TXT du DNS. Une clé de 2048 bits, non, et ce seul fait explique presque tout ce qui se passe mal quand un domaine se met à jour : l’enregistrement doit être publié sous forme de plusieurs chaînes entre guillemets qu’un destinataire recolle, et les outils intermédiaires ne coopèrent pas toujours. La clé qui ressort à l’autre bout est plus courte que celle que vous avez générée, et rien dans votre flux de courrier ne vous le dit.
La RFC 8301 l’a dit tout haut en 2018. Elle exige des signataires au moins 1024 bits et en recommande au moins 2048, et elle explique dans le même document pourquoi les clés plus fortes sont restées rares : les logiciels de provisionnement DNS qui ne gèrent qu’une chaîne de 255 octets dans un enregistrement TXT ne peuvent pas les contenir.
La longueur de la clé est la valeur p=, et rien d’autre
Un enregistrement DKIM est un enregistrement TXT placé en <selector>._domainkey.<domain> et contenant une clé publique. La balise p= la porte, encodée en base64, et sa longueur est la longueur de la clé. Rien d’autre dans l’enregistrement n’indique la force : pas de balise de bits, pas de taille d’algorithme, aucun champ qu’un panneau DNS pourrait vous montrer.
v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA...
Pour une clé RSA, p= contient une structure SubjectPublicKeyInfo : un conteneur imbriqué portant l’identifiant d’algorithme puis le module et l’exposant. La longueur en bits est la largeur de ce module, et c’est pourquoi la lire suppose d’analyser la structure plutôt que de mesurer la chaîne.
Cela compte plus qu’il n’y paraît, car la longueur de la chaîne et celle de la clé se séparent dès que quelque chose tronque la valeur.
2048 bits ne tiennent pas dans une seule chaîne DNS
Un enregistrement TXT du DNS est fait de chaînes de caractères d’au plus 255 octets chacune. Les valeurs plus longues sont publiées sous forme de plusieurs chaînes entre guillemets qu’un destinataire concatène sans séparateur. Mesuré sur des clés fraîchement générées, voici ce que coûte chaque taille.
| Clé | Valeur p= en base64 | Enregistrement entier | Chaînes DNS nécessaires |
|---|---|---|---|
| RSA 1024 | 216 caractères | 234 | 1 |
| RSA 2048 | 392 caractères | 410 | 2 |
| RSA 4096 | 736 caractères | 754 | 3 |
| Ed25519 | 44 caractères | 66 | 1 |
L’enregistrement d’exemple de la RFC 8463 elle-même publie une clé RSA en quatre chaînes entre guillemets, et un destinataire les assemble sans rien entre elles. C’est du DNS correct, et un destinataire s’en accommode sans difficulté.
La défaillance se situe en amont du destinataire. Un panneau de provisionnement qui n’accepte qu’une chaîne conserve silencieusement les 255 premiers caractères. Un panneau qui accepte la valeur entière mais insère une espace ou un saut de ligne là où étaient les guillemets produit un base64 comportant un caractère étranger à l’alphabet. Un export puis un réimport par fichier de zone peut perdre les guillemets entièrement. Chacun de ces cas produit un enregistrement qui commence toujours par v=DKIM1; k=rsa; p= et qui a toujours l’air correct dans un navigateur.
Une clé tronquée se lit comme un 2048 assuré si l’on croit l’enregistrement
C’est la partie qui mérite du soin, car elle décide si un outil de vérification sert à quelque chose.
La longueur d’un module RSA est déclarée à l’intérieur de la structure de la clé. Un lecteur qui croit la longueur déclarée trouve l’en-tête du module, lit le nombre d’octets qu’il prétend contenir et annonce la taille que ces octets représenteraient. Si la valeur a été coupée après cet en-tête, la longueur déclarée vaut toujours 2048 bits alors que les octets n’y sont plus, et le lecteur répond « 2048 » sans hésiter. Coupez une vraie clé à chaque décalage d’octet et l’immense majorité de ces coupures est rapportée comme une clé intacte de la taille prévue.
Notre propre outil de vérification DKIM exige que chaque longueur imbriquée de la structure se termine exactement là où se termine son conteneur. Une clé tronquée en un point quelconque, ou portant des résidus à la fin, devient impossible à analyser au lieu d’annoncer une taille plus courte ou la taille prévue, et une clé inanalysable est signalée comme un échec et non comme une clé absente. Une clé qui ne vérifie rien et une clé qui n’est pas publiée sont deux problèmes distincts aux solutions distinctes, et un outil qui les signale pareillement vous envoie au mauvais endroit.
Sur les domaines que nous testons pour le Unspam 2026 Email Deliverability Benchmark, 90 % signent avec une clé DKIM qui fonctionne : ce n’est donc pas un défaut d’adoption. C’est une catégorie de panne silencieuse à l’intérieur de ces 90 %.
Un p= vide est une révocation, pas une clé absente
v=DKIM1; k=rsa; p= sans rien après le signe égal est un enregistrement valide, et il signifie que la clé a été révoquée. La RFC 6376 le définit ainsi à dessein, pour qu’une clé compromise puisse être retirée sans supprimer l’enregistrement et laisser les destinataires deviner si le nom a simplement échoué à se résoudre.
Traitez la différence comme réelle. Un sélecteur révoqué est une décision que quelqu’un a prise ; un sélecteur absent est un déploiement qui n’est pas allé au bout. Dans une requête DNS ils se ressemblent énormément, et ils appellent des réponses opposées.
Il en va de même pour une rotation. Les sélecteurs existent pour qu’un domaine puisse porter plusieurs clés à la fois, et avoir s1._domainkey et s2._domainkey actifs ensemble est la façon de tourner sans trou. La signature nomme le sélecteur qu’elle a utilisé et un destinataire ne consulte que celui-là ; publier la nouvelle clé avant de basculer le signataire est donc l’ordre sûr, et retirer l’ancienne avant que le dernier message signé avec elle soit remis est l’ordre risqué.
Les clés Ed25519 font 32 octets bruts, pas une structure de clé
La RFC 8463 a ajouté la signature Ed25519, et l’enregistrement correspondant n’a pas la forme de celui de RSA. Avec k=ed25519, la valeur p= est la clé publique brute de 32 octets et non une SubjectPublicKeyInfo, ce qui explique qu’elle tienne en 44 caractères base64 et entre toujours dans une seule chaîne DNS.
La conséquence pratique est que toute autre longueur n’est pas une clé. Un fragment de 30 octets, une valeur tronquée ou une clé RSA entière restée sous une balise ed25519 sont tous inutilisables, et un outil qui annonce « Ed25519, présent » devant n’importe quelle valeur non vide ne vous apprend rien. Vérifiez la longueur, pas la présence.
L’adoption reste assez mince pour qu’Ed25519 soit d’ordinaire publié à côté de RSA plutôt qu’à sa place, car un destinataire qui ne le prend pas en charge traite la signature comme non vérifiable au lieu de se rabattre sur l’autre.
t=y fait que la signature ne compte pour rien, quelle que soit la clé
La balise t porte des drapeaux, et t=y signifie que le domaine est en test. La RFC 6376 dit à un destinataire qu’il « MUST NOT treat messages from Signers in testing mode differently from unsigned email », ce qui est plus fort qu’ignorer les échecs : la signature n’apporte strictement rien, DKIM ne peut donc pas s’aligner, et un domaine qui compte sur l’alignement DKIM n’obtient aucune réussite DKIM tant que le drapeau est posé.
Les drapeaux de test sont censés disparaître à la fin d’un déploiement, et souvent ils restent. Si un domaine publie une clé parfaite de 2048 bits, signe chaque message et accumule pourtant des échecs DMARC qu’il ne s’explique pas, vérifiez cette balise avant toute autre chose.
L’autre drapeau de la même balise est plus discret. t=s interdit à l’identité signataire d’être un sous-domaine de d=, ce qui est un durcissement délibéré et non un défaut, et aussi la différence entre un signataire qui fonctionne et un signataire qui s’arrête le jour où quelqu’un pointe un sous-domaine vers la même clé.
Que vérifier sur une clé déjà publiée
Six vérifications, dans l’ordre qui trouve les problèmes le plus vite.
- Que la clé s’analyse tout court. Non pas qu’un enregistrement existe au sélecteur, mais que la valeur qu’il contient soit une clé complète. C’est la vérification qui attrape une mise à jour tronquée.
- Que la force soit d’au moins 1024 bits et de préférence 2048. En dessous de 1024, un destinataire ne doit pas tenir la signature pour valide ; entre 1024 et 2048 elle est valide et en dessous de ce que recommande la RFC 8301.
- Que
p=ne soit pas vide, sauf révocation volontaire. - Pas de
t=y. Si le déploiement est terminé, le drapeau de test devrait avoir disparu. - Que chaque plateforme qui envoie en votre nom ait son propre sélecteur actif. Votre ESP, votre CRM, votre service d’assistance et votre outil de facturation en publient chacun un, et ils sont ajoutés à des moments différents par des personnes différentes.
- Que le sélecteur porté par la signature se résolve. Une clé publiée sous un nom que le signataire n’utilise pas est invisible.
Une réussite DKIM est nécessaire et non suffisante, car DMARC exige que le domaine signataire s’aligne avec l’adresse de votre en-tête From, et un message peut être parfaitement signé par le domaine propre d’une plateforme et échouer quand même. Notre guide des signatures DKIM couvre le format de l’enregistrement, notre guide de l’authentification des e-mails explique comment les trois enregistrements dépendent les uns des autres, et la même forme de panne silencieuse du côté SPF fait l’objet de notre guide du mécanisme include de SPF.
Pour voir la clé qu’un destinataire lit réellement, à côté du résultat de signature sur un vrai message, faites un test de spam gratuit.
