L'authentification des e-mails évolue, et les clés DKIM Ed25519 promettent des avantages clairs par rapport au RSA traditionnel : des clés plus petites, une vérification plus rapide et des garanties cryptographiques renforcées. Mais ces avantages n'ont d'importance que si les fournisseurs de messagerie prennent réellement en charge cette norme. Pour le savoir, Red Sift a analysé le comportement DKIM sur les principales plateformes de messagerie afin de répondre à des questions essentielles pour les administrateurs de messagerie : les clés Ed25519 peuvent-elles être déployées aujourd'hui en toute sécurité, sans risquer des échecs d'authentification ?
Nous avons également testé la manière dont les fournisseurs gèrent les clés DKIM faibles, y compris les clés RSA de moins de 1024 bits qui devraient être rejetées, afin d'identifier les failles de sécurité critiques encore présentes. Les résultats montrent quels fournisseurs ont adopté la cryptographie moderne, lesquels accusent un retard, et ce que cela implique pour votre stratégie de sécurité des e-mails.
Qu'est-ce qu'Ed25519 ?
Ed25519 est un algorithme de signature moderne basé sur les courbes elliptiques qui offre des avantages convaincants par rapport aux clés RSA traditionnelles pour DKIM. Alors que RSA-2048 utilise des clés de 2048 bits, Ed25519 atteint un niveau de sécurité équivalent ou supérieur avec seulement 256 bits, soit une réduction de 8 fois, particulièrement précieuse pour les enregistrements DNS où l'espace est limité.
La vérification des signatures Ed25519 est également 10 à 20 fois plus rapide que RSA-2048, ce qui réduit la charge de calcul pour les fournisseurs de messagerie traitant de gros volumes d'e-mails. L'algorithme offre environ 128 bits de sécurité (comparable à RSA-3072) et résiste par conception aux attaques temporelles, éliminant ainsi une vulnérabilité courante des implémentations RSA.
Méthodologie de test
Nous avons testé 19 fournisseurs de messagerie majeurs en envoyant des e-mails signés avec cinq configurations de clés DKIM différentes :
- RSA 512 bits (cryptographiquement faible, factorisable en quelques heures)
- RSA 768 bits (faible, factorisable en quelques mois avec des ressources modérées)
- RSA 1536 bits (acceptable, mais non standard)
- RSA 4096 bits (robuste, potentiellement coûteux en calcul)
- Ed25519 (courbe elliptique 256 bits, norme moderne)
Chaque fournisseur a reçu des e-mails de test provenant du domaine dkim.testsift.com avec les sélecteurs DKIM correspondants. Nous avons ensuite examiné les en-têtes Authentication-Results, ou d'autres en-têtes propriétaires du fournisseur, afin de déterminer si les signatures étaient acceptées, rejetées, ou refusées pour des raisons de politique.
Prise en charge d'Ed25519 : l'écart d'adoption
Seuls 9 fournisseurs sur 19 (47 %) valident avec succès les signatures DKIM Ed25519 :
Fournisseurs prenant en charge Ed25519
- Fastmail
- GMX
- HEY
- Hostpoint
- LaPoste (FR)
- MXroute
- Migadu
- Proton Mail
- Soverin
Fournisseurs sans prise en charge d'Ed25519
10 fournisseurs (53 %) échouent à valider les signatures Ed25519, avec des réponses d'erreur variées :
Fournisseur | Réponse d'erreur | Gravité |
Gmail | dkim=neutral (pas de clé) | Élevée – traite la signature comme si la clé n'existait pas |
Microsoft 365 | dkm=fail (erreur de syntaxe de signature) | Élevée – rejette comme malformée |
Yahoo | dkim=perm_fail | Élevée – échec permanent |
iCloud | dkim=permerror (algorithme de clé non pris en charge) | Élevée – échec permanent dû à un algorithme non pris en charge |
Proofpoint Essentials | dkim=invalid | Élevée – rejette comme invalide |
Rackspace | dkim=fail (algorithme de signature invalide) | Élevée – rejet explicite de l'algorithme |
Tuta | dkim=permerror (algorithme inconnu : ed25519-sha256) | Élevée – ne reconnaît pas l'algorithme |
mailbox.org | dkim=neutral (algorithme non pris en charge ed25519-sha256) | Moyenne – reconnaît mais ne prend pas en charge |
MailChannels | dkim=temperror | Moyenne – temperror, mais reproduit sur plusieurs tests |
Le constat le plus préoccupant : Gmail, Microsoft 365, et Yahoo (qui gèrent collectivement la majorité du trafic e-mail mondial) ne prennent pas en charge Ed25519. Cela rend un déploiement à grande échelle d'Ed25519 risqué pour les domaines qui s'appuient sur des politiques DMARC, car un échec de validation DKIM contribue aux échecs DMARC.
Acceptation des clés faibles : le risque de sécurité
Alors que 68 % des fournisseurs rejettent correctement les clés cryptographiquement faibles (RSA 512 bits et 768 bits), 6 fournisseurs les acceptent encore :
Fournisseurs acceptant les clés faibles (risque de sécurité)
- HEY – Accepte les signatures 512 bits et 768 bits
- LaPoste (FR) – Accepte les clés faibles avec le statut « bonne signature »
- Migadu – Aucune validation de la longueur de clé
- Proofpoint Essentials – Valide les signatures faibles
- Soverin – Accepte les signatures quelle que soit la robustesse de la clé
- mailbox.org – Accepte les clés 512 bits et 768 bits
Ces fournisseurs créent une vulnérabilité de sécurité. Une clé RSA 512 bits peut être factorisée en quelques heures avec du matériel grand public, permettant aux attaquants de falsifier des signatures DKIM pour tout domaine utilisant des clés faibles. Même les clés 768 bits sont vulnérables ; elles ont été factorisées publiquement en 2009.
Fournisseurs rejetant correctement les clés faibles
Les 13 fournisseurs suivants rejettent correctement les clés de moins de 1024 bits, appliquant des normes de sécurité minimales :
- Comcast – « clé de signature trop petite »
- Fastmail – « Longueur de clé 512/768 trop courte »
- GMX – Échec explicite sur les clés faibles
- Gmail – « policy (weak key) »
- Hostpoint – « clé publique trop courte »
- Microsoft 365 – « ignored public key size » (traité comme une violation de politique)
- MXroute – « pubkey_too_short »
- MailChannels – Renvoie temperror pour les clés faibles
- Proton Mail – « clé de signature trop petite » avec indication de la longueur en bits
- Rackspace – « clé de signature trop petite »
- Tuta – « la longueur de clé est trop courte »
- Yahoo – perm_fail sur les clés faibles
- iCloud – « clé de signature trop petite » avec motif de politique
L'approche de Gmail est particulièrement notable : il marque explicitement les clés faibles avec un résultat dkim=policy (weak key), rendant le problème de sécurité visible dans les en-têtes tout en continuant à traiter l'e-mail. Cela permet aux administrateurs d'identifier les configurations vulnérables sans impact immédiat sur la livraison.
Certaines plateformes, comme CES de Cisco (anciennement IronPort), disposent d'options configurables pour rejeter ou mettre en quarantaine les messages présentant des clés faibles.
Prise en charge des clés robustes : une compatibilité universelle
Les 19 fournisseurs testés ont tous validé avec succès les clés RSA 1536 bits et 4096 bits sans problème. Cela démontre que les préoccupations concernant les problèmes de compatibilité liés aux clés de plus grande taille sont infondées. Les fournisseurs n'ont aucune difficulté à gérer des clés bien supérieures au minimum de 1024 bits, y compris des tailles non standard comme 1536 bits.
L'acceptation universelle des clés 4096 bits confirme que les organisations peuvent déployer des clés RSA plus robustes sans risquer de problèmes de livraison, bien que la charge de calcul sur les serveurs récepteurs augmente avec la taille de la clé.
Le paradoxe de l'adoption
Seuls 5 fournisseurs appliquent les deux bonnes pratiques : prendre en charge les clés Ed25519 modernes tout en rejetant les clés RSA faibles :
- Fastmail
- GMX
- Hostpoint
- MXroute
- Proton Mail
Cela crée un compromis inconfortable pour les administrateurs de messagerie. Déployer des clés Ed25519 risque de provoquer des échecs d'authentification chez Gmail, Microsoft 365 et Yahoo, les trois plus grands fournisseurs en volume. Pourtant, conserver RSA signifie des enregistrements DNS plus volumineux, une charge de calcul persistante pour les serveurs de messagerie récepteurs, et une compatibilité avec les six fournisseurs qui valideraient même une signature 512 bits triviale et faible.
Implications pour les administrateurs de messagerie
Recommandations à court terme :
- Déployez RSA-2048 pour une compatibilité maximale
- Auditez vos clés DKIM actuelles — si l'une d'elles fait moins de 1024 bits, effectuez immédiatement une rotation et assurez-vous de signer avec au moins 1024 bits, idéalement 2048.
- Surveillez les en-têtes Authentication-Results pour identifier les fournisseurs traitant les clés faibles comme valides
- Pour les passionnés d'e-mail : envisagez la double signature (RSA + Ed25519) si votre infrastructure de messagerie le permet, bien que cela ajoute de la complexité et reste pour l'instant surtout une curiosité.
Perspectives à long terme :
- L'adoption d'Ed25519 progresse mais reste incomplète parmi les fournisseurs de premier plan
- Les taux d'échec DMARC pourraient augmenter si Ed25519 est déployé sans une analyse minutieuse des fournisseurs
- Les six fournisseurs acceptant des clés faibles représentent une vulnérabilité exploitable dans l'écosystème de messagerie
Pour les fournisseurs :
- Le rejet des clés faibles devrait être universel — les clés RSA 512 bits et 768 bits sont cryptographiquement compromises
- La prise en charge d'Ed25519 devrait être priorisée compte tenu de sa standardisation dans la RFC 8463 (publiée en septembre 2018)
- Des messages d'erreur clairs (comme l'indicateur de politique de clé faible de Gmail) aident les administrateurs à identifier et corriger les problèmes
Les fournisseurs de messagerie restent divisés, la voie à suivre nécessite une coordination
Le paysage de l'authentification des e-mails révèle une fracture préoccupante. Alors que près de la moitié des fournisseurs testés prennent en charge les signatures Ed25519 modernes, les trois plus grands fournisseurs, Gmail, Microsoft 365 et Yahoo, ne le font pas, rendant un déploiement généralisé d'Ed25519 prématuré pour la plupart des organisations. Simultanément, six fournisseurs continuent d'accepter des clés cryptographiquement faibles qui auraient dû être rejetées il y a des années, créant une faille exploitable dans la sécurité des e-mails.
Les administrateurs de messagerie font face à un jeu d'attente : Ed25519 offre de réels avantages en matière de sécurité et de performance, mais le déployer aujourd'hui signifie accepter des échecs d'authentification chez les grands fournisseurs. Tant que Gmail, Microsoft et Yahoo n'auront pas implémenté la RFC 8463, RSA-2048 ou RSA-4096 restera le seul choix viable pour une compatibilité universelle. La priorité devrait être d'éliminer les clés faibles de l'écosystème : tout domaine utilisant encore des clés DKIM de moins de 1024 bits est vulnérable à la falsification de signature et devrait effectuer une rotation immédiatement.
La voie à suivre nécessite une action coordonnée : les fournisseurs doivent implémenter la prise en charge d'Ed25519 et imposer des longueurs de clé minimales, tandis que les expéditeurs doivent auditer leurs configurations DKIM et éliminer les clés faibles. Tant que l'adoption d'Ed25519 ne sera pas généralisée, la promesse de la cryptographie moderne des e-mails restera partiellement inaccomplie. Au-delà de cela, le besoin éventuel d'algorithmes de signature post-quantiques se profile, bien que le calendrier et les normes restent incertains : RSA et Ed25519 seront tous deux, à terme, vulnérables aux attaques quantiques.
With exceptional email security knowledge and industry experience, Faisal is hands-on and dedicated CSE for Red Sift.




