MTA-STS

01 — DéfinitionQu'est-ce que MTA-STS ?

MTA-STS (Mail Transfer Agent Strict Transport Security) est un standard publié dans le RFC 8461 en septembre 2018. Il permet à un domaine récepteur d'emails de publier une politique qui exige des serveurs d'envoi qu'ils utilisent une connexion TLS valide pour délivrer les emails.

Le nom est volontairement analogue à HSTS (HTTP Strict Transport Security) pour le web : même logique appliquée au protocole SMTP. Un site web peut demander aux navigateurs d'utiliser toujours HTTPS ; un domaine mail peut demander aux serveurs d'envoi d'utiliser toujours TLS.

Contrairement à SPF, DKIM et DMARC qui protègent l'authenticité de l'expéditeur (qui a envoyé le mail), MTA-STS protège le canal de transmission (comment le mail circule). Il complète les précédents dans une architecture email moderne :

• SPF / DKIM / DMARC : l'expéditeur est-il légitime ?
• MTA-STS : le canal entre serveurs est-il chiffré et authentifié ?
• BIMI : l'utilisateur final voit-il un signal visuel de confiance ?

MTA-STS a été déployé progressivement par les grands acteurs à partir de 2019. En 2026, Gmail, Microsoft 365, Yahoo, Apple iCloud, La Poste, Orange et la plupart des hébergeurs majeurs supportent MTA-STS aussi bien en envoi qu'en réception.

MTA-STS résout un problème invisible mais réel : sans TLS forcé, un attaquant sur le chemin réseau peut dégrader la connexion SMTP en clair et lire les emails en transit. MTA-STS empêche cette dégradation.

02 — ContexteLe problème que MTA-STS résout

SMTP et son chiffrement historiquement opportuniste

Le protocole SMTP date des années 1980 et a été conçu sans chiffrement. La commande STARTTLS a été ajoutée ultérieurement pour permettre un passage en TLS après négociation initiale en clair. Mais ce chiffrement est opportuniste : si la négociation échoue, ou si STARTTLS n'est pas proposé, la connexion tombe en clair sans aucune alerte.

Attaques de downgrade STARTTLS

Un attaquant positionné entre deux serveurs mail (FAI compromis, opérateur hostile, acteur étatique) peut supprimer l'annonce STARTTLS dans la négociation SMTP. Le serveur d'envoi, ne voyant aucune offre TLS, se rabat sur une connexion en clair. L'attaquant peut alors lire et modifier les emails en transit. Cette technique s'appelle STARTTLS stripping.

L'étude publiée par Google et l'Université du Michigan en 2015 avait révélé que des millions d'emails entre Gmail et certains pays étaient systématiquement déchiffrés par ce procédé dans certaines régions du monde. Ce constat a motivé la création de MTA-STS et DANE.

Attaques par certificats frauduleux

Même quand TLS fonctionne, SMTP n'a pas les mêmes contrôles que HTTPS. Beaucoup de serveurs mail acceptent des certificats auto-signés, expirés, ou émis pour un autre domaine, par souci de délivrabilité. Un attaquant peut présenter un certificat frauduleux et établir une connexion TLS en apparence correcte, tout en interceptant les emails.

Attaques sur le MX

Pire encore, un attaquant avec accès au DNS (DNS hijacking, détournement BGP) peut modifier les enregistrements MX du destinataire et rediriger le flux mail vers son propre serveur. Sans validation forte, le serveur d'envoi ne s'apercevra de rien.

Réponse MTA-STS

MTA-STS apporte trois garanties cumulatives :

• TLS obligatoire : le serveur d'envoi refuse de livrer le mail si la connexion TLS échoue.
• Certificat valide : le certificat présenté doit être émis par une autorité reconnue et correspondre au nom du serveur.
• Liste de MX autorisés : la politique publie les MX légitimes ; seuls ceux-ci sont acceptés.

03 — FonctionnementMécanique technique

Deux éléments de configuration

1. Un enregistrement DNS TXT

Publié sur _mta-sts.votredomaine.fr. Il indique simplement la version de la politique et un identifiant pour la détection de changements. Exemple :

_mta-sts.exemple.fr IN TXT
"v=STSv1; id=20260422120000Z"

Les tags :

• v : version du protocole (toujours STSv1).
• id : identifiant de la politique, changé à chaque mise à jour. Format libre, souvent un timestamp.

2. Un fichier de politique servi en HTTPS

Publié à l'URL https://mta-sts.votredomaine.fr/.well-known/mta-sts.txt. Le fichier texte contient la politique réelle. Exemple :

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

Les clés :

• version : STSv1.
• mode : none, testing ou enforce (voir section dédiée).
• mx : liste des serveurs MX légitimes. Wildcards acceptés.
• max_age : durée en secondes pendant laquelle la politique est valide en cache (typiquement 1 semaine, max 1 an).

