2026-08-11 · RECHERCHE · L'équipe Offensive Technology

SMTP TLS Downgrade : l'écart de 92% derrière DMARC

Une attaque SMTP TLS downgrade retire le chiffrement de l'email pendant son transit, et la plupart des domaines ne peuvent pas l'empêcher. Le chiffrement SMTP classique est opportuniste : les serveurs proposent STARTTLS, mais si un attaquant positionné sur le chemin réseau retire cette offre, le serveur émetteur retombe silencieusement en clair au lieu de refuser. Les seuls enregistrements qui rendent TLS obligatoire sont MTA-STS et DANE. Nous avons résolu le DNS public du top 25 000 Tranco et lu ces enregistrements pour les 18 012 domaines qui reçoivent du courrier. Le résultat est un écart net. L'authentification est répandue : 79,3% publient DMARC et 55,2% l'appliquent. L'application du chiffrement en transit est rare : seulement 3,3% publient une politique MTA-STS, 3,6% publient un enregistrement DANE, et à peine 6,5% publient l'un ou l'autre. En combinant les deux, l'écart est frappant : parmi les domaines qui appliquent DMARC, 92% ne publient ni MTA-STS ni DANE, donc leur courrier est authentifié contre l'usurpation mais reste rétrogradable en transit.

Ce qu'est réellement une attaque SMTP TLS downgrade

Le SMTP entre serveurs de messagerie commence en clair. Le serveur récepteur annonce ses capacités, et s'il supporte le chiffrement il liste STARTTLS parmi elles. Le serveur émetteur émet alors STARTTLS et les deux négocient une session TLS. La faiblesse est dans le mot opportuniste. Si la capacité STARTTLS n'est pas annoncée, ou si la négociation TLS échoue, ou si le certificat ne se valide pas, le comportement par défaut historique n'est pas d'abandonner. C'est d'envoyer le courrier en clair quand même, sur le principe que délivrer le message compte plus que le chiffrer.

Ce comportement par défaut est ce qu'un attaquant exploite. Un adversaire positionné sur le chemin réseau, un opérateur chez un fournisseur de transit, quelqu'un qui a compromis un routeur, un acteur étatique à une frontière, observe l'échange en clair d'ouverture et supprime la ligne STARTTLS de la liste de capacités du récepteur avant qu'elle n'atteigne l'émetteur. L'émetteur, ne voyant aucune offre de chiffrement, livre en clair. C'est le STARTTLS stripping, et c'est un downgrade plutôt qu'une rupture : rien n'est cassé, le protocole est simplement redirigé vers son repli non chiffré. Le message, ses pièces jointes, et tout contenu de réinitialisation de mot de passe ou de facture circulent en clair sur le fil. La communauté opérationnelle APNIC a une description claire du mécanisme (SMTP downgrade attacks and MTA-STS) si vous voulez la vue au niveau des paquets.

Deux standards ferment ce repli. MTA-STS (RFC 8461) permet à un domaine de publier une politique qui dit, en substance, "pour mon courrier entrant, TLS avec un certificat valide est requis, ne repliez pas." Un émetteur qui a récupéré et mis en cache cette politique refusera une connexion strippée plutôt que de rétrograder. DANE pour SMTP (RFC 7672) accomplit la même tâche en publiant un enregistrement TLSA dans le DNS, authentifié par DNSSEC, qui épingle le certificat que le serveur de messagerie doit présenter. L'un ou l'autre transforme un downgrade silencieux en livraison refusée. Aucun des deux n'est activé par défaut, et c'est toute l'histoire des chiffres ci-dessous.

Pourquoi DMARC n'aide pas ici

Cela vaut la peine d'être précis, car les deux problèmes sont constamment confondus. DMARC, SPF et DKIM sont de l'authentification. Ils permettent à un récepteur de décider si l'adresse From visible est légitime, et DMARC indique au récepteur quoi faire quand ce n'est pas le cas. C'est ainsi qu'on empêche quelqu'un de forger votre domaine. Nous avons mesuré cette couche dans un article précédent sur l'écart entre publier et appliquer DMARC, et cela compte. Mais authentification et chiffrement sont orthogonaux. DMARC porte sur qui le message prétend être. Une attaque downgrade porte sur le transport qui achemine le message. Vous pouvez passer chaque contrôle d'authentification haut la main et voir malgré tout la connexion strippée en clair, parce que DMARC n'a jamais eu d'avis sur le transport pour commencer.

