Longueur de clé DKIM : comment choisir entre 1 024, 2 048 et 4 096
par
Dernière mise à jour :
9 Temps de lecture : 9 min
Points clés à retenir
- La longueur de la clé DKIM correspond au nombre de bits de votre clé de signature RSA. Les clés plus longues offrent une meilleure protection contre la falsification, mais génèrent des enregistrements DNS plus volumineux à publier.
- Le RSA à 1 024 bits est déconseillé par la RFC 8301 et ne respecte pas les exigences minimales du NIST ; pourtant, certains panneaux d'hébergement comme cPanel continuent de le générer par défaut.
- Le RSA 2048 bits est le paramètre par défaut approprié pour 2026, car il est conforme à la norme RFC 8301, aux recommandations du NIST ainsi qu'aux exigences de Google et Yahoo en matière d'envoi en masse.
- Une clé publique de 2 048 bits dépasse la limite de 255 octets imposée par l'enregistrements TXT du DNS ; vous devez donc la diviser en chaînes fragmentées, sinon la vérification échouera sans message d'erreur.
- Si l'étape de regroupement n'est pas effectuée, cela entraîne un échec DKIM silencieux : votre e-mail est tout de même envoyé, les journaux restent intacts, mais les destinataires rejettent la signature.
- Changez de clés tous les 6 à 12 mois à l'aide d'un sélecteur parallèle, et n'utilisez l'algorithme Ed25519 qu'en double signature avec RSA-2048, jamais seul.
La mise à jour de votre clé DKIM devrait renforcer la sécurité de vos e-mails. Dans la pratique, cela entraîne souvent des échecs d'authentification dus à une configuration DNS incorrecte.
De nombreuses organisations utilisent encore des clés DKIM de 1 024 bits sans s'en rendre compte. D'autres passent à 2 048 bits pour se conformer aux recommandations de sécurité actuelles, avant de découvrir que ces clés plus longues entraînent de nouvelles exigences en matière de publication. Une seule erreur lors de l'ajout de la clé publique au DNS peut entraîner l'échec de la vérification DKIM, même si l'envoi des e-mails se poursuit normalement.
Le défi consiste à choisir la bonne longueur de clé, à la publier correctement et à la maintenir au fil du temps sans perturber l'authentification des e-mails.
Ce guide explique en quoi la longueur des clés DKIM influe sur la sécurité, la délivrabilité et la conformité en 2026. Vous découvrirez les différences entre les clés de 1 024 bits, 2 048 bits, 4 096 bits et Ed25519, comment vérifier votre déploiement actuel, éviter les erreurs courantes de publication DNS et renouveler vos clés en toute sécurité.
Qu'est-ce que la longueur d'une clé DKIM ?
La longueur de la clé DKIM correspond à la taille, en bits, de la paire de clés RSA utilisée pour signer et vérifier les e-mails conformément à la norme DKIM (RFC 6376). La clé privée signe chaque message sortant au niveau du serveur de messagerie, et la clé publique correspondante est enregistrée dans un enregistrement TXT du DNS afin que les serveurs destinataires puissent vérifier la signature.
Plus une clé est longue, plus elle est difficile à pirater. Une clé de 2 048 bits résiste bien mieux à la contrefaçon qu’une clé de 1 024 bits. Cependant, la longueur de la clé implique un compromis, car elle influe à la fois sur la robustesse cryptographique, la taille des enregistrements DNS et la compatibilité avec les destinataires.
La clé publique est publiée sous un sélecteur, le label (tel que selector1._domainkey.example.com) qui indique au destinataire quelle clé utiliser, car un domaine peut gérer plusieurs clés simultanément.
Comparaison des options de longueur de clé DKIM
Toutes les clés DKIM ne se valent pas. Certaines sont obsolètes, d'autres correspondent à la norme actuelle, et d'autres encore résolvent un problème tout en en créant un autre. Voici une comparaison pratique entre les clés de 1 024 bits, 2 048 bits, 4 096 bits et Ed25519.
RSA à 1 024 bits
Le RSA à 1 024 bits était la norme DKIM d'origine ; c'est aujourd'hui l'option la moins sûre encore autorisée. Les normes ont évolué depuis. La RFC 8301 (2018) fixe à 1 024 bits la taille minimale acceptable d’une clé, mais recommande au moins 2 048 bits pour la signature. Elle exige également que les vérificateurs considèrent comme non valides les clés de moins de 1 024 bits.
NIST SP 800-131A, rév. 2 va plus loin, en interdisant l'utilisation de clés RSA inférieures à 2 048 bits pour la génération de signatures numériques et en classant les clés RSA de 1 024 bits comme relevant de la cryptographie obsolète. Les consignes de Google à l'intention des expéditeurs acceptent toujours les clés DKIM de 1 024 bits comme exigence minimale pour la distribution des e-mails via Gmail, mais recommandent des clés de 2 048 bits pour une sécurité renforcée.
Malgré toutes les recommandations, les clés de 1 024 bits restent courantes. De nombreux panneaux d'hébergement et anciennes plateformes de messagerie continuent de les générer par défaut, ce qui fait que des entreprises utilisent le RSA à 1 024 bits sans s’en rendre compte.
Une clé RSA de 1 024 bits est moins sûre que ce que préconisent les recommandations cryptographiques actuelles ; c'est pourquoi les organismes de normalisation et les fournisseurs de messagerie ont évolué vers des déploiements à 2 048 bits. Cependant, les organisations qui utilisent encore le protocole DKIM à 1 024 bits ont généralement tout intérêt à planifier et à valider une migration contrôlée plutôt que de procéder à des changements précipités susceptibles d'entraîner des échecs d'authentification.
RSA à 2048 bits
Le RSA à 2048 bits est la norme DKIM actuellement en vigueur. La RFC 8301 recommande des clés RSA d'au moins 2 048 bits pour la signature, la norme NIST SP 800-131A Rev. 2 considère que les clés RSA de 2 048 bits ou plus sont acceptables pour la génération de signatures numériques, et les consignes de Google à l'intention des expéditeurs recommandent des clés de 2 048 bits pour des raisons de sécurité. Une clé de 2 048 bits répond aux exigences actuelles du secteur, des fournisseurs et en matière de conformité.
La plupart des échecs DKIM liés aux clés de 2048 bits ne sont pas des échecs cryptographiques. Il s’agit d’échecs de publication DNS. Une clé publique de 2048 bits comporte environ 392 caractères en base64, alors qu’une chaîne DNS TXT est limitée à 255 octets. La clé ne peut donc pas être publiée sous la forme d’une seule chaîne. Elle doit être divisée en plusieurs chaînes entre guillemets au sein d’un même enregistrement TXT, que le DNS réassemble automatiquement lors de la recherche.
Si la clé est publiée de manière incorrecte, la vérification DKIM échoue même si l'enregistrement semble exister et que le serveur de messagerie continue de signer les messages normalement.
RSA à 4096 bits
La longueur de clé RSA de 4 096 bits est la plus grande longueur de clé que la plupart des destinataires sont en mesure de vérifier. La norme RFC 8301 exige que les vérificateurs valident les clés comprises entre 1 024 et 4 096 bits, et ne prévoient la validation des clés supérieures à cette longueur qu'à titre facultatif ; ainsi, une clé de plus de 4 096 bits risque de ne pas être vérifiée du tout. Le service DKIM hébergé de PowerDMARC prend en charge des longueurs de clé allant jusqu'à 4 096 bits.
Pour la plupart des organisations, une longueur de 4 096 bits n’est pas nécessaire. Elle n’apporte aucun gain de sécurité significatif par rapport à une longueur de 2 048 bits, qui répond déjà aux exigences minimales de la norme NIST SP 800-131A Rev. 2 et aux directives de Google relatives aux expéditeurs, tout en générant un enregistrement DNS plus volumineux et en ajoutant une légère surcharge lors de la vérification de la signature.
N'utilisez la clé de 4096 bits que dans des environnements hautement sécurisés ou soumis à une réglementation stricte, lorsque cela est expressément requis par une politique interne ou par un auditeur.
Ed25519 (Orientations futures)
Ed25519 est un algorithme de signature DKIM normalisé par la RFC 8463 (2018). Son principal avantage réside dans la taille de la clé. Une clé publique Ed25519 se code en une chaîne Base64 de 44 octets, ce qui permet à l'intégralité de l'enregistrement DNS de la clé de tenir dans une seule chaîne TXT. Contrairement aux algorithmes RSA-2048 et RSA-4096, il ne nécessite pas de fractionnement des enregistrements DNS et fonctionne avec les systèmes qui ne peuvent pas publier d'enregistrements TXT comportant plusieurs chaînes. La norme RFC 8463 précise également qu'Ed25519 offre une sécurité cryptographique élevée avec des clés nettement plus courtes que celles du RSA.
Le défi réside dans l'adoption. La RFC 8463 impose aux vérificateurs de prendre en charge l'algorithme Ed25519-SHA256, mais ne recommande que sa prise en charge pour la signature. Dans la pratique, la prise en charge de cet algorithme par les différentes plateformes de messagerie, les MTA et les fournisseurs de messagerie reste inégale. Un déploiement utilisant exclusivement l'algorithme Ed25519 peut entraîner des lacunes dans la vérification DKIM chez les destinataires qui ne prennent pas en charge cet algorithme.
C'est pourquoi il est préférable d'utiliser Ed25519 en association avec RSA-2048. La RFC 8463 prend explicitement en charge la double signature, ce qui permet à un message de comporter à la fois une signature RSA-SHA256 et une signature Ed25519-SHA256. Étant donné qu’un sélecteur ne peut publier qu’une seule clé publique, chaque signature doit utiliser un sélecteur différent, tout en partageant le même domaine de signature. Les destinataires vérifient la signature qu’ils prennent en charge, ce qui garantit la compatibilité tout en permettant aux organisations d’adopter Ed25519.
| Longueur de la clé | Niveau de sécurité | Taille des enregistrements DNS | État de conformité (2026) | Utilisation recommandée |
|---|---|---|---|---|
| RSA à 1 024 bits | Faible, obsolète | Tient dans une seule chaîne TXT | En dessous du seuil minimum fixé par le NIST ; utilisation réservée aux applications héritées, conformément aux recommandations du NIST ; accepté par Google comme seuil minimum absolu | Uniquement pour les systèmes hérités ; prévoyez une migration contrôlée vers le 2048 bits |
| RSA à 2048 bits | Fort ; norme en vigueur | ~392 caractères Base64 ; doit être divisé en plusieurs chaînes de caractères | Conforme à la norme RFC 8301, aux recommandations du NIST et à celles de Google | La norme pour la quasi-totalité des organisations |
| RSA à 4096 bits | Très fort | Plus grand ; doit être divisé ; la plupart des récepteurs vérifieront le plus grand | Dépasse les exigences actuelles | Uniquement dans des environnements hautement sécurisés ou réglementés |
| Ed25519 | Algorithme puissant, clés plus courtes que celles du RSA | 44 octets ; peut contenir une chaîne TXT, sans fragmentation | Normalisé dans la RFC 8463 ; les vérificateurs DOIVENT prendre en charge cette norme, les signataires DEVRAIENT le faire ; la prise en charge par les destinataires reste inégale | Signature double avec RSA-2048 |
Comment vérifier la longueur actuelle de votre clé DKIM
Avant de planifier une mise à niveau de la clé DKIM, vérifiez la taille de la clé actuellement publiée dans le DNS.
1. Identifiez votre sélecteur DKIM
Ouvrez les en-têtes d'un e-mail signé et repérez la champ « DKIM-Signature » . La valeur du champ s= est votre sélecteur. Vous pouvez également trouver ce sélecteur dans les paramètres de configuration DKIM de votre fournisseur de messagerie.
2. Recherchez l'enregistrement DKIM
Requête selector._domainkey.votredomaine.com à l'aide d'un outil de recherche DKIM ou d'un outil de requête DNS pour récupérer l'enregistrement TXT publié.
3. Vérifier la clé publique
Recherchez la balise p= dans l'enregistrement. Celle-ci contient la clé publique DKIM. La plupart des outils de vérification DKIM identifient automatiquement la longueur de la clé et indiquent s'il s'agit d'une clé de 1 024 bits, de 2 048 bits ou d'une autre taille.
4. Évaluer le résultat
Si le domaine utilise encore une clé de 1 024 bits, prévoyez une migration vers le protocole RSA 2 048 bits. Si une clé de 2 048 bits est déjà déployée et fonctionne correctement, aucune mesure immédiate n'est généralement nécessaire.
L'outil DKIM Checker de PowerDMARC récupère votre enregistrement publié et détecte automatiquement le sélecteur des principaux fournisseurs ; vous pouvez ainsi vérifier la longueur de votre clé en quelques secondes, sans avoir à décoder le code Base64 manuellement. Essayez-le gratuitement
Le problème du fractionnement DNS à 2 048 bits (et comment l'éviter)
L'une des causes les plus courantes d'échecs DKIM après une mise à niveau vers une clé de 2048 bits est la publication incorrecte des enregistrements DNS.
Le problème provient de des limitations de l'enregistrement TXT du DNS . Une chaîne TXT ne peut contenir au maximum que 255 octets, alors qu'une clé publique RSA de 2 048 bits encodée en base64 compte généralement environ 392 caractères. Par conséquent, la clé ne peut pas être publiée sous la forme d'une seule chaîne. Si un fournisseur DNS tronque l'enregistrement ou rejette l'entrée, la vérification DKIM échoue.
| Composant | Limitation |
|---|---|
| Chaîne TXT DNS unique | 255 octets maximum |
| Clé publique RSA typique de 2048 bits | Environ 392 caractères en Base64 |
| Conséquences en cas de publication erronée | Échec de la vérification DKIM |
Pour publier correctement une clé de 2048 bits, répartissez la clé publique en plusieurs chaînes de caractères entre guillemets au sein d'un même enregistrement TXT. Le DNS concatène automatiquement ces chaînes lors de la recherche.
selector1._domainkey.example.com. IN TXT (
« v=DKIM1 ; k=rsa ; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA1xN8s9k2 »
« Qp7Yv3RwL0fHmZ2bKct5oXn8eW4uV1aA9dGqB6sT0pJrN3mC2hF7lYxoZ4kP1wIDAQAB »
)
La prise en charge des enregistrements TXT longs varie selon les fournisseurs DNS. Certaines plateformes exigent que les administrateurs saisissent manuellement plusieurs chaînes entre guillemets, tandis que d’autres divisent et réassemblent automatiquement les valeurs longues. Vérifiez toujours les exigences de formatage des enregistrements DNS de votre fournisseur avant de publier une clé DKIM.
Gardez à l'esprit les points suivants :
| Exigence | Explication |
|---|---|
| Emplacement partagé | La clé peut être divisée en plusieurs parties. Le DNS réassemble automatiquement ces chaînes pour former une seule valeur. |
| Longueur de la chaîne | Aucune chaîne de caractères ne doit dépasser la limite DNS de 255 octets. |
| Validation | Vérifiez l'enregistrement DKIM publié une fois la propagation DNS terminée et assurez-vous que la clé publique complète est renvoyée. |
| Dépannage | Si la signature des e-mails s'effectue correctement mais que les destinataires signalent des échecs de vérification DKIM, vérifiez que la clé publique publiée ne présente pas de problèmes de troncature ou de formatage. |
Après avoir publié une nouvelle clé DKIM, validez l'enregistrement DNS et vérifiez que les serveurs destinataires peuvent récupérer la clé publique dans son intégralité, sans erreur.
Quand et comment renouveler les clés DKIM
La rotation des clés DKIM réduit le risque lié à l'exposition prolongée des clés et constitue une exigence courante dans les programmes de sécurité et de conformité. Bien qu'aucun calendrier de rotation universel ne soit défini par la norme DKIM, de nombreuses organisations procèdent à la rotation de leurs clés de signature tous les 6 à 12 mois dans le cadre de leurs opérations de maintenance de sécurité courantes.
Un processus de rotation DKIM sécurisé consiste à introduire un nouveau sélecteur avant de retirer celui qui est en place. Cela garantit une validation DKIM ininterrompue tout au long de la transition.
- Étape 1 : Générez une nouvelle paire de clés DKIM et attribuez-lui un nouveau sélecteur. De nombreuses organisations utilisent des noms de sélecteurs basés sur la date afin de simplifier le suivi et l'audit.
- Étape 2 : Publiez la nouvelle clé publique dans le DNS sous le nouveau sélecteur. Si vous utilisez une clé RSA de 2048 bits, assurez-vous que l'enregistrement DNS est correctement publié.
- Étape 3 : Attendez que la propagation DNS s'effectue en fonction du TTL de l'enregistrement.
- Étape 4 : Mettez à jour le serveur de messagerie ou le fournisseur de services de messagerie électronique afin qu'il signe les messages avec le nouveau sélecteur.
- Étape 5 : Laissez le sélecteur précédent actif jusqu'à ce que les messages signés avec l'ancienne clé aient parcouru les voies de distribution normales et que les caches DNS aient expiré.
- Étape 6 : Supprimez l'ancien sélecteur et l'enregistrement DNS associé dès qu'il n'est plus utilisé.
Cette approche permet aux deux sélecteurs de coexister pendant la période de transition, ce qui évite les échecs de vérification DKIM dus aux délais de propagation DNS ou aux enregistrements mis en cache.
Les organisations qui gèrent plusieurs domaines, sélecteurs ou services de messagerie peuvent avoir du mal à assurer une rotation manuelle de manière cohérente.
Exigences relatives à la longueur des clés DKIM selon les plateformes et les cadres de conformité
Les exigences relatives à la longueur des clés DKIM varient selon les fournisseurs de messagerie, les normes de sécurité et les cadres de conformité. Alors que certains cadres définissent des exigences cryptographiques explicites, d'autres s'alignent sur des recommandations et des bonnes pratiques plus générales du secteur.
Conformité et exigences applicables aux prestataires
| Cadre / Fournisseur | Exigence relative à la longueur de la clé DKIM |
|---|---|
| Conditions d'utilisation de Google pour les expéditeurs en masse | 1 024 bits au minimum ; 2 048 bits recommandés |
| Conditions requises pour les expéditeurs Yahoo | Conforme, dans l'ensemble, aux exigences de Google relatives aux expéditeurs |
| NIST SP 800-131A, 2e édition | Les clés RSA de moins de 2048 bits ne sont pas autorisées pour la génération de signatures numériques |
| Environnements soumis à la réglementation HIPAA | En règle générale, il convient de suivre les recommandations cryptographiques du NIST, ce qui fait du RSA à 2048 bits le minimum pratique. |
| Environnements FedRAMP | Se conformer aux normes cryptographiques du NIST et aux longueurs de clé approuvées |
| Environnements PCI DSS | Il n'y a pas d'exigence spécifique concernant la longueur des clés DKIM, mais les organisations suivent généralement les pratiques cryptographiques conformes aux recommandations du NIST. |
Prise en charge des plateformes et paramètres par défaut
| Plate-forme | Considérations relatives à la longueur des clés DKIM |
|---|---|
| cPanel | Dans certaines configurations, le système déploie généralement par défaut des clés DKIM de 1 024 bits. Vérifiez la longueur de la clé publiée avant de considérer que la conformité est respectée. |
| Microsoft Exchange 2013/2016 | La prise en charge de la longueur des clés et les valeurs par défaut peuvent varier en fonction de la méthode de déploiement et de la mise en œuvre de DKIM. |
| Espace de travail Google | Prend en charge nativement les clés DKIM de 2 048 bits. |
| Microsoft 365 | Prend en charge nativement les clés DKIM de 2 048 bits. |
| Plateformes modernes de messagerie électronique dans le cloud | Prend généralement en charge le déploiement de DKIM à 2 048 bits sans nécessiter de configuration supplémentaire. |
Que ce soit chez les principaux fournisseurs de messagerie, dans les infrastructures de sécurité ou dans les environnements d'entreprise, la longueur de clé RSA de 2 048 bits reste celle recommandée pour le protocole DKIM. Elle répond aux recommandations de sécurité actuelles, aux exigences de compatibilité générales et aux attentes en matière de conformité, tout en évitant les difficultés de déploiement associées aux clés RSA plus longues.
Comment générer une clé DKIM de 2048 bits
La génération d'une paire de clés DKIM de 2048 bits peut s'effectuer à l'aide d'un outil de génération de clés DKIM ou directement depuis la ligne de commande.
Méthode 1 : Utiliser un générateur de clés DKIM
Le générateur DKIM de PowerDMARC crée une paire de clés DKIM de 2 048 bits et fournit la clé publique dans un format compatible avec le DNS, ainsi que la clé privée correspondante, pour votre serveur de messagerie ou votre plateforme de messagerie.
Méthode 2 : Générer une paire de clés avec OpenSSL
# Générer une clé privée de 2048 bits
openssl genrsa -out dkim_private.key 2048
# Extraire la clé publique correspondante
openssl rsa -in dkim_private.key -pubout -out dkim_public.key
Une fois la paire de clés générée, respectez les bonnes pratiques suivantes :
| Recommandation | Détails |
|---|---|
| Utilisez un sélecteur descriptif | Les sélecteurs basés sur la date, tels que 20260101 ou jan2026, simplifient la gestion des clés et le suivi de leur rotation. |
| Protéger la clé privée | Conservez la clé privée uniquement sur le système chargé de la signature DKIM. Elle ne doit en aucun cas être publiée dans le DNS ni partagée publiquement. |
| Publier la clé publique dans le DNS | Ajoutez la clé publique à l'enregistrement TXT « selector._domainkey » correspondant. |
| Vérifier le formatage DNS | Si vous utilisez une clé RSA de 2048 bits, assurez-vous que la clé publique est correctement publiée et qu'elle respecte les limites de longueur des enregistrements TXT du DNS. |
| Tester avant le déploiement | Vérifiez que l'enregistrement DKIM est accessible au public et que les messages signés avec le nouveau sélecteur passent la validation DKIM. |
Une fois la clé publiée et la propagation DNS terminée, mettez à jour votre plateforme de messagerie afin de commencer à signer les messages avec le nouveau sélecteur.
Gérer correctement la longueur des clés DKIM en 2026
Une clé de 2 048 bits correctement générée, publiée et mise à jour offre une protection renforcée contre la falsification sans entraîner de problèmes de délivrabilité. En revanche, une clé mal publiée peut compromettre la vérification DKIM, quelle que soit sa robustesse cryptographique.
Avant d'effectuer toute modification, vérifiez votre déploiement DKIM actuel. Si vous utilisez encore une clé de 1 024 bits, prévoyez une migration contrôlée vers une clé RSA de 2 048 bits. Si vous utilisez déjà une clé de 2 048 bits, vérifiez la configuration de vos enregistrements DNS, mettez en place un processus de rotation des clés et surveillez régulièrement vos résultats d'authentification.
Une authentification solide des e-mails ne se résume pas au choix d'une longueur de clé appropriée. Elle repose sur une gestion correcte de l'ensemble du cycle de vie DKIM, depuis la génération des clés et leur publication dans le DNS jusqu'à leur rotation et leur validation continue.
FAQ
Google exigera-t-il l'utilisation du protocole DKIM à 2048 bits en 2026 ?
Les règles de Google relatives aux expéditeurs en masse acceptent une longueur minimale de 1 024 bits, mais recommandent vivement d'utiliser 2 048 bits. Étant donné que le NIST interdit l'utilisation du RSA à 1 024 bits pour la génération de signatures numériques, la longueur de 2 048 bits constitue la norme de fait, quelle que soit la restriction imposée par Google.
Que se passe-t-il si j'utilise une clé DKIM de 1 024 bits ?
Vos e-mails continueront d'être authentifiés par les destinataires qui acceptent les clés de 1 024 bits, y compris Gmail. Cependant, cette longueur est inférieure au minimum de 2 048 bits fixé par le NIST ; elle risque donc de ne pas satisfaire aux audits de conformité et peut être piratée par des attaquants disposant de ressources suffisantes.
Comment diviser une clé DKIM de 2048 bits dans le DNS ?
Une clé publique de 2048 bits (environ 392 caractères) dépasse la limite de 255 octets imposée pour les chaînes TXT ; vous devez donc la diviser en plusieurs chaînes entre guillemets au sein du même enregistrement TXT. Le DNS les concatène automatiquement. Vérifiez la validité à l'aide d'un outil de vérification DKIM après la publication.
Gmail et Outlook prennent-ils en charge le DKIM Ed25519 ?
En 2026, la prise en charge s'améliore, mais reste inégale selon les destinataires et les fournisseurs de services Internet (FAI). Ne vous contentez pas de signer uniquement avec Ed25519. Optez pour une double signature avec RSA-2048 et Ed25519, afin que les destinataires qui ne prennent pas en charge Ed25519 puissent se rabattre sur RSA.
À quelle fréquence faut-il renouveler les clés DKIM ?
La meilleure pratique généralement recommandée est de procéder tous les 6 à 12 mois. Utilisez une méthode de sélection parallèle afin que l'ancienne clé reste valide jusqu'à ce que la nouvelle soit diffusée, ce qui permet de garantir la signature des e-mails tout au long de la transition.
Spécialiste du contenu chez PowerDMARC
Milena est une rédactrice et créatrice de contenu qualifiée qui possède plus de 7 ans d'expérience dans la création de contenu attrayant sur les technologies de l'information, la cybersécurité, les événements virtuels, etc. Elle est diplômée d'institutions prestigieuses telles que la New York University Abu Dhabi, l'UWC China et le Collège d'Europe.
Derniers messages de Milena Baghdasaryan (voir tous)
- Longueur de clé DKIM : comment choisir entre 1 024, 2 048 et 4 096 - 9 juillet 2026
- Qu'est-ce que ClickFix (et FileFix) ? - 8 juillet 2026
- Comment choisir un fournisseur de messagerie électronique : un cadre d'évaluation axé sur la sécurité - 1er juillet 2026
