MTA-STS, c'est quoi et à quoi ça sert

Comment déployer MTA-STS

Le déploiement comporte trois éléments :

1. L'enregistrement DNS. Un TXT à publier sur _mta-sts.exemple.fr, contenant un identifiant de version de la politique (v=STSv1; id=...). Cet identifiant change à chaque mise à jour de la politique, pour signaler aux expéditeurs qu'ils doivent la re-télécharger.

2. Le fichier de politique. Hébergé en HTTPS sur https://mta-sts.exemple.fr/.well-known/mta-sts.txt, il précise le mode d'application (testing, enforce) et la liste des serveurs MX autorisés à recevoir en TLS le courrier du domaine.

3. Le mode de démarrage : testing avant enforce. Exactement comme pour DMARC, la bonne pratique est de commencer en mode testing, qui journalise les échecs de connexion TLS sans bloquer la livraison, avant de passer en enforce une fois la configuration validée. C'est là qu'intervient le protocole complémentaire décrit plus bas.

TLS-RPT : le retour d'expérience de MTA-STS

MTA-STS seul dit quoi exiger, mais pas ce qui se passe réellement côté expéditeurs qui tentent de joindre le domaine. C'est le rôle de TLS-RPT (SMTP TLS Reporting), un protocole compagnon qui fait pour MTA-STS ce que les rapports agrégés font pour DMARC : il renvoie des rapports quotidiens détaillant les succès et les échecs de connexion TLS observés par les expéditeurs qui écrivent au domaine. Sans TLS-RPT, passer MTA-STS en enforce revient à durcir une politique DMARC sans jamais lire les rapports — un pari à l'aveugle, où le blocage d'un expéditeur légitime faute de TLS resterait à jamais invisible. Le protocole est détaillé dans TLS-RPT expliqué ; les deux se déploient presque toujours ensemble.

Le parallèle avec DMARC

La ressemblance méthodologique avec DMARC n'est pas un hasard — les deux protocoles répondent au même problème structurel (un mécanisme de sécurité optionnel, contournable silencieusement) avec la même solution (publier une politique explicite, et une boucle de rapports pour la valider avant de durcir). Pour qui a déjà mené un déploiement DMARC via la séquence none → quarantine → reject, la séquence testing → enforce de MTA-STS, accompagnée de TLS-RPT, n'a rien de dépaysant. Le principe de prudence est identique : la bascule en application stricte n'intervient qu'une fois les rapports démontrés propres.

MTA-STS protège-t-il contre l'usurpation ?

