MTA-STS — Mail Transfer Agent Strict Transport Security

Voie de normalisation Sécurité du transport Published March 2026

ELI5: Imaginez envoyer une lettre par une boîte aux lettres verrouillée, mais quelqu'un pourrait remplacer le verrou par un faux et lire votre courrier. MTA-STS, c'est comme publier un panneau qui dit « J'utilise toujours le vrai verrou — si le verrou semble faux, ne livrez pas. » Cela empêche les attaquants de tromper les serveurs de messagerie pour envoyer des emails sans chiffrement.

Pourquoi cela existe

SMTP a été conçu à une époque où les e-mails transitaient en texte clair. STARTTLS (RFC 3207) a ajouté un chiffrement optionnel, mais il présente un défaut fatal : il est opportuniste. Un serveur d'envoi demande « supportez-vous TLS ? » et un attaquant actif du réseau peut simplement supprimer cette réponse, forçant une rétrogradation en texte clair. Le serveur d'envoi n'a aucun moyen de distinguer « ce serveur ne supporte pas TLS » de « un attaquant a supprimé l'offre TLS ».

MTA-STS résout ce problème en permettant aux propriétaires de domaines de publier une politique — via HTTPS, et non DNS — qui déclare : « Mes serveurs de courrier supportent toujours TLS avec des certificats valides. Si vous ne pouvez pas établir une connexion sécurisée, refusez de livrer. » Parce que la politique est récupérée via HTTPS (qui dispose de sa propre chaîne de confiance de certificats), un attaquant actif ne peut pas la forger ou la supprimer.

Comment cela fonctionne

MTA-STS exige deux choses du domaine récepteur :

Un enregistrement TXT DNS à _mta-sts.example.com qui signale l'existence de la politique et inclut un identifiant de version pour l'invalidation du cache.
Un fichier de politique servi en HTTPS à https://mta-sts.example.com/.well-known/mta-sts.txt qui déclare la politique réelle.

Étape 1 : Enregistrement DNS

Publiez un enregistrement TXT pour annoncer votre politique MTA-STS :

_mta-sts.example.com. IN TXT "v=STSv1; id=20240101T000000Z"

Le champ id est une chaîne opaque. Les serveurs d'envoi mettent en cache la politique et la récupèrent à nouveau lorsque l'id change. Utilisez un timestamp ou un compteur croissant.

Étape 2 : Fichier de politique

Hébergez la politique à https://mta-sts.example.com/.well-known/mta-sts.txt. Le certificat HTTPS doit être valide pour mta-sts.example.com.

version: STSv1
mode: enforce
mx: mail.example.com
mx: backup.example.com
mx: *.example.net
max_age: 604800

Champs de politique

