Radar DNS : retour à l'outil

MTA-STS, DANE et TLS-RPT expliqués

Dernière mise à jour : 4 novembre 2026

SPF, DKIM et DMARC répondent tous à la même question : ce message vient-il bien de qui il prétend ? Aucun ne s'occupe de savoir si son contenu peut être lu en chemin.

C'est l'angle mort que MTA-STS, DANE et TLS-RPT viennent couvrir. Ils sont beaucoup moins connus, mal documentés en français, et pourtant ils règlent un problème réel.

Le problème : un chiffrement qu'on peut désactiver

Quand un serveur de messagerie en contacte un autre, il commence en clair, puis demande à passer en chiffré via la commande STARTTLS. Si le serveur d'en face répond qu'il sait faire, la suite est chiffrée.

La faille tient en une phrase : cette négociation se fait en clair. Un intermédiaire en position d'écoute peut supprimer la réponse annonçant le support de STARTTLS. Les deux serveurs concluent alors que le chiffrement n'est pas disponible et poursuivent en clair, sans la moindre alerte. C'est une attaque par rétrogradation.

Pire : par défaut, SMTP utilise un chiffrement dit opportuniste, et un serveur qui ne valide pas le certificat d'en face accepte n'importe quel interlocuteur. Un attaquant peut donc se présenter comme votre serveur.

MTA-STS et DANE résolvent cela de deux manières différentes.

MTA-STS : une politique publiée en HTTPS

MTA-STS permet d'annoncer : « mes serveurs acceptent TLS, exigez-le, et refusez la connexion s'il n'est pas disponible ».

Le dispositif comporte deux parties. D'abord un enregistrement DNS qui signale l'existence d'une politique :

_mta-sts.exemple.fr.  TXT  "v=STSv1; id=20261104120000"

Ensuite la politique elle-même, servie en HTTPS à l'adresse https://mta-sts.exemple.fr/.well-known/mta-sts.txt :

version: STSv1
        mode: enforce
        mx: mx1.exemple.fr
        mx: mx2.exemple.fr
        max_age: 604800

Le serveur expéditeur récupère cette politique, la met en cache pour la durée indiquée, et refusera désormais toute connexion non chiffrée vers vos serveurs.

Le mode accepte trois valeurs : testing pour observer sans rien bloquer, enforce pour appliquer, none pour désactiver. Commencez toujours par testing.

Sa force : il repose sur HTTPS, donc sur les autorités de certification habituelles. Aucun prérequis DNS particulier, ce qui le rend accessible à tout le monde.

Sa faiblesse : la toute première récupération de la politique reste vulnérable, et un attaquant contrôlant le DNS pourrait masquer l'enregistrement. C'est un modèle de confiance à la première utilisation.

DANE : le certificat ancré dans le DNS

DANE prend le problème par l'autre bout. Plutôt que de s'appuyer sur les autorités de certification, il publie directement dans le DNS l'empreinte du certificat attendu, dans un enregistrement TLSA :

_25._tcp.mx1.exemple.fr.  TLSA  3 1 1 a73a9adb16bd5a41...

Un serveur expéditeur qui trouve cet enregistrement sait exactement quel certificat attendre. Toute substitution est détectée.

Le prérequis est absolu : DANE exige DNSSEC. Sans la signature cryptographique de votre zone, un attaquant supprime simplement l'enregistrement TLSA de la réponse DNS, et l'expéditeur conclut qu'il n'y a pas de DANE. La protection disparaît sans laisser de trace.

C'est pour cette raison que Radar DNS vérifie l'état DNSSEC de la réponse en même temps que la présence du TLSA, et signale explicitement un TLSA non signé : il donne une fausse impression de sécurité.

Sa force : pas de dépendance aux autorités de certification, et aucune fenêtre de vulnérabilité initiale.

Sa faiblesse : DNSSEC reste peu déployé, et la rotation des certificats devient délicate, il faut publier le nouveau TLSA avant de changer le certificat, sous peine de couper la réception.

Lequel choisir

Ils ne s'excluent pas, ils se complètent, et les grands opérateurs déploient souvent les deux. En pratique :

MTA-STS est plus simple à déployer mais demande un hébergement HTTPS sur un sous-domaine dédié. DANE ne demande que du DNS, à condition d'avoir DNSSEC.

TLS-RPT : savoir quand ça casse

C'est le troisième élément, et de loin le plus simple à mettre en place :

_smtp._tls.exemple.fr.  TXT  "v=TLSRPTv1; rua=mailto:tls-rapports@exemple.fr"

Un seul enregistrement DNS, aucun fichier à héberger, aucun risque. Les serveurs expéditeurs vous envoient alors un rapport quotidien des échecs de connexion chiffrée vers vos serveurs : certificat expiré, négociation TLS échouée, politique MTA-STS introuvable.

Sans lui, un problème de transport est invisible. Vous ne savez pas que des messages qui vous étaient destinés ont été refusés ou transmis en clair.

C'est par là qu'il faut commencer, avant même MTA-STS : vous obtenez de la visibilité sans rien changer au comportement de vos serveurs.

Et BIMI, dans tout ça

BIMI est souvent cité à côté, mais il ne relève pas du tout de la sécurité du transport. Il permet d'afficher votre logo dans la boîte de réception, via un enregistrement :

default._bimi.exemple.fr.  TXT  "v=BIMI1; l=https://exemple.fr/logo.svg; a=..."

Ce qu'il faut en retenir : BIMI n'est honoré que si votre DMARC est en p=quarantine ou p=reject. Publier un BIMI avec un DMARC en p=none ne produit strictement rien.

C'est sa vertu principale : il transforme le durcissement de DMARC, perçu comme une contrainte, en bénéfice visible pour votre marque.

Un ordre de déploiement raisonnable

  1. TLS-RPT : un enregistrement DNS, aucun risque, de la visibilité immédiate.
  2. MTA-STS en testing : la politique est publiée, rien n'est encore bloqué. Lisez les rapports TLS-RPT.
  3. MTA-STS en enforce : quand les rapports sont propres.
  4. DNSSEC puis DANE : si vous maîtrisez votre zone et acceptez la rigueur que demande la rotation des certificats.
  5. BIMI : une fois DMARC en application, si l'affichage du logo vous intéresse.

Les trois premières étapes ne présentent aucun risque pour la réception de votre courrier. Radar DNS affiche l'état des quatre dans l'onglet Sécurité, en distinguant un enregistrement publié d'une protection réellement effective.

À lire aussi