Non, et c'est une confusion fréquente à dissiper. MTA-STS protège le transport — la confidentialité et l'intégrité du message pendant son trajet entre serveurs. Il ne dit rien sur l'identité de l'expéditeur, qui reste entièrement du ressort de SPF, DKIM et DMARC. Un message parfaitement chiffré en transit peut très bien être un email usurpé ; un message parfaitement authentifié peut très bien avoir voyagé en clair. Les deux couches sont complémentaires, pas substituables — un déploiement email sérieux en 2026 couvre les deux, pas l'une au détriment de l'autre, car traiter MTA-STS comme un remplacement de DMARC (ou l'inverse) revient à confondre le contenant et le contenu.

Qui bénéficie le plus de MTA-STS

Le protocole a une valeur particulièrement élevée pour les organisations qui échangent des informations sensibles par email : secteur financier, santé, juridique, administrations. Une rétrogradation TLS exploitée sur ce type de trafic expose des données dont la confidentialité est souvent une obligation réglementaire, pas seulement une bonne pratique — relevés bancaires, dossiers médicaux ou pièces de procédure échangés par email, autant de cas où une interception en clair constitue potentiellement un incident à déclarer. Le sujet croise directement les enjeux de conformité qui touchent les secteurs les plus réglementés — voir DMARC pour les banques pour un exemple de secteur où ce type d'exigence de transport chiffré s'ajoute naturellement aux obligations d'authentification. Une entreprise qui doit démontrer sa diligence en matière de protection des données email a tout intérêt à documenter MTA-STS au même titre que DMARC dans son dossier de conformité, plutôt que de le traiter comme un détail purement technique sans valeur probante.

Le rôle du fichier de politique servi en HTTPS

Un détail architectural mérite d'être expliqué, car il révèle pourquoi MTA-STS est plus robuste que STARTTLS seul. Le fichier de politique n'est pas stocké dans le DNS lui-même (contrairement à DMARC ou SPF) — il est hébergé en HTTPS, sur un sous-domaine dédié mta-sts.exemple.fr. Pourquoi cette architecture en deux temps, un enregistrement DNS et un fichier web ?

La réponse tient à la taille et à la nature de l'information. Un enregistrement DNS TXT est limité en taille et peu adapté à contenir une liste de serveurs MX et des règles de mode. En revanche, un enregistrement DNS léger (juste un identifiant de version) couplé à un fichier HTTPS complet (protégé par les certificats TLS standards du web, eux-mêmes vérifiés) donne le meilleur des deux mondes : une notification légère et rapide à consulter dans le DNS, et un contenu détaillé protégé par l'infrastructure de confiance HTTPS existante. Un attaquant qui voudrait falsifier la politique devrait donc compromettre à la fois le DNS et obtenir un certificat TLS valide pour le sous-domaine — une barrière bien plus haute qu'un enregistrement DNS seul.

La mise en cache côté expéditeur

Autre mécanisme à connaître : les expéditeurs qui respectent MTA-STS ne re-téléchargent pas le fichier de politique à chaque email envoyé — ils le mettent en cache, généralement pour une durée définie dans le fichier lui-même (souvent plusieurs jours). C'est pour cette raison que l'identifiant de version (id=) dans l'enregistrement DNS est essentiel : c'est le signal qui indique à un expéditeur en cache qu'une nouvelle version existe et doit être re-téléchargée. Que la politique change (l'ajout d'un nouveau serveur MX, par exemple) sans que cet identifiant bouge, et certains expéditeurs continueront d'appliquer l'ancienne version pendant toute la durée de leur cache — un piège classique lors d'une migration d'infrastructure mail.

Maintenir le point de publication en vie

Déployer MTA-STS crée aussi une dépendance opérationnelle qu'on oublie facilement : le point HTTPS qui sert le fichier de politique doit rester en ligne, et son certificat TLS valide. Contrairement à un enregistrement DNS, qui dort tranquillement une fois publié, un point web peut pourrir — un certificat qui expire sans que personne ne s'en aperçoive, un serveur décommissionné lors d'une migration, une redirection ajoutée sans savoir que l'URL de politique doit répondre directement. Quand la politique ne peut plus être téléchargée, les expéditeurs qui en détiennent une copie en cache continuent de l'appliquer jusqu'à expiration, et les nouveaux ne peuvent tout simplement plus découvrir les exigences du domaine — une érosion silencieuse de la protection, plutôt qu'une panne visible. Le remède est procédural, pas technique : l'hôte de politique doit passer sous la même supervision de renouvellement de certificat et de disponibilité que n'importe quel service de production.

Limites à connaître

MTA-STS ne protège que le trajet entre serveurs de messagerie (le tronçon SMTP serveur-à-serveur) ; il ne couvre pas la connexion entre un client mail et son propre serveur d'envoi (généralement déjà chiffrée par d'autres moyens), ni le contenu une fois stocké dans une boîte de réception. C'est une protection ciblée sur un maillon précis de la chaîne — précieuse, mais pas une solution de chiffrement de bout en bout. Pour ce niveau de garantie, il faudrait des mécanismes distincts comme S/MIME ou PGP, qui chiffrent le contenu lui-même plutôt que le seul transport entre serveurs.

En résumé

MTA-STS ferme une faille structurelle de SMTP — la rétrogradation silencieuse vers du texte clair — en remplaçant une négociation optionnelle par une politique publiée et vérifiable. Associé à TLS-RPT pour la visibilité, et déployé avec la même prudence méthodologique qu'un déploiement DMARC (testing avant enforce), c'est une couche de sécurité qui complète, sans la remplacer, l'authentification apportée par SPF, DKIM et DMARC.

Pour vérifier l'état de l'authentification email de base avant d'ajouter cette couche de transport, un passage du domaine dans l'analyseur DMARC gratuit suffit — l'identité d'abord, le chiffrement du trajet ensuite, dans cet ordre de priorité. Une fois la politique de transport publiée, l'analyseur MTA-STS gratuit en confirme le mode et la bonne récupération.