Lisez les serveurs de messagerie de votre domaine dans MX, obtenez en une fois le fichier de politique MTA-STS, l’enregistrement _mta-sts et l’enregistrement de rapport TLS, et voyez ce que votre domaine publie aujourd’hui. Gratuit, sans inscription.
MTA-STS (Mail Transfer Agent Strict Transport Security, RFC 8461) indique aux serveurs expéditeurs que votre domaine n’accepte le courrier que par une connexion chiffrée avec un certificat valide, et vers quels serveurs. Sans lui, le chiffrement entre serveurs de messagerie est facultatif : un attaquant placé sur le trajet peut supprimer l’offre TLS et lire le courrier en clair, sans que l’expéditeur s’en aperçoive.
MTA-STS se compose d’un fichier de politique sur un serveur web et d’un enregistrement TXT qui l’annonce. TLS-RPT (RFC 8460) ajoute une adresse de rapport où les expéditeurs signalent les livraisons qu’ils n’ont pas pu sécuriser. Le générateur écrit les trois.
1. Chargez vos serveurs de messagerie. Saisissez le domaine et cliquez sur « Charger l’enregistrement publié ». Le générateur lit les enregistrements MX et les inscrit comme lignes mx de la politique. Les hôtes d’un même fournisseur peuvent être regroupés avec un joker comme *.mail.protection.outlook.com.
2. Publiez le fichier de politique. Il se place à https://mta-sts.example.com/.well-known/mta-sts.txt, servi en texte brut via HTTPS avec un certificat valide pour mta-sts.example.com. Le sous-domaine a besoin d’un enregistrement A ou CNAME vers n’importe quel serveur web capable d’héberger le fichier.
3. Publiez les deux enregistrements TXT. _mta-sts avec v=STSv1; id=... annonce la politique ; _smtp._tls avec v=TLSRPTv1; rua=mailto:... indique l’adresse des rapports TLS quotidiens.
4. Commencez en testing, puis passez à enforce. En mode testing, les expéditeurs signalent les problèmes mais continuent de livrer. Après deux semaines de rapports TLS propres, passez le fichier à mode: enforce et changez l’id de l’enregistrement TXT pour que les expéditeurs récupèrent la nouvelle version.
| Ligne | Signification |
|---|---|
version: STSv1 |
Toujours cette valeur. |
mode: testing |
testing signale seulement, enforce refuse la livraison non sécurisée, none retire une politique. |
mx: mx1.example.com |
Une ligne par serveur autorisé à recevoir le courrier. Un joker couvre exactement un niveau. |
max_age: 604800 |
Durée en secondes pendant laquelle un expéditeur peut garder la politique en cache. Au maximum 31557600, soit un an. |
Les lignes sont séparées par CRLF, comme dans le fichier téléchargé. L’id de l’enregistrement TXT est une chaîne libre de 32 caractères au plus ; le générateur utilise l’horodatage actuel, si bien que chaque nouvelle politique reçoit automatiquement un nouvel id. Les expéditeurs ne récupèrent à nouveau le fichier que si l’id change ou que max_age a expiré.
*.example.com correspond à mx1.example.com, pas à mx1.eu.example.com.Sur les 1 000 domaines .de les mieux classés de la liste Tranco (liste 467YX, lue le 19 octobre 2026), 924 reçoivent du courrier. Seuls 63 publient un enregistrement MTA-STS et 62 un enregistrement TLS-RPT. Plus de neuf domaines allemands sur dix dotés d’un serveur de messagerie acceptent donc encore, sans que personne ne le remarque, une rétrogradation vers une livraison non chiffrée. MTA-STS fait partie des rares protections de messagerie qui ne coûtent qu’un petit fichier et deux enregistrements DNS.
Les lignes mx doivent correspondre aux noms d’hôte de vos enregistrements MX. Pour une messagerie hébergée, les noms du fournisseur sont stables, et un joker garde la politique valide quand un hôte s’ajoute.
| Messagerie hébergée chez | Lignes mx de la politique |
|---|---|
| Microsoft 365 | mx: *.mail.protection.outlook.com |
| Google Workspace | mx: smtp.google.com pour la configuration actuelle, ou mx: aspmx.l.google.com plus mx: *.aspmx.l.google.com pour la configuration classique |
| Votre propre serveur | exactement les noms de vos enregistrements MX, par ex. mx1.example.com |
Comparez le résultat à vos vrais enregistrements MX avant de passer à enforce. « Charger l’enregistrement publié » remplit le champ depuis MX et, une fois une politique publiée, la vérification signale chaque hôte MX qu’elle ne couvre pas. Rappelez-vous qu’un joker couvre un seul niveau : *.aspmx.l.google.com correspond à alt1.aspmx.l.google.com, mais pas à aspmx.l.google.com lui-même, qui a donc besoin de sa propre ligne.
Le fichier n’a besoin que de HTTPS avec un certificat valide pour mta-sts. suivi de votre domaine. Les solutions courantes :
/.well-known/mta-sts.txt.Quelle que soit la solution, le fichier doit être servi avec le statut 200, directement depuis mta-sts. suivi de votre domaine, sans redirection vers un autre hôte. Les expéditeurs ne suivent pas les redirections, et une politique redirigée compte comme absente.
Oui, mais un serveur minimal. Les expéditeurs récupèrent un petit fichier texte en HTTPS sur mta-sts.votredomaine. N’importe quel hébergement web ou statique avec un certificat valide pour ce nom convient ; le fichier ne change que si vos serveurs de messagerie changent.
En testing, les expéditeurs vérifient la politique et signalent les échecs via TLS-RPT, mais livrent quand même. En enforce, ils refusent de livrer à un serveur listé par une connexion sans TLS valide. Commencez en testing et basculez quand les rapports sont propres.
Les deux résolvent le même problème de deux manières. DANE nécessite DNSSEC et est utilisé par de nombreux fournisseurs européens ; MTA-STS fonctionne sans DNSSEC et est pris en charge par Gmail et Microsoft. Publier les deux est courant et sans inconvénient.
Un rapport JSON par expéditeur et par jour : combien de connexions ont été établies, combien ont réussi avec un TLS valide et la raison de chaque échec, comme un certificat expiré ou un hôte absent de la politique. Ils ne contiennent aucun contenu de message.
Passez le fichier à mode: none, donnez un nouvel id à l’enregistrement TXT et laissez les deux en ligne au moins pendant le max_age publié auparavant. Supprimer les enregistrements tout de suite laisse les expéditeurs appliquer la politique en cache jusqu’à son expiration.
Non. La politique et les enregistrements sont construits dans le navigateur. « Charger l’enregistrement publié » lit MX, _mta-sts et _smtp._tls du domaine et récupère le fichier de politique publié, comme le ferait n’importe quel expéditeur. Rien n’est conservé.
« Charger l’enregistrement publié » demande à notre résolveur les enregistrements MX, les enregistrements TXT sur _mta-sts et _smtp._tls, et récupère le fichier de politique sur https://mta-sts. suivi de votre domaine. Le validateur de l’Email Security Check compare ensuite chaque ligne mx d’une politique publiée aux vrais hôtes MX, de sorte qu’un serveur non couvert est signalé avant qu’enforce ne le bloque.
Le générateur fonctionne dans le navigateur : il écrit la politique à partir du mode, des serveurs et de la durée de cache choisis, utilise un horodatage comme id et construit l’enregistrement TLS-RPT à partir de votre adresse de rapport. Il ne peut pas mettre en place le serveur web ni le certificat du sous-domaine mta-sts, et il ne teste pas si vos serveurs présentent des certificats valides ; les rapports TLS le feront.