Clé DKIM : longueur recommandée, publication et rotation

Votre clé DKIM est un élément d’authentification publié dans le DNS dont l’état peut influer sur la livraison. Une clé faible, mal formée ou obsolète peut empêcher les destinataires de valider les signatures. C’est particulièrement important avec les exigences Gmail introduites en février 2024 et le renforcement annoncé à partir de novembre 2025 ; consultez les conditions actuelles. Si vous révisez encore les bases DNS, commencez par la messagerie professionnelle, puis revenez ici.

En bref : utilisez une clé DKIM RSA de 2048 bits lorsque c’est pris en charge. Publiez-la correctement, souvent en divisant le TXT en plusieurs chaînes entre guillemets. Planifiez la rotation avec des sélecteurs. Pour une rotation ordinaire, gardez l’ancien sélecteur quelques jours après la bascule afin de couvrir les messages en transit. C’est une approche prudente, pas une garantie de livraison.

Pour un nouveau domaine, consultez aussi créer une adresse e-mail avec votre domaine et les enregistrements DNS requis de TrekMail afin de préparer DKIM, SPF et DMARC ensemble.

Qu’est-ce qu’une clé DKIM ?

Il s’agit ici de la partie publique de la configuration de signature DKIM. Le serveur signe les messages sortants avec une clé privée ; le destinataire récupère la clé publique dans le DNS pour vérifier les données signées et la responsabilité du domaine signataire. Cela ne prouve pas à lui seul l’identité personnelle ni la fiabilité du From visible.

DKIM signifie DomainKeys Identified Mail. La clé privée reste dans le système d’envoi et la clé publique est publiée sous un sélecteur, généralement à un nom comme s1._domainkey.example.com.

À réception, le serveur examine la signature DKIM, recherche la clé publique dans le DNS et la valide. En cas de réussite, il obtient deux indications :

• Le corps et les en-têtes signés conservent leur intégrité selon les règles de canonicalisation de la signature.
• La signature a été produite avec accès à la clé privée correspondant au domaine et au sélecteur.

Cela ne garantit pas le placement en boîte de réception. C’est un signal cryptographique vérifiable que les filtres peuvent prendre en compte.

Quelle longueur de clé DKIM choisir ?

Choisissez RSA de 2048 bits comme recommandation pour DKIM en 2025 et 2026. Le minimum normatif autorise encore RSA de 1024 bits, mais la recommandation pratique est 2048 bits : davantage de robustesse avec moins de difficultés de taille DNS et de compatibilité que peuvent présenter les clés de 4096 bits.

Le RFC 8301 impose aux signataires au moins 1024 bits pour RSA et recommande au moins 2048 bits. Cette recommandation est techniquement importante.

Si vous reprenez une ancienne infrastructure, ne supposez pas que la clé convient. Beaucoup de panneaux et systèmes généraient par défaut 1024 bits. Même si c’était courant autrefois, cette décision mérite une révision.

La documentation Google illustre l’enjeu opérationnel. Gmail exige DKIM pour les expéditeurs en nombre, et sa FAQ décrit des limites possibles lorsque l’authentification échoue. Consultez la FAQ des consignes Google pour les expéditeurs.

Pourquoi une clé DKIM de 2048 bits peut poser problème dans le DNS

Une clé DKIM de 2048 bits peut poser problème, car chaque chaîne TXT DNS est limitée à 255 octets par fragment entre guillemets. La clé publique complète dépasse cette taille. Si le panneau attend une seule longue valeur, il peut la rejeter, la tronquer ou l’enregistrer incorrectement.

C’est un piège fréquent : le problème vient souvent de l’interface DNS, pas de la cryptographie.

La valeur publique de p= pour RSA DKIM de 2048 bits peut nécessiter plusieurs chaînes entre guillemets au sein d’un seul TXT. Le vérificateur DKIM ou l’application consommant l’enregistrement les concatène ; il ne faut pas supposer que le résolveur DNS le fait automatiquement. Des données incorrectement publiées peuvent faire échouer la validation.

Erreurs courantes :

