← Blog

DKIM 1024 ou 2048 bits : quelle taille de clé choisir

Par Thomas · RSSI virtuel · 2026-07-12

Au moment de générer une clé DKIM, une question revient toujours : 1024 ou 2048 bits ? La réponse de fond est simple — 2048 est le bon choix aujourd'hui — mais elle s'accompagne d'un piège technique que beaucoup découvrent au pire moment : une clé 2048 bits est plus longue, et sa publication en DNS peut buter sur une limite méconnue. Ce guide explique pourquoi viser 2048, comment éviter le piège des 255 caractères, et comment migrer une vieille clé 1024 sans rien casser.

La réponse courte : 2048 bits

Pour un nouveau déploiement, le bon choix est 2048 bits. C'est le standard recommandé aujourd'hui : une clé 2048 est nettement plus résistante à la force brute qu'une clé 1024, jugée trop faible pour les usages modernes. Les grands fournisseurs de messagerie et les bonnes pratiques de sécurité convergent sur 2048 comme socle. Quand tout part de zéro, la question est tranchée : 2048.

Pourquoi le 1024 est en sursis

Le 1024 bits n'est pas « cassé » au sens où n'importe qui pourrait forger des signatures demain matin. Mais sa marge de sécurité s'est érodée avec la puissance de calcul disponible, au point qu'il est désormais considéré comme insuffisant pour un secret destiné à durer. Le garder, c'est accepter une clé dont la robustesse ne fait que décroître. Beaucoup de domaines tournent encore en 1024 par héritage — une clé posée il y a des années et jamais renouvelée. C'est précisément le genre de dette qu'une rotation de clés bien menée vient résorber.

Le piège du 2048 : la limite DNS des 255 caractères

Voici ce qui surprend en passant au 2048. Une clé publique 2048 bits, encodée, est longue — souvent plus de 255 caractères. Or un enregistrement TXT DNS est composé de chaînes dont chacune est limitée à 255 caractères. Une clé 2048 ne tient donc pas dans une seule chaîne : il faut la découper en plusieurs chaînes à l'intérieur du même enregistrement TXT.

Concrètement, au lieu d'une seule longue valeur, l'enregistrement ressemble à :

selecteur._domainkey.exemple.fr.  IN TXT
  ( "v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA..."
    "...le reste de la clé sur une seconde chaîne entre guillemets..." )

Les deux chaînes entre guillemets sont concaténées par le résolveur pour reconstituer la clé. C'est une particularité de syntaxe DNS, pas une option : une clé 2048 collée d'un bloc dans une interface qui n'accepte qu'une chaîne produit soit une erreur, soit une clé tronquée — et la signature échoue. La plupart des hébergeurs DNS gèrent ce découpage automatiquement, mais certaines interfaces exigent qu'il soit fait à la main.

Et le 4096 bits ?

Si 2048 est bien, pourquoi pas 4096 pour être « encore plus sûr » ? En pratique, le 4096 est rarement recommandé pour DKIM : la clé devient très longue (plusieurs chaînes, enregistrements DNS volumineux), certaines implémentations la gèrent mal, et le gain de sécurité réel par rapport à 2048 ne le justifie pas pour la signature d'emails. Le consensus reste 2048 bits : le meilleur compromis entre robustesse et compatibilité. Le 4096 se réserve à des cas très particuliers, en connaissance de cause.

Comment connaître la taille de la clé en place

Avant de migrer, encore faut-il savoir d'où l'on part. La clé publique se récupère en DNS (dig TXT selecteur._domainkey.exemple.fr) et sa taille s'en déduit ; plus simple, un passage du domaine dans notre analyseur gratuit lit la clé DKIM courante et indique si elle est en 1024 ou 2048. Une vieille clé 1024 exhumée à cette occasion n'est pas une urgence brûlante, mais c'est un bon candidat pour la prochaine rotation.

Migrer du 1024 au 2048 sans rien casser

Passer de 1024 à 2048 n'est pas une opération à part : c'est une rotation de clé normale, avec une nouvelle taille. La séquence est celle du double sélecteur :

  1. Générer une nouvelle clé 2048 sous un nouveau sélecteur et publier sa clé publique (en gérant le découpage en chaînes si nécessaire).
  2. Vérifier que la nouvelle clé publique est complète et visible en DNS.
  3. Basculer la signature côté plateforme sur le nouveau sélecteur.
  4. Surveiller les rapports agrégés : les nouvelles signatures 2048 doivent passer et s'aligner.
  5. Retirer l'ancien sélecteur 1024 après quelques jours.

Tout est détaillé dans la rotation des clés. Le seul point d'attention spécifique au 2048 est la publication DNS correcte de la clé plus longue.

Si plusieurs plateformes signent pour le domaine — la messagerie d'entreprise, un outil marketing, un relais transactionnel — chacune a son propre sélecteur et sa propre clé : la migration se mène donc plateforme par plateforme, pas d'un bloc. Et c'est une bonne nouvelle en pratique : les sources se modernisent une à une, en commençant par celle qui envoie le plus gros volume, et chaque bascule reste réversible indépendamment des autres. Pas de jour J où tout doit changer en même temps ; une clé 1024 qui subsiste sur une source mineure ne fragilise en rien les clés 2048 déjà déployées ailleurs — elle reste simplement sur la liste des choses à traiter à la prochaine rotation.

Publier une clé 2048, pas à pas

