SPF, DKIM et DMARC prouvent qui a envoyé un message. MTA-STS et TLS-RPT protègent le message pendant qu'il est en mouvement — ils s'assurent que la connexion qui achemine votre courrier est réellement chiffrée, et ils vous préviennent quand elle ne l'est pas. MTA-STS (SMTP MTA Strict Transport Security, défini dans la RFC 8461) permet à un domaine de déclarer que le courrier destiné à ses serveurs doit arriver via TLS avec un certificat valide. TLS-RPT (SMTP TLS Reporting, RFC 8460) demande aux serveurs expéditeurs de produire un rapport quotidien indiquant si ce chiffrement a réussi ou échoué. Aucun des deux n'authentifie le contenu — ensemble, ils comblent une faille différente, celle que le simple TLS opportuniste laisse grande ouverte. Voici le rôle de chacun et comment les déployer sans casser votre courrier entrant.
La réponse en bref#
MTA-STS est une politique que vous publiez pour que les serveurs de messagerie des autres chiffrent le
courrier qu'ils vous envoient à vous. Elle comporte deux éléments : un enregistrement DNS TXT à
_mta-sts.yourdomain.com qui signale l'existence de la politique, et un fichier de politique
hébergé en HTTPS à https://mta-sts.yourdomain.com/.well-known/mta-sts.txt qui répertorie vos noms d'hôte
MX, un mode (none, testing ou enforce) et la durée de sa mise en cache.
TLS-RPT est un second enregistrement TXT à _smtp._tls.yourdomain.com qui indique une adresse
destinée à recevoir les rapports quotidiens sur le déroulement de ces connexions TLS. Le déploiement sûr reflète
DMARC : publiez d'abord en mode testing, lisez les rapports TLS-RPT jusqu'à ce que vous soyez certain
que chaque connexion négocie proprement le TLS, puis passez à enforce.
La faille que MTA-STS comble#
Le SMTP moderne chiffre déjà la plupart du courrier en transit grâce à STARTTLS — le serveur expéditeur demande « prenez-vous en charge le TLS ? », le destinataire répond oui, et les deux négocient un canal chiffré. Le problème est que cette poignée de main est opportuniste et non authentifiée. Si l'un des deux côtés ne propose pas le TLS, le courrier bascule en clair au lieu d'échouer. Pire encore, un attaquant placé entre les deux serveurs peut supprimer l'offre STARTTLS de la conversation — une attaque par rétrogradation — et le serveur expéditeur, ne voyant aucun TLS proposé, remet discrètement le message en clair. Le certificat n'est pas non plus vérifié, si bien qu'un homme du milieu peut présenter le sien et intercepter la connexion.
MTA-STS corrige ces deux faiblesses. En publiant une politique, vous indiquez aux expéditeurs conformes : le courrier pour ce domaine doit transiter par TLS, le serveur destinataire doit présenter un certificat valide qui correspond à l'un de mes noms d'hôte MX répertoriés, et si ces conditions ne sont pas réunies, ne pas remettre — différer et réessayer plutôt que de basculer en clair. Comme la politique est récupérée via HTTPS, son propre certificat sert d'ancre de confiance, ce qui empêche un attaquant de la falsifier ou de la supprimer. Le résultat est qu'un espion passif ou un attaquant actif par rétrogradation ne peut plus forcer votre courrier entrant à passer en clair.
Ce qu'apporte TLS-RPT#
MTA-STS à lui seul, c'est de l'application sans visibilité — vous diriez aux expéditeurs de refuser les connexions non sécurisées, mais vous n'auriez aucun moyen de voir à quelle fréquence cela se produit réellement ni quels expéditeurs échouent. TLS-RPT est le canal de retour. Il fonctionne exactement comme le rapport agrégé de DMARC, et s'associe naturellement à l'habitude de lire les rapports DMARC.
Lorsque vous publiez un enregistrement TLS-RPT, les expéditeurs participants vous envoient un rapport JSON
quotidien résumant chaque session TLS qu'ils ont ouverte vers vos hôtes MX : combien ont
réussi, combien ont échoué, et — surtout — pourquoi elles ont échoué. Un rapport peut faire apparaître
un certificat expiré sur l'un de vos serveurs MX, une incohérence de nom d'hôte, une négociation
STARTTLS interrompue ou un problème de récupération de politique. C'est exactement
l'information dont vous avez besoin avant d'oser passer MTA-STS en enforce, car un échec en
mode enforce signifie du courrier entrant différé ou rejeté. TLS-RPT est ce qui rend le
déploiement sûr plutôt qu'un saut dans l'inconnu.
Configurer MTA-STS : l'enregistrement DNS et le fichier de politique#
MTA-STS nécessite trois éléments en place : un enregistrement DNS, un fichier de politique, et un sous-domaine pour héberger le fichier via HTTPS.
1. L'enregistrement DNS TXT. Publiez un enregistrement TXT à _mta-sts.yourdomain.com. Son rôle
est modeste — il annonce l'existence d'une politique et porte un id que les expéditeurs utilisent pour
détecter les changements de politique.
_mta-sts.example.com. TXT "v=STSv1; id=20260725090000"
L'id est une chaîne arbitraire d'au plus 32 caractères alphanumériques. Un horodatage est
la convention courante. La seule règle qui compte : chaque fois que vous modifiez le fichier de
politique, changez l'id. Les expéditeurs mettent votre politique en cache, et un nouvel id est le signal qui
leur indique de la récupérer à nouveau. Oubliez de l'incrémenter et vos changements risquent de passer inaperçus aussi
longtemps que votre max_age.
2. Le fichier de politique. Hébergez un fichier en texte brut au chemin fixe
https://mta-sts.yourdomain.com/.well-known/mta-sts.txt. Il répertorie le mode, chaque
nom d'hôte MX valide et une durée de mise en cache :
version: STSv1
mode: testing
mx: mail.example.com
mx: *.example.com
max_age: 86400
Chaque ligne mx doit correspondre à un nom d'hôte des enregistrements MX de votre domaine, et la forme avec
joker (*.example.com) correspond à un unique label le plus à gauche. Chaque hôte MX que vous répertoriez doit
servir un certificat actuellement valide, rattaché à une autorité de certification publique, et correspondant
à son nom d'hôte — sinon un expéditeur en mode enforce le refusera. Le max_age est
la durée de mise en cache en secondes ; la RFC 8461 autorise des valeurs allant jusqu'à 31557600 (environ
un an). Gardez-le court (un jour environ) pendant vos tests pour que les changements se propagent
rapidement, puis augmentez-le une fois que vous êtes confiant en enforce — les destinataires comme Google
recommandent un max_age long en production, même si la valeur exacte reste votre choix.
3. Le sous-domaine mta-sts en HTTPS. Le fichier de politique doit être accessible via
HTTPS sur le sous-domaine mta-sts avec un certificat valide pour
mta-sts.yourdomain.com. En pratique, vous faites pointer ce sous-domaine (via A/AAAA ou CNAME)
vers ce qui sert le fichier — un petit hébergement statique ou un CDN est typique — et vous vous assurez
qu'il répond avec Content-Type: text/plain. De nombreux fournisseurs DNS et d'hébergement proposent désormais
une option MTA-STS gérée qui prend en charge le fichier et le certificat à votre place.
Configurer TLS-RPT#
TLS-RPT est de loin le plus simple des deux : un unique enregistrement TXT, pas de fichier de politique.
_smtp._tls.example.com. TXT "v=TLSRPTv1; rua=mailto:tls-reports@example.com"
La balise rua indique où vont les rapports. Elle accepte une adresse mailto:, un point de terminaison
https: qui reçoit les rapports envoyés en POST, ou une liste des deux séparée par des virgules. Le JSON brut de TLS-RPT
est dense, si bien que la plupart des équipes font pointer rua vers un service de surveillance qui analyse les
rapports en un tableau de bord lisible — de la même manière que les rapports DMARC transitent généralement par un
analyseur plutôt que par une boîte de réception humaine. Vous pouvez publier TLS-RPT seul, et cela vaut la
peine de le faire avant MTA-STS : cela vous donne un aperçu de l'état actuel de votre TLS sans aucun
risque pour le flux de courrier.
Déployer MTA-STS et TLS-RPT en toute sécurité#
L'ordre des opérations pour MTA-STS et TLS-RPT compte plus que les enregistrements eux-mêmes — faites-le mal et vous pouvez différer votre propre courrier entrant. Suivez la même discipline « surveiller puis appliquer » qui régit un bon déploiement DMARC.
1. Publiez d'abord TLS-RPT. Sans politique MTA-STS pour l'instant, les rapports vous indiquent simplement quelle part de votre courrier entrant utilise déjà le TLS et si l'un de vos certificats MX est mal configuré. Corrigez tout ce qui est évident à ce stade.
2. Publiez MTA-STS en mode testing. Ajoutez l'enregistrement DNS et le fichier de politique avec
mode: testing. Dans ce mode, les expéditeurs évaluent votre politique et signalent les échecs via
TLS-RPT, mais ils remettent quand même le courrier normalement. Rien ne change dans votre flux de courrier
— vous ne faites que collecter des données. Laissez-le ainsi assez longtemps pour capturer un cycle
complet de vos correspondants habituels, idéalement quelques semaines.
3. Lisez les rapports TLS-RPT et corrigez les échecs. Surveillez les problèmes de certificat, les
incohérences de nom d'hôte et les hôtes MX que vous avez oublié de répertorier. Chaque échec en mode testing
est un échec que vous auriez provoqué en mode enforce. Continuez d'ajuster vos
certificats et votre fichier de politique jusqu'à ce que les rapports soient propres.
4. Passez en mode: enforce. Une fois les échecs devenus silencieux, modifiez le fichier de politique
en enforce et incrémentez l'id dans l'enregistrement DNS pour que les expéditeurs le récupèrent à nouveau. À partir de
ce moment, les expéditeurs conformes refuseront de remettre le courrier via une connexion non authentifiée ou
rétrogradée. Envisagez d'augmenter max_age maintenant pour une protection renforcée contre
les tentatives de rétrogradation.
Comment cela s'articule avec SPF, DKIM et DMARC#
Il vaut la peine d'être précis sur ce que MTA-STS et TLS-RPT font et ne font pas, car il est facile de les ranger dans la « délivrabilité » et d'en attendre la mauvaise chose.
SPF, DKIM et DMARC répondent à la question ce message provient-il vraiment de celui qu'il prétend être ? — ils authentifient l'identité et le contenu. MTA-STS et TLS-RPT répondent à une question différente : la connexion qui a acheminé ce message était-elle réellement chiffrée et vérifiée ? — ils protègent la confidentialité en transit. Les deux couches sont complémentaires et indépendantes. Un message peut réussir DMARC tout en circulant en clair, et il peut circuler via un TLS imposé tout en échouant à DMARC. Une configuration complète a besoin des deux.
Deux mises en garde honnêtes. Premièrement, MTA-STS et TLS-RPT ne font pas partie des exigences pour les expéditeurs en masse de Google et Yahoo entrées en vigueur en 2024 — celles-ci imposent SPF, DKIM, DMARC, la désinscription en un clic et un faible taux de spam, pas des politiques de sécurité du transport. Cela dit, les grands fournisseurs publient bien MTA-STS et le respectent en tant que destinataires, si bien qu'une politique que vous publiez est réellement appliquée par Gmail et d'autres lorsqu'ils vous remettent du courrier. Deuxièmement, MTA-STS n'est pas un remède au dossier spam. Il renforce la sécurité du transport entrant ; il n'améliore pas, à lui seul, l'endroit où atterrit votre marketing sortant. Le placement en boîte de réception est toujours décidé par la réputation de l'expéditeur, l'engagement et l'hygiène de la liste, et si votre courrier va dans les spams, les raisons résident dans ces signaux, pas dans votre configuration TLS. Considérez MTA-STS et TLS-RPT comme le chapitre « sécurité du transport » d'un domaine d'envoi mature — utile, mais distinct des leviers du guide de délivrabilité qui font réellement bouger le placement en boîte de réception.
Si vous voulez une analogie, MTA-STS est un proche cousin de DANE, l'ancienne méthode fondée sur DNSSEC pour imposer le TLS au SMTP. Les deux visent le même problème de rétrogradation ; MTA-STS a été conçu pour que les domaines sans DNSSEC puissent tout de même obtenir l'essentiel de la protection, en utilisant le système de certificats web à la place. Si vous utilisez déjà DANE, vous n'avez peut-être pas besoin de MTA-STS, mais les deux peuvent coexister.
Foire aux questions#
MTA-STS remplace-t-il SPF, DKIM ou DMARC ?#
Non — ils opèrent sur des couches différentes et vous avez besoin des deux. SPF, DKIM et DMARC authentifient l'expéditeur et le contenu d'un message, prouvant qu'il provient bien de votre domaine et qu'il n'a pas été altéré. MTA-STS et TLS-RPT sécurisent le transport : ils forcent la connexion qui achemine le message à utiliser un TLS vérifié et signalent quand ce n'est pas le cas. Un message a besoin d'authentification et d'une remise chiffrée, donc MTA-STS se place aux côtés de DMARC plutôt que de le remplacer.
MTA-STS et TLS-RPT sont-ils exigés par Google et Yahoo ?#
Pas dans le cadre des exigences de 2024 pour les expéditeurs en masse, qui imposent SPF, DKIM, DMARC, la désinscription en un clic et un taux de spam inférieur à 0,3 % — MTA-STS ne figure pas sur cette liste. Mais les grands fournisseurs publient eux-mêmes des politiques MTA-STS et respectent la vôtre en tant que destinataires, si bien qu'une politique que vous publiez est réellement appliquée par Gmail et d'autres. C'est une bonne pratique recommandée pour un domaine d'envoi mature, mais pas une condition formelle pour atteindre la boîte de réception.
Quelle est la différence entre MTA-STS et DANE ?#
Tous deux imposent TLS sur le SMTP entrant et se défendent contre les attaques par rétrogradation ; ils diffèrent dans la manière d'établir la confiance. DANE publie les informations de certificat dans le DNS et s'appuie sur DNSSEC pour rendre ces enregistrements inviolables. MTA-STS évite l'exigence de DNSSEC en servant sa politique via HTTPS, en utilisant le système ordinaire de certificats web comme ancre de confiance. MTA-STS est généralement plus facile à déployer pour les domaines sans DNSSEC ; les deux peuvent aussi fonctionner ensemble.
MTA-STS améliorera-t-il mon placement en boîte de réception ?#
Pas directement. MTA-STS est un contrôle de sécurité du transport pour le courrier entrant vers votre domaine — il ne change rien à la manière dont votre marketing sortant est filtré. Le placement en boîte de réception est déterminé par la réputation de l'expéditeur, l'engagement, les taux de plainte et la qualité de la liste. MTA-STS vaut la peine d'être configuré pour la sécurité et l'exhaustivité, mais si votre courrier atterrit dans les spams, la solution réside dans l'hygiène de votre liste et votre réputation, pas dans votre politique TLS.
MTA-STS et TLS-RPT renforcent les tuyaux par lesquels transite votre courrier, mais la boîte de réception se gagne sur la qualité de la liste. Le vérificateur d'e-mails gratuit repère les domaines morts et les fautes de frappe avant qu'ils ne rebondissent, et le plan gratuit exécute le pipeline complet de vérification sur votre liste — car un domaine sécurisé et bien authentifié ne mérite un placement que lorsque la liste qui le sous-tend est propre.
