SPF, DKIM et DMARC authentifient l’expéditeur d’un email, mais aucun des trois ne protège le trajet du message entre deux serveurs SMTP. Un serveur malveillant placé sur ce trajet peut encore proposer un repli vers une connexion en clair, intercepter le contenu ou le modifier, sans que l’expéditeur ni le destinataire s’en aperçoivent. MTA-STS (RFC 8461) comble ce trou en imposant TLS au moment de la remise, et TLS-RPT (RFC 8460) donne les moyens de surveiller les échecs de cette négociation jour après jour.
Le problème que MTA-STS résout : le repli TLS silencieux
Depuis des années, la plupart des serveurs SMTP négocient STARTTLS lors de l’échange avant remise. Le problème est que cette négociation reste opportuniste : si elle échoue, le protocole SMTP historique autorise un repli vers une connexion non chiffrée plutôt que de bloquer l’envoi. Un attaquant en position d’intercepter le trafic, par détournement DNS, par détournement BGP ou via un relais compromis, peut donc forcer ce repli en coupant simplement la négociation TLS, sans avoir besoin de casser le moindre chiffrement. MTA-STS retire ce choix au serveur expéditeur : une fois la politique publiée et respectée, l’absence de TLS valide devient un motif de refus d’envoi plutôt qu’un repli silencieux. DANE, qui s’appuie sur DNSSEC, vise le même objectif par une autre voie, mais son déploiement dépend d’une zone DNS signée que peu d’hébergeurs proposent encore en standard ; MTA-STS, lui, ne demande qu’un enregistrement TXT et un fichier HTTPS.
Déployer une politique MTA-STS pas à pas
Trois éléments composent une politique MTA-STS : un enregistrement DNS qui en signale l’existence et sa version, un fichier de politique servi en HTTPS sur un sous-domaine dédié, et un certificat valide pour ce sous-domaine. Aucun de ces éléments ne nécessite de toucher à la configuration du serveur de messagerie lui-même : la politique décrit un comportement attendu des serveurs expéditeurs tiers, elle ne modifie rien côté réception.
L’enregistrement DNS prend la forme suivante :
_mta-sts.exemple.fr. IN TXT "v=STSv1; id=20261108000000;"
mta-sts.exemple.fr. IN CNAME exemple.fr.
Le fichier de politique, lui, doit être accessible à l’adresse https://mta-sts.exemple.fr/.well-known/mta-sts.txt, servi avec l’en-tête Content-Type: text/plain :
version: STSv1
mode: testing
mx: mail.exemple.fr
mx: mail2.exemple.fr
max_age: 86400
Le champ id de l’enregistrement DNS doit changer à chaque modification du fichier de politique : c’est ce qui indique aux serveurs qui l’ont déjà mise en cache qu’une nouvelle version existe. Un simple horodatage, comme dans l’exemple ci-dessus, suffit.
Comprendre les trois modes : none, testing et enforce
Le champ mode du fichier de politique détermine le comportement réel appliqué par les serveurs expéditeurs qui respectent MTA-STS.
| Mode | Comportement en cas d’échec TLS | Usage recommandé |
|---|---|---|
none | Aucun blocage, la politique est ignorée en pratique | Désactivation temporaire sans retirer la politique |
testing | L’email part malgré l’échec, mais l’échec est rapporté via TLS-RPT | Phase d’observation avant mise en production |
enforce | L’email n’est pas remis en l’absence de TLS valide | Politique définitive, après validation en mode testing |
enforce sans phase de test revient à risquer de bloquer silencieusement des emails légitimes si un enregistrement MX change, si un certificat expire sans renouvellement automatique, ou si un relais sortant mal configuré échoue sur la négociation TLS. Le mode testing, maintenu plusieurs semaines, sert précisément à détecter ces cas avant qu’ils ne coûtent une remise.Activer TLS-RPT pour recevoir les rapports d’échec
TLS-RPT fonctionne indépendamment de MTA-STS mais les deux se complètent naturellement : l’un impose le chiffrement, l’autre rapporte ce qui se passe quand la négociation échoue, que la cause soit MTA-STS, DANE ou une politique TLS opportuniste classique. Son activation se résume à un enregistrement DNS :
_smtp._tls.exemple.fr. IN TXT "v=TLSRPTv1; rua=mailto:[email protected]"
Les serveurs qui gèrent TLS-RPT envoient alors un rapport agrégé, en général quotidien, au format JSON compressé, à l’adresse déclarée dans rua. Le principe rejoint celui des rapports agrégés décrits dans le guide d’authentification SPF, DKIM et DMARC : une synthèse régulière plutôt qu’une alerte en temps réel, pensée pour un traitement automatisé plutôt qu’une lecture manuelle au quotidien.
Lire et exploiter un rapport TLS-RPT
Un rapport TLS-RPT regroupe les tentatives de connexion par politique observée, MTA-STS, DANE ou aucune, et par type d’échec : certificat expiré, nom de certificat ne correspondant pas au MX, échec de la négociation elle-même, ou politique MTA-STS introuvable malgré sa publication. Un volume d’échecs qui grimpe d’un coup après un changement d’hébergeur ou de certificat est souvent le premier signal visible d’une mauvaise reconfiguration, avant même qu’un destinataire ne remonte un problème de remise.
Un repli TLS vers une connexion en clair ne génère aucune alerte côté expéditeur si rien ne le surveille : TLS-RPT est, pour le transport SMTP, l’équivalent de ce que les rapports agrégés DMARC apportent à l’authentification.
Pièges fréquents et bonnes pratiques de déploiement
Trois erreurs reviennent le plus souvent dans les déploiements observés sur des infrastructures d’envoi gérées par des équipes réduites. D’abord, oublier de renouveler automatiquement le certificat du sous-domaine mta-sts, ce qui bascule une politique en enforce vers un blocage de la remise au premier renouvellement manqué. Ensuite, modifier la liste des MX sans republier le fichier de politique avec un nouvel id, ce qui laisse des serveurs expéditeurs s’appuyer sur une politique en cache devenue incorrecte jusqu’à l’expiration du max_age. Enfin, négliger la cohérence entre la liste des mx déclarée dans la politique et les enregistrements MX réels du domaine : toute divergence fait basculer la validation côté expéditeur en échec, quel que soit le mode choisi.
Le déploiement complet, pour un domaine qui gère déjà les causes classiques de mise en spam et son authentification SPF, DKIM et DMARC, prend généralement entre deux et quatre semaines, l’essentiel du délai tenant à l’observation du mode testing plutôt qu’à la configuration technique elle-même, qui se résume à quelques enregistrements DNS et un fichier statique. Les plateformes d’envoi transactionnel les plus utilisées documentent désormais leur propre procédure MTA-STS, ce qui simplifie la partie certificat et hébergement du fichier de politique pour qui n’opère pas ses propres serveurs sortants.
Ce qu’il faut retenir
- MTA-STS empêche le repli silencieux vers une connexion SMTP non chiffrée en imposant TLS lors de la remise.
- Le déploiement passe par un enregistrement DNS, un fichier de politique HTTPS et un mode progressif :
testingavantenforce. - TLS-RPT fournit des rapports agrégés sur les échecs de négociation TLS, qu’ils viennent de MTA-STS, de DANE ou d’une politique opportuniste.
- Un certificat non renouvelé ou une politique non republiée après un changement de MX sont les deux causes de blocage les plus fréquentes une fois en mode
enforce.
MTA-STS reste largement sous-déployé chez les hébergeurs mutualisés et les petites infrastructures, alors que sa configuration technique est nettement plus simple que celle de DMARC. Le vrai frein tient à la discipline de republication de la politique à chaque changement d’infrastructure d’envoi, pas à la complexité du protocole. Sur les domaines suivis qui l’ont adopté, la phase testing a systématiquement révélé au moins un MX secondaire mal configuré que personne n’avait remarqué auparavant, un bon argument pour la traiter comme un audit gratuit plutôt que comme une formalité de sécurité. — Simon Janvier
Pour aller plus loin : la spécification MTA-STS (RFC 8461) et la spécification TLS-RPT (RFC 8460).