Parcours d'un envoi avec MTA-STS

1. Un serveur d'envoi veut livrer un email à destinataire@exemple.fr.
2. Il effectue une requête DNS sur les MX de exemple.fr.
3. Il consulte _mta-sts.exemple.fr pour détecter une politique MTA-STS.
4. Si présente et non en cache, il récupère https://mta-sts.exemple.fr/.well-known/mta-sts.txt.
5. Il met la politique en cache selon le max_age.
6. Il applique la politique pour cette livraison et les suivantes :
   • Le serveur MX utilisé est-il dans la liste ?
   • La connexion TLS réussit-elle ?
   • Le certificat est-il valide et correspond-il au nom du MX ?
7. Si toutes les conditions sont remplies et que le mode est enforce, le mail est délivré. Sinon, il est différé ou rejeté.

Pourquoi passer par HTTPS pour la politique ?

Le choix de servir la politique via HTTPS (et non seulement DNS) est délibéré : en l'absence de DNSSEC largement déployé, le DNS classique est falsifiable. En revanche, HTTPS avec un certificat d'autorité publique est authentifiable par tous les serveurs Internet. MTA-STS tire parti de l'infrastructure X.509 web, qui est plus universelle que DNSSEC.

L'inconvénient : on ajoute une dépendance HTTP pour un protocole email. Si le serveur web est indisponible au moment où un expéditeur tente de récupérer la politique, celui-ci applique la politique en cache (si présente) ou ne peut pas valider MTA-STS cette fois-ci.

04 — Modesnone, testing, enforce

Mode none — désactivé

Aucun blocage. Utile pour désactiver temporairement MTA-STS sans retirer tous les enregistrements DNS. Peu utilisé en pratique.

Mode testing — observation

Le serveur expéditeur vérifie la politique mais ne bloque pas les mails en cas d'échec. Les problèmes sont remontés via TLS-RPT (voir section dédiée) sans impact sur la délivrabilité. Étape indispensable avant enforce.

En mode testing, on identifie :

• Les expéditeurs qui ne supportent pas MTA-STS (rapport vide ou incomplet).
• Les problèmes de configuration TLS sur vos propres MX.
• Les prestataires tiers qui envoient des mails sans TLS correct.
• Les erreurs dans la politique (MX mal listés, certificats invalides).

Durée typique : 4 à 12 semaines.

Mode enforce — blocage actif

Le mode cible. Tout échec de validation MTA-STS entraîne un différé ou un refus du mail. Un attaquant qui tente un downgrade TLS ne peut pas intercepter le mail — il sera soit correctement chiffré, soit non livré du tout.

Passer en enforce nécessite d'avoir parfaitement résolu les incidents identifiés en mode testing. Un enforce prématuré peut provoquer des pertes d'emails avec des partenaires légitimes qui n'ont pas encore une configuration TLS correcte.

Rétrogradation

Le passage de enforce à testing (ou none) est toujours possible. Les serveurs expéditeurs respectent la dernière politique valide en cache : en cas de problème majeur, il suffit de mettre à jour la politique et de changer l'id dans le DNS pour forcer le rechargement.

05 — ComparaisonMTA-STS et DANE

Deux approches du même problème

DANE (DNS-based Authentication of Named Entities, RFC 7672 pour SMTP) est l'autre standard qui force le TLS entre serveurs mail. Les deux existent en parallèle et poursuivent le même objectif, mais avec des architectures différentes.

DANE — fondation DNSSEC

DANE publie les empreintes de certificats dans des enregistrements DNS (type TLSA) protégés par DNSSEC. Le serveur expéditeur vérifie que le certificat présenté correspond à l'empreinte publiée. Avantages : cryptographiquement robuste, pas de dépendance HTTPS, intégré au DNS. Inconvénients : dépendance stricte à DNSSEC (pas déployé partout), complexité opérationnelle, rotation des certificats délicate.

MTA-STS — fondation HTTPS

MTA-STS publie sa politique via HTTPS, en s'appuyant sur les autorités de certification classiques. Avantages : pas besoin de DNSSEC, déploiement plus simple, accessible à toute organisation ayant un site web. Inconvénients : dépendance à la disponibilité d'un serveur HTTPS, confiance dans les AC publiques.

Géographie du déploiement

Les deux standards ont des adoptions géographiquement différentes :

• DANE est dominant en Allemagne, aux Pays-Bas, dans certains pays scandinaves où DNSSEC est très déployé. L'allemand DE-NIC et le néerlandais SIDN poussent fortement ce standard.
• MTA-STS est dominant dans le monde anglo-saxon et par défaut chez Gmail, Microsoft, Yahoo. C'est le choix par défaut de la plupart des hébergeurs grand public.

Les deux sont complémentaires