• Le panneau coupe l’enregistrement à 255 caractères d’un octet.
• Il ajoute des espaces ou retours à la ligne dans la clé.
• Vous publiez plusieurs TXT séparés au lieu d’un TXT contenant plusieurs chaînes.
• Vous supprimez une partie du préfixe v=DKIM1; k=rsa; p= en essayant de raccourcir le texte.

Vous n’obtenez pas une clé plus faible, mais une clé potentiellement invérifiable.

Publier correctement une clé DKIM de 2048 bits

Publiez un seul TXT par sélecteur et divisez la valeur uniquement en chaînes au sein de cet enregistrement. Le vérificateur destinataire les concatène. Gardez la syntaxe valide, puis vérifiez la réponse exacte en ligne de commande.

Syntaxe de fichier de zone :

s1._domainkey.example.com. IN TXT (
  "v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAr..."
  "...rest_of_the_public_key_here...QAB"
)

Beaucoup d’interfaces web demandent le même enregistrement sur une ligne :

"v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAr..." "...rest_of_the_public_key_here...QAB"

Vérifiez ensuite depuis l’extérieur. Ne vous fiez pas seulement à l’aperçu.

dig txt s1._domainkey.example.com +short

La réponse TXT doit être complète. Deux chaînes entre guillemets sont normales si elles appartiennent au même enregistrement. Des fragments manquants, échappements inattendus ou résultats partiels demandent de vérifier aussi bien les données publiées que l’outil d’interrogation.

Avec TrekMail, consultez le SMTP géré par TrekMail et l’assistant DNS. Selon le forfait actuel, vous pouvez utiliser le SMTP géré et obtenir dans le tableau de bord la valeur de l’enregistrement DKIM du domaine. L’offre décrite présente Starter à $3.50 par mois et un essai gratuit de 14 jours avec carte bancaire pour les forfaits payants. Nano est présenté comme gratuit et utilise votre SMTP externe, dont le fournisseur signataire doit fournir clés et sélecteurs. Vérifiez les conditions actuelles.

Exemple conceptuel : vous générez une clé DKIM de 2048 bits, la collez chez un registrar qui tronque silencieusement les longs TXT, et les messages quittent toujours votre serveur. Le problème peut rester invisible jusqu’à ce que Gmail constate une authentification invalide. D’où l’importance d’une vérification externe.

Renouveler une clé DKIM en limitant les interruptions

Pour une rotation ordinaire, ajoutez un sélecteur, publiez la nouvelle clé, basculez la signature et gardez temporairement l’ancien. Évitez d’écraser la clé active. Des sélecteurs distincts réduisent les erreurs sur les messages retardés ou réessayés. En cas de fuite possible, une révocation immédiate peut primer sur la transition.

Procédure prudente pour une rotation planifiée :

1. Générez une nouvelle paire DKIM de 2048 bits.
2. Attribuez-lui un nouveau sélecteur, comme s2.
3. Publiez s2._domainkey.example.com dans le DNS.
4. Basculez la configuration de signature vers s2.
5. Gardez s1 publié plusieurs jours, selon vos files et politiques.
6. Retirez s1 lorsque les anciens messages signés ne sont plus en transit.

Un exemple de délai est 7 jours. Il peut couvrir des retards, nouvelles tentatives et caches habituels, mais n’est pas universel : adaptez-le au contexte et au motif du renouvellement.

Ne remplacez pas la clé au même sélecteur sauf maîtrise de tous les cas de signature et transit, ou demande du fournisseur. La plupart des équipes n’ont pas ce contrôle complet. Utilisez les sélecteurs pour distinguer les clés.

Avec plusieurs systèmes d’envoi, documentez l’attribution des sélecteurs. C’est important pour diagnostiquer CRM, support, application web et fournisseur de boîtes utilisant le même domaine.

Quand renouveler une clé DKIM ?

Suivez une politique fixe, et renouvelez aussi après exposition de la clé privée, changement de fournisseur ou migration d’envoi. Une cadence semestrielle peut être un point de départ pour certaines équipes. Un environnement à risque élevé peut demander un autre rythme ; une politique prévisible vaut généralement mieux que l’improvisation.

