SPF, DKIM et DMARC authentifient l'expéditeur d'un email. MTA-STS et TLS-RPT s'occupent d'un problème complètement différent : la sécurité du transport entre serveurs mail, c'est-à-dire si vos emails circulent chiffrés ou en clair sur le réseau. Ce sont deux protocoles complémentaires, rarement expliqués, mais qui comblent une faille réelle du protocole SMTP historique.
Le problème que SMTP ne résout pas nativement
SMTP, le protocole de base de l'email, chiffre les connexions via une extension appelée STARTTLS — mais cette extension est opportuniste : si la connexion chiffrée échoue pour une raison quelconque (attaque, mauvaise configuration, interception), la plupart des serveurs se rabattent silencieusement sur une connexion en clair plutôt que d'échouer l'envoi. Un attaquant capable d'intercepter le trafic réseau peut donc forcer ce repli et lire, voire modifier, des emails en transit — une attaque connue sous le nom de « downgrade STARTTLS ».
MTA-STS : imposer le chiffrement, sans exception
MTA-STS (Mail Transfer Agent Strict Transport Security) publie une politique qui dit explicitement aux serveurs expéditeurs : « n'envoyez jamais d'email vers mon domaine sans connexion TLS valide, et n'acceptez aucun repli en clair ». Concrètement, cela demande deux éléments :
- Un enregistrement DNS TXT sur
_mta-sts.votredomaine.com, qui signale l'existence d'une politique. - Un fichier de politique hébergé en HTTPS sur
mta-sts.votredomaine.com/.well-known/mta-sts.txt, qui précise le mode (enforce,testing) et les serveurs MX autorisés.
v=STSv1; id=20260807T000000Z
En mode enforce, un serveur expéditeur qui ne peut pas établir de connexion TLS valide vers vos serveurs mail refusera d'envoyer le message en clair — il échouera plutôt que de compromettre la confidentialité.
TLS-RPT : être informé quand ça casse
TLS-RPT (SMTP TLS Reporting) est le complément naturel de MTA-STS : il publie une adresse qui reçoit des rapports quotidiens sur les tentatives de connexion TLS ayant échoué vers votre domaine.
v=TLSRPTv1; rua=mailto:tls-reports@exemple.com
Sans TLS-RPT, un problème de certificat TLS ou de configuration de vos serveurs mail peut bloquer silencieusement une partie de vos emails entrants — les expéditeurs en mode enforce refusent simplement d'envoyer, sans que vous en soyez informé autrement que par une baisse de volume difficile à diagnostiquer.
Pourquoi ces deux protocoles sont sous-utilisés
Contrairement à SPF/DKIM/DMARC qui protègent votre réputation d'expéditeur, MTA-STS et TLS-RPT protègent la confidentialité des emails que vous recevez — un bénéfice moins visible immédiatement, donc souvent relégué après les priorités d'authentification. Ils sont pourtant simples à mettre en place une fois SPF/DKIM/DMARC stabilisés, et ferment une faille réelle que ces trois protocoles ne couvrent pas du tout.
À retenir
- MTA-STS impose le chiffrement TLS pour les emails entrants vers votre domaine, sans repli possible en clair.
- TLS-RPT vous signale quand des tentatives de connexion chiffrée échouent, avant que ça devienne un problème silencieux de délivrabilité.
- Les deux sont indépendants de SPF/DKIM/DMARC : ils s'ajoutent à votre configuration, ils ne la remplacent pas.