Ainsi un domaine à p=reject avec SPF et DKIM parfaitement alignés a résolu l'usurpation et n'a rien fait contre l'interception. Le courrier qui arrive est prouvablement du bon expéditeur et était lisible par quiconque sur le chemin. C'est la confusion que cette mesure vise à corriger : un contrôle DMARC vert n'est pas un cadenas sur l'enveloppe.

Les données : authentifié, pas chiffré

Voici l'état d'adoption sur les 18 012 domaines receveurs de courrier de l'échantillon. La barre d'authentification est haute. Les deux barres qui arrêtent réellement un downgrade sont symboliques.

Les mécanismes de sécurité du transport, détaillés, avec ce que chacun apporte, sont ci-dessous. Lisez les deux dernières lignes ensemble : en additionnant MTA-STS et DANE, seule une petite minorité de domaines de messagerie disposent d'une application quelconque contre un downgrade, et presque aucun n'exécute les deux.

Un détail de ce tableau mérite qu'on s'y arrête. DANE (3,6%) est marginalement plus répandu que MTA-STS (3,3%), ce qui va à l'encontre de l'hypothèse habituelle selon laquelle MTA-STS l'aurait emporté parce qu'il ne nécessite pas DNSSEC. Les deux se chevauchent à peine : seulement 0,3% des domaines de messagerie publient les deux. En pratique ce sont deux camps. Les fournisseurs et zones de code pays qui signent déjà avec DNSSEC penchent vers DANE, tous les autres qui s'en donnent la peine penchent vers MTA-STS, et l'union des deux efforts laisse encore 93,5% des domaines de messagerie sans aucune application.

L'écart de 92%

Le chiffre à retenir est le croisement. Parmi les 9 945 domaines qui appliquent DMARC en quarantine ou reject, 9 192, soit 92%, ne publient ni politique MTA-STS ni enregistrement DANE. Ce ne sont pas des retardataires qui ont ignoré la sécurité email. Ce sont les domaines qui ont fait le travail plus difficile et plus visible de porter DMARC jusqu'à l'application, puis se sont arrêtés une couche trop tôt. Ils ont décidé qu'un expéditeur forgé est inacceptable, ce qui est correct, tout en laissant le message réel lisible en transit pour quiconque est positionné pour stripper la session.

Placez-vous dans le fauteuil de l'attaquant, car c'est ce fauteuil qui décide si un contrôle compte. Supposons que vous vouliez lire ou altérer du courrier circulant vers une cible, pas le forger. Vous cherchez une position sur le chemin et un domaine qui va rétrograder. Vous vérifiez le DNS de la cible de la même façon que nous l'avons fait. Si le domaine publie une politique MTA-STS en mode enforce, ou un enregistrement DANE sur une zone signée, un serveur émetteur qui la respecte refusera de vous livrer une session en clair, et votre downgrade échoue chez l'émetteur. Si le domaine ne publie ni l'un ni l'autre, ce qui décrit 92% de l'ensemble appliquant DMARC et 93,5% de tous les domaines de messagerie, le STARTTLS opportuniste est la règle et un strip renvoie du clair. La posture DMARC que vous voyez aussi dans cette recherche DNS ne change rien à ce résultat. Vous n'alliez jamais forger l'expéditeur. Vous alliez lire le courrier.

Ce qui rend ce chiffre digne d'être cité, c'est la façon dont il a été produit. C'est une mesure passive indépendante, pas de la télémétrie fournisseur. Nous n'avons pas rendu compte de courrier filtré par un de nos produits, et nous n'avons pas extrapolé à partir du flux entrant d'un seul fournisseur. Nous avons lu les enregistrements de politique publics que chaque serveur émetteur sur internet lit, pour un échantillon fixe à une date fixe. Des enquêtes d'adoption antérieures arrivent à la même conclusion depuis d'autres points de vue : des trackers indépendants comme l'enquête MTA-STS d'URIports situent l'adoption dans les chiffres uniques bas et en hausse lente, ce qui concorde avec ce que nous observons dans le DNS brut.