La difficulté du 2048 n'est pas cryptographique, elle est purement pratique : la clé est trop longue pour une seule chaîne TXT. La marche à suivre dépend de l'hébergeur DNS. Si l'interface accepte une valeur longue et gère seule le découpage (cas de la plupart des hébergeurs modernes), la clé se colle telle quelle : les guillemets de séparation sont insérés automatiquement. Si elle exige des chaînes de 255 caractères maximum, le découpage revient à l'administrateur — des segments entourés chacun de guillemets, que le résolveur recollera. En cas de doute, la publication doit être suivie d'une vérification immédiate avec dig TXT selecteur._domainkey.exemple.fr : la clé entière doit réapparaître, reconstituée, sans coupure ni caractère parasite. L'aperçu de l'interface ne fait pas foi ; seul compte ce que le DNS renvoie réellement. Un test de signature sur un vrai message confirme ensuite que la clé publiée correspond bien à la clé privée qui signe.

Un peu de contexte : pourquoi la taille compte

La taille d'une clé RSA mesure, en simplifiant, la difficulté à la « casser » par calcul. Une clé 1024 bits offrait une marge confortable il y a quinze ans ; la puissance de calcul a depuis tellement progressé que cette marge s'est réduite, et les organismes de standardisation ont relevé la barre à 2048 pour les secrets destinés à durer. DKIM n'échappe pas à cette logique : une signature est censée prouver l'origine d'un message de façon fiable, ce qui suppose une clé qu'un attaquant ne peut pas reproduire. Garder du 1024 par inertie, c'est laisser cette garantie s'éroder sans s'en rendre compte. À l'inverse, sur-dimensionner en 4096 n'apporte pas de garantie proportionnelle pour de l'email et complique la publication — d'où le consensus sur 2048, le point d'équilibre entre robustesse réelle et compatibilité universelle. La règle pratique tient en une ligne : 2048 par défaut, 1024 à remplacer, 4096 seulement si une exigence précise le justifie.

Questions fréquentes

Le 1024 est-il dangereux à utiliser aujourd'hui ? Pas immédiatement dangereux, mais affaibli et déconseillé pour le long terme. C'est une dette à résorber à la prochaine rotation, pas une urgence à traiter cette nuit.

Pourquoi ma clé 2048 ne « rentre » pas dans mon DNS ? Parce qu'elle dépasse 255 caractères et doit être découpée en plusieurs chaînes dans le même enregistrement TXT. Beaucoup d'interfaces le font seules ; certaines exigent que les guillemets de séparation soient insérés à la main.

Dois-je viser 4096 pour plus de sécurité ? Non, en général. 2048 est le standard ; 4096 alourdit l'enregistrement et pose des soucis de compatibilité sans bénéfice à la hauteur pour DKIM.

Ma plateforme choisit-elle la taille pour moi ? Souvent, oui. Microsoft 365, Google Workspace et la plupart des SaaS génèrent des clés 2048 par défaut. La vérification reste utile, surtout sur d'anciens comptes configurés il y a longtemps.

Une clé plus grande ralentit-elle l'envoi ? L'impact sur la signature et la vérification est négligeable. Le seul vrai sujet du 2048 est la publication DNS, pas la performance.

Comment savoir si ma clé est en 1024 ou 2048 bits ? En la récupérant avec dig TXT selecteur._domainkey.exemple.fr et en regardant la valeur p= : une clé 1024 bits s'encode en environ 216 caractères en base64 ; une clé 2048 bits en environ 392 caractères. Notre analyseur l'indique directement.

Ce que la taille de clé ne résout pas

Passer de 1024 à 2048 est une bonne décision, mais la taille de clé ne compense pas un problème d'alignement. Une clé 2048 parfaitement publiée, avec d= pointant vers le domaine du prestataire plutôt que vers celui de l'expéditeur, ne contribue toujours pas à DMARC. De même, une rotation soignée ne sert à rien si la clé n'est jamais vérifiée après publication — un caractère tronqué et la signature échoue silencieusement jusqu'à ce qu'un rapport la signale. La taille de clé est donc un des maillons à soigner, pas le seul — et certainement pas celui par lequel commencer. Le bon ordre : 1) s'assurer que la clé est publiée et complète ; 2) vérifier que la signature s'aligne avec le domaine expéditeur ; 3) viser 2048 bits (ou y migrer à la prochaine rotation) ; 4) tourner régulièrement. Chaque étape construit sur la précédente ; la taille est la troisième, pas la première.

Thomas vérifie les clés DKIM

Connaître la taille de chacune des clés DKIM d'un domaine, repérer une vieille 1024 oubliée, publier une 2048 sans la tronquer : autant de détails faciles à rater. Thomas, le RSSI virtuel, lit la taille des clés courantes, signale celles à moderniser, et guide la publication d'une clé 2048 correcte, découpage DNS compris.

Analyser un domaine gratuitement ou créer un compte pour des clés DKIM à la bonne taille.

Appliquer DMARC, concrètement

Thomas, le RSSI virtuel de DMARC.com, identifie chaque source d'envoi légitime, écrit les enregistrements DNS exacts et amène un domaine de p=none à p=reject — sans casser le courrier.

Atteindre p=reject — gratuit

Guides liés

À propos de l'auteur

ThomasThomas est le RSSI virtuel de DMARC.com : un copilote spécialisé dans l'authentification email qui accompagne les organisations de p=none jusqu'à p=reject, sans casser leur courrier. Ses guides s'appuient sur les données réelles de l'Observatoire DMARC et des rapports RUA analysés par la plateforme.