Règle opérationnelle : si la clé privée a pu fuiter, remplacez-la et envisagez sa révocation immédiate. Sans incident, appliquez tout de même la politique de rotation.

Motifs pour avancer la rotation :

• Vous avez changé de prestataire sortant.
• Vous avez retiré un fournisseur disposant d’un accès de signature.
• Vous avez exporté des clés par une procédure non sûre.
• Vous avez trouvé un ancien compte administrateur partagé dont personne ne peut expliquer l’usage.

Arguments qui ne justifient pas un report :

• « On le fera quand on aura le temps. »
• « La clé réussit encore, donc tout va bien. »
• « On ne sait plus où est la clé privée. »

Sur beaucoup de domaines clients, il s’agit d’exploitation, pas seulement de cryptographie. L’hébergement de messagerie multidomaine devient alors important. Un domaine peut se gérer à la main ; cinquante demandent un processus.

Faut-il utiliser Ed25519 pour DKIM ?

Ed25519 donne des clés beaucoup plus courtes et réduit les problèmes de longueur TXT associés à RSA-2048. La contrepartie est la compatibilité. Le RFC 8463 l’a normalisé pour DKIM, mais RSA-2048 reste généralement le choix conservateur pour une large interopérabilité.

L’avantage principal est la taille. Une clé publique Ed25519 est petite face à RSA, ce qui simplifie souvent la publication.

L’inconvénient est la variation du support. Certains destinataires et outils le gèrent bien ; d’autres peuvent ne pas le faire. RSA-2048 nécessite aussi des vérifications, même s’il est largement utilisé. Si votre plateforme accepte une double signature et que vous connaissez le chemin, tester Ed25519 avec RSA peut être pertinent.

Pour la plupart des exploitants :

• Choisissez RSA-2048 par défaut.
• Envisagez Ed25519 si vous connaissez la compatibilité des destinataires et pouvez la tester.
• Ne passez pas à Ed25519 seul simplement parce que le DNS paraît plus propre.

Ancienne et nouvelle approche : gérer DKIM à grande échelle

L’ancienne approche modifie les TXT à la main, colle de grandes clés dans différents panneaux et espère que personne n’oublie la rotation. La nouvelle adopte une gestion reproductible et, lorsque c’est pertinent, déléguée du DNS et de la signature : le cycle de vie des clés fait partie du processus de messagerie.

Ancienne approche :

• Chaque domaine a une interface DNS différente.
• Chaque rotation dépend d’un rappel susceptible d’être ignoré.
• Une faute chez un registrar peut affecter un client sans être détectée avant les problèmes de livraison.

Nouvelle approche :

• Une procédure commune pour plusieurs domaines.
• Une signature gérée avec une configuration cohérente.
• Moins de tâches répétitives liées aux longs TXT et aux écarts d’authentification.

TrekMail peut s’intégrer à ce modèle d’hébergement multidomaine forfaitaire plutôt que facturé par utilisateur. L’offre décrite comprend stockage mutualisé, boîtes IMAP, migration IMAP intégrée, catch-all, transfert, BYO SMTP sur Nano et SMTP géré sur les forfaits payants ; vérifiez les fonctions actuelles. Si vous gérez du transfert, contrôlez aussi l’authentification sur ces chemins : transférer la messagerie d’un domaine vers Gmail présente un cas connexe.

Pour les équipes et agences, l’avantage potentiel n’est pas un DNS « magique », mais moins d’erreurs répétitives grâce à un processus centralisé. L’offre décrite de Starter commence à $3.50/mois ; consultez les tarifs actuels.

Conclusion sur la clé DKIM

En règle générale, choisissez RSA-2048, publiez correctement, vérifiez avec des requêtes réelles et planifiez la rotation par sélecteur. Si vous utilisez encore 1024 bits, préparez une mise à niveau compatible. Si le panneau altère les longs TXT, corrigez la méthode ou choisissez un système qui les gère convenablement.

Ne considérez pas DKIM seul. Une clé vérifiable est plus utile lorsque SPF, DMARC et l’infrastructure d’envoi sont également bien configurés et alignés. Consultez les enregistrements DNS requis de TrekMail et créer une adresse avec votre domaine pour revoir l’ensemble.