Les deux standards peuvent coexister sur un même domaine et se renforcent mutuellement. Un serveur expéditeur respectant DANE et MTA-STS appliquera les deux validations. Les organisations les plus exigeantes déploient les deux : DANE pour les destinataires qui le supportent, MTA-STS pour la couverture plus large.

Quel choisir en pratique ?

Pour la majorité des organisations en France, MTA-STS est le choix par défaut pragmatique : compatible avec Gmail, Microsoft 365, Orange, La Poste, Apple, plus simple à déployer sans DNSSEC, aligné avec les recommandations CNIL et ANSSI. DANE est à privilégier si vous avez déjà déployé DNSSEC sur votre domaine, ou pour des environnements de très haute sécurité.

06 — TLS-RPTLe complément reporting

Principe

TLS-RPT (SMTP TLS Reporting), publié dans le RFC 8460, permet aux serveurs expéditeurs d'envoyer des rapports sur les problèmes TLS rencontrés en tentant de se connecter à votre domaine. Les rapports sont envoyés quotidiennement, par email ou via HTTPS, et contiennent le détail des sessions échouées.

Publication

Un enregistrement TXT sur _smtp._tls.votredomaine.fr :

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

Les tags :

• v : version (TLSRPTv1).
• rua : URI de destination — mailto: pour email, https:// pour webhook.

Contenu des rapports

Les rapports sont au format JSON structuré et contiennent :

• Date et période couverte.
• Serveur expéditeur qui rapporte.
• Nombre total de sessions tentées.
• Nombre de succès et d'échecs.
• Détail des échecs par catégorie (certificat invalide, TLS non disponible, MX hors politique…).
• Identifiants des MX impliqués.

Utilité

• Détecter des tentatives d'interception ou de downgrade.
• Identifier des problèmes de configuration sur ses propres serveurs.
• Valider sereinement la transition testing → enforce.
• Surveiller dans la durée la qualité de l'écosystème TLS entrant.

Outils de traitement

Les rapports TLS-RPT arrivent en volume important et sont peu lisibles manuellement. Des outils d'analyse automatisée sont proposés par Dmarcian, EasyDMARC, Valimail, PowerDMARC, Red Sift et d'autres spécialistes de l'email. Ces outils consolident, normalisent et visualisent les rapports.

Activer TLS-RPT en premier

Conseil opérationnel classique : activer TLS-RPT avant MTA-STS. Le reporting fonctionne même sans politique active et donne immédiatement de la visibilité. Après quelques semaines d'observation, la politique MTA-STS peut être déployée en connaissance de cause.

07 — DéploiementMise en place pas à pas

08 — FAQQuestions fréquentes

MTA-STS est-il compatible avec les messageries internes ?

Oui. MTA-STS s'applique au flux entre MTA (serveurs SMTP) sur Internet, sans impact sur les messageries internes (Exchange, Microsoft 365, Google Workspace) qui utilisent leurs propres protocoles. Déployer MTA-STS ne modifie rien pour les utilisateurs finaux ni pour les messageries internes.

Quels sont les risques de déployer MTA-STS ?

Principal risque : des emails légitimes perdus si un partenaire envoie depuis un serveur dont le TLS est mal configuré. C'est pour cette raison que le mode testing est essentiel. Un autre risque est lié à la disponibilité du serveur web servant la politique : s'il est down, les expéditeurs ne peuvent pas charger une politique récente. Avoir une politique en cache suffisamment longue (max_age de plusieurs semaines) atténue ce risque.

MTA-STS fonctionne-t-il avec Microsoft 365 et Google Workspace ?

Oui, les deux sont pleinement compatibles aussi bien en envoi qu'en réception. Google Workspace supporte MTA-STS nativement côté envoi depuis 2020. Microsoft 365 a renforcé son support progressivement : support complet en envoi et en réception depuis 2022-2023. La configuration côté client est généralement automatique dès que les enregistrements DNS sont publiés.

Faut-il un MTA-STS pour chaque sous-domaine ?

MTA-STS fonctionne par domaine. Si vous utilisez plusieurs sous-domaines pour envoyer des emails (sales.exemple.fr, support.exemple.fr), chaque sous-domaine qui reçoit des emails doit avoir sa propre politique MTA-STS. Pour les sous-domaines qui ne font que de l'envoi (domaines tiers marketing), MTA-STS ne s'applique pas directement.

MTA-STS peut-il être combiné avec S/MIME ou PGP ?

Oui, les standards sont indépendants. MTA-STS protège le transport entre serveurs ; S/MIME et PGP chiffrent de bout en bout le contenu. Les deux couches sont complémentaires : MTA-STS garantit le canal, le chiffrement applicatif garantit la confidentialité du contenu même face à un hébergeur compromis. Les environnements sensibles combinent typiquement les deux.