ServicesBlogA proposContact
Retour au blog

Sécurité email

MTA-STS & TLS-RPT : sécuriser le transport des emails

Comprendre MTA-STS et TLS-RPT : comment imposer TLS entre serveurs mail, publier une politique, recevoir les rapports et déployer sans casser les flux.

25 septembre 2025 - 8 min

Illustration MTA-STS et TLS-RPT pour sécuriser le transport email

SPF, DKIM et DMARC protègent l’identité d’un email.

MTA-STS et TLS-RPT protègent plutôt son chemin de transport.

Ces deux mécanismes aident un domaine à dire aux autres serveurs : “quand vous me livrez un email, utilisez TLS correctement, et prévenez-moi si quelque chose échoue”.

Le problème : SMTP utilise souvent TLS de façon opportuniste

Quand un serveur mail livre un message à un autre serveur mail, il utilise SMTP.

Dans beaucoup de cas, TLS est négocié avec STARTTLS. C’est utile, mais historiquement opportuniste : si TLS n’est pas proposé ou si la connexion est dégradée, certains serveurs peuvent encore tenter une livraison moins sûre.

Un attaquant placé sur le chemin peut chercher à provoquer ce type de dégradation.

Il peut aussi tenter de manipuler la résolution DNS ou le chemin vers les MX du domaine destinataire.

MTA-STS répond à ce risque :

Si mon domaine annonce une politique TLS stricte, les serveurs compatibles doivent refuser une livraison qui ne respecte pas cette politique.

À quoi sert MTA-STS ?

MTA-STS signifie Mail Transfer Agent Strict Transport Security.

Il permet à un domaine de publier une politique qui indique :

  • que ses serveurs MX acceptent TLS ;
  • quels MX sont autorisés ;
  • quel mode appliquer ;
  • combien de temps la politique peut être mise en cache.

MTA-STS annonce une politique TLS avec un TXT DNS et un fichier HTTPS

Concrètement, un expéditeur compatible vérifie la politique MTA-STS du domaine destinataire avant de livrer.

Si la politique est en mode strict et que le MX ne présente pas un certificat TLS valide, la livraison doit être refusée plutôt que dégradée.

MTA-STS sert donc à éviter deux scénarios classiques :

  • la dégradation TLS, où une connexion chiffrée devient non chiffrée ;
  • le détournement vers un mauvais MX qui ne correspond pas à la politique publiée.

Comment une politique MTA-STS est publiée

MTA-STS repose sur deux éléments.

D’abord, un enregistrement DNS TXT :

_mta-sts.example.com. TXT "v=STSv1; id=20250925"

Le champ id sert d’identifiant de version. Quand la politique change, on change aussi cet identifiant pour pousser les expéditeurs compatibles à la recharger.

Ensuite, un fichier accessible en HTTPS :

https://mta-sts.example.com/.well-known/mta-sts.txt

Exemple de contenu :

version: STSv1
mode: testing
mx: mail.example.com
mx: *.protection.outlook.com
max_age: 86400

Les champs importants sont :

  • version : la version de la politique ;
  • mode : le comportement attendu ;
  • mx : les serveurs MX autorisés ;
  • max_age : la durée de cache de la politique.

Les modes MTA-STS

MTA-STS a trois modes principaux.

none permet de publier une politique sans demander d’application stricte. Il sert surtout à préparer ou désactiver proprement.

testing permet de recevoir des rapports sans bloquer brutalement les messages.

enforce demande aux expéditeurs compatibles de refuser la livraison si TLS valide n’est pas disponible ou si le MX ne correspond pas à la politique.

Déploiement progressif de MTA-STS avec les modes none, testing et enforce

La bonne pratique consiste à commencer avec testing, un max_age court et TLS-RPT actif.

Une fois les rapports propres et les MX validés, on peut augmenter progressivement max_age, puis passer en enforce.

À quoi sert TLS-RPT ?

TLS-RPT signifie SMTP TLS Reporting.

Il permet à un domaine de recevoir des rapports sur les problèmes rencontrés par les expéditeurs lorsqu’ils tentent de livrer des emails en TLS.

Sans TLS-RPT, une politique MTA-STS peut échouer silencieusement : un partenaire n’arrive plus à livrer, mais vous n’avez pas forcément une vision claire de la cause.

TLS-RPT apporte cette visibilité.