Champ	Description
`version`	Doit être `STSv1`.
`mode`	`enforce` (rejeter en cas d'échec), `testing` (livrer mais signaler), ou `none` (désactiver).
`mx`	Noms d'hôtes MX autorisés. Les caractères génériques sont autorisés pour l'étiquette la plus à gauche uniquement (par exemple, `*.example.com`).
`max_age`	Durée (en secondes) pendant laquelle les serveurs d'envoi doivent mettre en cache cette politique. Recommandé : 604800 (1 semaine) ou plus.

Ce que fait le serveur d'envoi

Consulte les enregistrements MX pour le domaine du destinataire.
Vérifie une politique MTA-STS mise en cache, ou la récupère si l'enregistrement TXT DNS _mta-sts est nouveau ou modifié.
Se connecte à un hôte MX et initie STARTTLS.
Valide le certificat TLS du serveur MX par rapport aux motifs mx dans la politique.
Si le mode est enforce et que TLS échoue ou que le certificat ne correspond pas : ne pas livrer. Mettez le message en file d'attente et réessayez plus tard.

Détails techniques clés

Pourquoi HTTPS au lieu de DNSSEC ?

Le déploiement de DNSSEC reste limité. HTTPS exploite l'infrastructure PKI Web largement déployée (autorités de certification). Tout domaine pouvant obtenir un certificat web peut utiliser MTA-STS — aucun DNSSEC requis. C'est la différence clé entre MTA-STS et DANE (RFC 7672), qui exige DNSSEC.

Confiance à la première utilisation (TOFU)

MTA-STS suit un modèle TOFU. La première fois qu'un serveur d'envoi rencontre votre politique, il doit faire confiance aux réponses DNS et HTTPS. Après cela, la politique mise en cache protège contre les rétrograadations jusqu'à l'expiration de max_age. Un attaquant devrait compromettre simultanément HTTPS et DNS pendant la récupération initiale — une attaque considérablement plus difficile.

Mode de test

Commencez par mode: testing. Dans ce mode, les serveurs d'envoi livrent le courrier même si la validation TLS échoue, mais génèrent des rapports TLS-RPT (RFC 8460) pour que vous puissiez identifier les problèmes avant de passer à enforce.

Exemple de déploiement

Une configuration MTA-STS complète pour example.com :

Enregistrements DNS

; Signal de politique MTA-STS _mta-sts.example.com. 300 IN TXT "v=STSv1; id=2024061501" ; Point de terminaison de rapport TLS (RFC 8460) _smtp._tls.example.com. 300 IN TXT "v=TLSRPTv1; rua=mailto:tls-reports@example.com" ; Enregistrements MX (doivent correspondre aux lignes de politique mx:) example.com. 300 IN MX 10 mail.example.com. example.com. 300 IN MX 20 backup.example.com.

Fichier de politique

# Servi à https://mta-sts.example.com/.well-known/mta-sts.txt
version: STSv1
mode: testing
mx: mail.example.com
mx: backup.example.com
max_age: 86400

Une fois que les rapports TLS-RPT confirment l'absence de problèmes, changez mode en enforce et augmentez max_age à 604800 ou plus.

Erreurs courantes

Incompatibilité de certificat. Le nom d'hôte MX dans votre politique doit correspondre au certificat TLS sur ce serveur. Si votre MX est mail.example.com mais le certificat est pour *.mailprovider.com, l'application entraînera des échecs de livraison.
Oublier de mettre à jour l'id DNS. Les serveurs d'envoi mettent en cache la politique en fonction de l'id. Si vous modifiez le fichier de politique mais pas l'id, les serveurs d'envoi ne la récupéreront pas à nouveau jusqu'à l'expiration de max_age.
Certificat HTTPS invalide sur mta-sts.example.com. Le site d'hébergement de la politique doit avoir un certificat valide approuvé publiquement. Les certificats auto-signés ou expirés feront que les serveurs d'envoi ignoreront la politique.
Passer directement à enforce. Commencez toujours par testing et surveillez les rapports TLS-RPT pendant au moins deux semaines. Les serveurs MX mal configurés perdront silencieusement le courrier en mode enforce.
max_age court en mode enforce. Une TTL courte signifie que les serveurs d'envoi récupèrent fréquemment, élargissant la fenêtre TOFU. Utilisez au moins 604800 secondes (1 semaine) en production.
Mauvaise utilisation du caractère générique MX. mx: * n'est pas valide. Les caractères génériques s'appliquent à l'étiquette DNS la plus à gauche uniquement : mx: *.example.com correspond à a.example.com mais pas à a.b.example.com.

Impact sur la livrabilité

MTA-STS n'améliore pas directement le placement en boîte de réception — il protège le courrier de vos destinataires de l'interception. Cependant, il présente des avantages indirects en matière de livrabilité :

Renforce la confiance du domaine. Google, Microsoft et Yahoo supportent tous MTA-STS. Publier une politique signale que vous prenez la sécurité au sérieux et que vous gérez bien votre domaine.
Obligatoire pour la conformité. Les secteurs traitant des données sensibles (finance, santé) exigent de plus en plus l'application de TLS pour les e-mails. MTA-STS est le mécanisme standard.
Empêche les rétrograadations silencieuses. Sans MTA-STS, un attaquant sur le chemin du réseau peut supprimer STARTTLS et intercepter le courrier sans que l'une ou l'autre partie le sache. C'est une attaque documentée dans le monde réel.
S'associe à TLS-RPT. Les rapports RFC 8460 vous donnent une visibilité sur les échecs de TLS sur tous les serveurs d'envoi — inestimable pour diagnostiquer les problèmes de certificat ou de configuration avant qu'ils n'affectent la livraison.