Comment vérifier et corriger votre propre domaine

Vous n'avez besoin ni d'outil ni d'inscription. Une requête DNS est une lecture passive d'enregistrements déjà publics, donc vous pouvez les exécuter contre votre propre domaine dès maintenant.

• Vérifier MTA-STS. Exécutez dig TXT _mta-sts.yourdomain.com +short. Un enregistrement commençant par v=STSv1 signifie que vous annoncez une politique. S'il est vide, vous n'avez pas de MTA-STS. Notez que l'enregistrement pointe seulement vers une politique ; le fichier de politique à https://mta-sts.yourdomain.com/.well-known/mta-sts.txt doit indiquer mode: enforce pour réellement bloquer, pas mode: testing.
• Vérifier DANE. Trouvez d'abord vos serveurs de messagerie avec dig MX yourdomain.com +short, puis pour chaque hôte MX exécutez dig TLSA _25._tcp.that-mx-host +short. Un enregistrement TLSA signifie que DANE est en jeu. DANE ne se valide que sur une zone signée DNSSEC, donc confirmez la signature avec dig DS yourdomain.com +short.
• Activer les rapports. Publiez un enregistrement TLS-RPT (RFC 8460) à _smtp._tls.yourdomain.com afin que les négociations échouées ou les downgrades vous soient signalés au lieu de rester invisibles. Cela ne bloque rien, mais c'est ainsi que vous découvrez qu'un downgrade se produit.

Si les recherches MTA-STS et TLSA reviennent toutes deux vides, votre courrier entrant est protégé contre l'usurpation et exposé à l'interception. La correction consiste à publier une politique MTA-STS en mode enforce, ou un enregistrement DANE TLSA sur une zone signée, ou les deux. Faire l'un ou l'autre vous place dans la petite minorité. Le jugement nécessaire pour en déployer un sans casser la livraison légitime est le même jugement que celui qui sait lesquels de vos autres contrôles exposés comptent réellement, ce qui est tout l'intérêt de lire une surface comme le ferait un attaquant plutôt que de faire confiance aux coches vertes.

Ce que cela ne prouve pas

Des limites honnêtes, parce qu'un chiffre sans ses réserves est du marketing.

• Tranco classe par popularité agrégée, pas par trafic. La liste Tranco combine plusieurs classements de fournisseurs pour être stable et difficile à manipuler, mais ce n'est pas un recensement de trafic. Lisez ces chiffres comme une tranche honnête du web populaire, pas l'internet entier.
• MTA-STS est mesuré au signal DNS. Nous avons compté un domaine comme ayant MTA-STS s'il publie l'enregistrement _mta-sts. Nous n'avons délibérément pas récupéré le fichier de politique, ce qui impliquerait de contacter l'hébergeur web du domaine, donc nous ne pouvons pas distinguer mode: enforce de mode: testing. La part réellement en application est donc à ou en dessous de 3,3%, ce qui élargit l'écart, pas ne le réduit.
• DANE est mesuré par la présence de TLSA. Nous avons vérifié la présence d'un enregistrement TLSA sur les hôtes MX, jusqu'à cinq par domaine. Un enregistrement publié signale une intention et une configuration ; nous n'avons pas vérifié la chaîne DNSSEC ni que chaque émetteur la valide, donc traitez 3,6% comme le plafond du DANE réellement fonctionnel.
• C'est un instantané. Le DNS change quotidiennement. Ces chiffres décrivent le 11 août 2026, pas une tendance, même s'ils concordent avec des enquêtes indépendantes montrant une adoption faible et en hausse lente.
• L'application en transit dépend encore de l'émetteur. MTA-STS et DANE n'aident que lorsque le serveur émetteur les honore. Un éditeur fait ce qu'il faut en annonçant la politique ; un émetteur qui l'ignore peut toujours rétrograder. Les enregistrements sont nécessaires, pas suffisants en eux-mêmes.