TLS-RPT centralise les rapports envoyés par Gmail, Microsoft et Yahoo

Il se publie avec un enregistrement TXT :

_smtp._tls.example.com. TXT "v=TLSRPTv1; rua=mailto:tls-rpt@example.com"

Les rapports peuvent aussi être envoyés vers une URL HTTPS selon les implémentations.

Ils contiennent des informations agrégées : domaine concerné, politique appliquée, nombre de sessions, types d’échecs et période observée.

Ce que les rapports peuvent révéler

TLS-RPT est particulièrement utile pendant les changements d’infrastructure.

Il peut faire apparaître :

  • un certificat expiré ;
  • un certificat qui ne couvre pas le nom du MX ;
  • un MX oublié dans la politique MTA-STS ;
  • un problème de chaîne de certification ;
  • une incompatibilité TLS ;
  • une erreur DNS ;
  • un partenaire qui tente encore une livraison vers un ancien serveur ;
  • une passerelle mail qui ne présente pas le bon certificat.

Ces rapports ne remplacent pas les logs SMTP, mais ils donnent une vue externe.

C’est précieux, car ce qui fonctionne depuis votre serveur ne fonctionne pas toujours depuis Gmail, Microsoft, Yahoo ou d’autres expéditeurs.

MTA-STS, TLS-RPT et DNSSEC

MTA-STS ne remplace pas DNSSEC ni SMTP DANE.

Il fonctionne différemment.

SMTP DANE s’appuie sur DNSSEC pour publier des informations TLS vérifiables dans le DNS.

MTA-STS s’appuie sur un TXT DNS, puis sur une politique récupérée en HTTPS.

Les deux approches visent à sécuriser le transport SMTP, mais avec des dépendances différentes.

Dans beaucoup d’environnements, MTA-STS est plus simple à déployer que DANE, car il ne nécessite pas forcément DNSSEC sur toute la chaîne DNS.

En revanche, il demande de maintenir correctement :

  • le sous-domaine mta-sts ;
  • le certificat HTTPS de ce sous-domaine ;
  • la liste des MX autorisés ;
  • le mode de politique ;
  • le max_age ;
  • la réception et l’analyse des rapports TLS-RPT.

Les erreurs fréquentes

Les erreurs MTA-STS les plus courantes sont assez prévisibles.

On retrouve souvent :

  • une politique en enforce publiée trop tôt ;
  • un max_age trop long dès le premier déploiement ;
  • un MX réel absent de la politique ;
  • un wildcard mx mal compris ;
  • un certificat TLS invalide sur un MX ;
  • un fichier mta-sts.txt inaccessible en HTTPS ;
  • un TXT _mta-sts dont l’id n’est pas mis à jour après modification ;
  • une adresse TLS-RPT non surveillée.

Ces erreurs peuvent provoquer des files d’attente, des retards ou des rejets chez les expéditeurs compatibles.

La sécurité du transport email se prépare donc comme un changement de production.

Méthode de déploiement

Pour une PME ou une organisation avec plusieurs flux, la méthode la plus sûre est progressive.

Étapes recommandées :

  1. inventorier les MX réels du domaine ;
  2. vérifier les certificats TLS présentés par ces MX ;
  3. publier TLS-RPT ;
  4. publier MTA-STS en testing ;
  5. surveiller les rapports pendant quelques jours ;
  6. corriger les MX, certificats ou passerelles signalés ;
  7. augmenter progressivement max_age ;
  8. passer en enforce seulement quand les rapports sont propres ;
  9. documenter la politique et les dépendances.

Cette approche évite de transformer une amélioration de sécurité en incident de messagerie.

Conclusion

MTA-STS et TLS-RPT ajoutent une couche de confiance au transport email.

MTA-STS permet à un domaine d’exiger TLS et de déclarer les MX autorisés.

TLS-RPT permet de recevoir des rapports quand les expéditeurs rencontrent des problèmes de livraison sécurisée.

Ensemble, ils aident à détecter les erreurs de certificats, les mauvais MX, les dégradations TLS et les chemins de livraison anormaux.

Ils ne remplacent pas SPF, DKIM, DMARC, DNSSEC ou DANE. Ils complètent l’architecture email sur une autre couche : le chemin SMTP entre serveurs.

Sources utiles : RFC 8461 - SMTP MTA Strict Transport Security et RFC 8460 - SMTP TLS Reporting.