Questions fréquentes

Qu'est-ce qu'une attaque STARTTLS downgrade ?

C'est le cas où un attaquant sur le chemin réseau entre deux serveurs de messagerie retire l'offre du serveur de basculer vers TLS dès le début en clair de la session SMTP. Comme le STARTTLS opportuniste retombe en clair quand aucun TLS n'est proposé, l'émetteur livre alors le courrier non chiffré et l'attaquant peut le lire ou l'altérer. MTA-STS et DANE ferment ce repli en indiquant à l'émetteur que TLS est requis.

Le SMTP est-il chiffré en transit par défaut ?

Pas de façon fiable. La plupart des serveurs proposent STARTTLS, mais le TLS SMTP classique est opportuniste : si l'offre est absente ou si le certificat échoue à se valider, l'émetteur retombe silencieusement en clair. Le chiffrement a lieu quand rien n'interfère, mais un attaquant actif peut le stripper. Seulement 6,5% des domaines de messagerie que nous avons mesurés rendent TLS obligatoire avec MTA-STS ou DANE.

DMARC chiffre-t-il l'email en transit ?

Non. DMARC, avec SPF et DKIM, authentifie l'expéditeur afin qu'un récepteur puisse repérer une adresse From forgée. Il ne dit rien sur si la connexion est chiffrée. Un domaine peut appliquer DMARC à p=reject et voir malgré tout son courrier livré en clair après un downgrade. Dans notre échantillon, 92% des domaines appliquant DMARC ne publiaient ni MTA-STS ni DANE.

MTA-STS empêche-t-il les attaques TLS downgrade ?

Oui, c'est son rôle. MTA-STS publie une politique indiquant aux serveurs émetteurs que votre domaine requiert TLS avec un certificat valide, donc un émetteur qui a mis en cache la politique refuse une connexion strippée plutôt que de rétrograder. Sa seule limite est le trust-on-first-use : un émetteur qui n'a jamais récupéré votre politique n'est pas encore couvert, ce pour quoi DANE, ancré dans DNSSEC, est plus robuste.

Quelle est la différence entre MTA-STS et DANE ?

Les deux forcent TLS sur le SMTP entrant mais ancrent la confiance différemment. MTA-STS s'appuie sur le système de certificats web plus le trust-on-first-use et ne nécessite pas DNSSEC. DANE publie un enregistrement TLSA authentifié par DNSSEC, ce qui supprime la faille du premier usage mais nécessite une zone signée. Dans notre recensement ils étaient adoptés à un taux presque identique et bas, 3,3% et 3,6%, et seulement 0,3% des domaines de messagerie publiaient les deux.

Quel pourcentage de domaines a déployé MTA-STS ?

Dans notre recensement d'août 2026 du top 25 000 Tranco, sur les 18 012 domaines recevant du courrier, 3,3% publiaient un enregistrement MTA-STS. DANE était à 3,6% et TLS-RPT à 3,9%. En comptant l'un ou l'autre contrôle d'application, 6,5% requièrent TLS en transit, contre 79,3% qui publient DMARC.

Comment vérifier si mon propre domaine résiste à un downgrade SMTP ?

Exécutez dig TXT _mta-sts.yourdomain.com +short et cherchez v=STSv1, et dig TLSA _25._tcp.your-mx-host +short pour chaque hôte MX. Si les deux sont vides, votre courrier entrant repose sur du STARTTLS opportuniste et peut être rétrogradé. Publier une politique MTA-STS en mode enforce, ou un enregistrement DANE sur une zone signée, ferme cet écart.

Lectures associées

• p=none suffit-il ? Publier DMARC n'est pas la même chose que l'appliquer. La couche d'authentification à laquelle cet article se rattache.
• Quelle est l'exposition des domaines les plus fréquentés du monde à l'usurpation d'email ? La question de présence pour le volet anti-usurpation.
• Combien de domaines majeurs restreignent qui peut émettre leurs certificats ? La même méthode DNS passive, appliquée aux enregistrements CAA.