Test MTA-STS
Testez la politique MTA-STS et le TLS-RPT de tout domaine : mode d’application, serveurs autorisés et protection du courrier entrant contre les attaques par dégradation. Gratuit, sans compte.
Qu’est-ce qu’un MTA-STS ?
MTA-STS est le standard qui fait passer le chiffrement en transit de « TLS si possible » à « TLS ou pas de livraison ». Il associe un TXT DNS sur _mta-sts.votredomaine.com à un fichier de politique en HTTPS qui nomme vos serveurs de messagerie et un mode d’application. Les serveurs d’envoi compatibles (dont Gmail et Microsoft 365) lisent cette politique et refusent de livrer votre courrier à un imposteur ou sur une connexion dégradée. Associez-le à DMARC et à un BIMI pour une sécurité e-mail complète en entrée comme en sortie, et lisez le guide complet MTA-STS.
Base de connaissances e-mail
MTA-STS : définition
MTA-STS (Mail Transfer Agent Strict Transport Security, RFC 8461) permet à un domaine d’exiger des autres serveurs un TLS chiffré et authentifié pour lui livrer ses e-mails. Sans lui, le chiffrement SMTP est opportuniste : un attaquant qui intercepte la connexion peut retirer TLS et lire ou modifier les messages (attaque par dégradation). MTA-STS comble ce trou en publiant une politique que les serveurs d’envoi doivent respecter.
De quoi se compose un déploiement MTA-STS ?
Deux parties, toutes deux requises. D’abord un TXT DNS sur _mta-sts.votredomaine.com avec v=STSv1 et un id. Ensuite un fichier de politique servi en HTTPS sur https://mta-sts.votredomaine.com/.well-known/mta-sts.txt, qui liste le mode (testing ou enforce), les serveurs autorisés (mx) et un max_age. Le DNS signale qu’une politique existe et quand elle a changé ; le fichier HTTPS est la politique. Si l’un manque ou si le certificat de l’hôte mta-sts est invalide, MTA-STS ne s’applique pas.
Comment marche ce test MTA-STS ?
Saisissez un domaine : l’outil lit le TXT _mta-sts, récupère le fichier de politique sur l’hôte mta-sts en HTTPS et lit votre TXT _smtp._tls pour TLS-RPT. Il montre ensuite le mode d’application, les serveurs autorisés, le max_age et l’état des rapports, pour vérifier que tout se résout comme le verrait un serveur d’envoi.
Quelle différence entre les modes testing et enforce ?
En mode testing, un serveur d’envoi sans TLS valide livre quand même le message, mais (si TLS-RPT est configuré) vous signale l’échec. En mode enforce, ce même serveur refuse de livrer tant qu’il n’obtient pas une connexion TLS authentifiée vers un MX listé. Commencez toujours en testing, suivez vos rapports TLS-RPT jusqu’à expliquer les échecs, puis passez en enforce. Passer direct en enforce avec une liste MX fausse peut rejeter du courrier légitime.
TLS-RPT : quoi et faut-il l’avoir ?
TLS-RPT (RFC 8460) est un TXT compagnon sur _smtp._tls.votredomaine.com qui demande aux destinataires des rapports quotidiens sur les connexions TLS, succès et échecs. Vivement conseillé : ces rapports montrent si votre politique MTA-STS pose problème avant le passage en enforce, puis révèlent les soucis de livraison ensuite.
En quoi MTA-STS diffère-t-il de DANE ?
Les deux imposent TLS en réception, mais ancrent la confiance autrement. DANE publie des empreintes de certificat dans le DNS et exige DNSSEC sur votre domaine. MTA-STS s’appuie sur la PKI web (un certificat valide sur l’hôte mta-sts) sans DNSSEC, donc bien plus simple à adopter : d’où son support par Google, Microsoft et Yahoo. Les domaines déjà en DNSSEC publient souvent les deux.
Pourquoi la politique doit-elle être sur un sous-domaine mta-sts ?
Le standard fixe l’emplacement : les expéditeurs lisent https://mta-sts.votredomaine.com/.well-known/mta-sts.txt. Le sous-domaine mta-sts a besoin de son propre A/AAAA (ou CNAME) et d’un certificat TLS valide pour ce nom. Erreur courante : publier le TXT DNS sans jamais monter l’hôte mta-sts, ou laisser expirer son certificat ; le test ci-dessus le signale.
Palisade configure-t-il MTA-STS ?
Oui. Palisade publie le DNS _mta-sts, héberge le fichier de politique sur une infrastructure redondante, synchronise l’id quand la politique change et vous aide à passer de testing à enforce une fois les rapports TLS-RPT propres : sur chaque domaine géré, avec SPF, DKIM, DMARC et BIMI.
Chaque balise d’un déploiement MTA-STS et de son compagnon TLS-RPT, expliquée.
- vVersion (TXT DNS)
- La balise de version du TXT _mta-sts. Elle doit valoir « STSv1 ». Absente ou fausse, les expéditeurs ignorent l’enregistrement et ne lisent jamais votre politique.
- idID de politique
- Une chaîne unique du TXT _mta-sts (souvent un horodatage comme 20240419T120000). À chaque changement du fichier de politique hébergé, changez aussi l’id pour que les expéditeurs le relisent. Un ancien id fait servir aux caches votre politique précédente.
- modeMode d’application
- Défini dans le fichier de politique. « testing » signale les problèmes TLS mais livre quand même si TLS échoue ou si le certificat est invalide : le premier pas sûr. « enforce » demande de refuser la livraison sans connexion TLS valide et authentifiée vers un MX listé. « none » retire la politique.
- mxServeurs mail autorisés
- Une ou plusieurs lignes mx du fichier de politique, avec les noms d’hôte autorisés à recevoir votre courrier, ex. mail.example.com ou un joker comme *.example.net. Elles doivent correspondre à vos MX publiés. Un serveur expéditeur n’impose TLS qu’aux hôtes listés.
- max_ageDurée de vie
- Combien de temps (en secondes) les expéditeurs gardent votre politique en cache, dans le fichier de politique. Valeur courante : 604800 (une semaine). Plus long résiste mieux aux attaques par rétrogradation mais ralentit les changements ; commencez bas en test, puis montez une fois stable.
- ruaAdresse TLS-RPT
- Dans le TXT associé _smtp._tls (v=TLSRPTv1), rua est l’adresse des rapports TLS quotidiens, en mailto ou https:. Ils montrent à quelle fréquence le courrier vers votre domaine échoue en TLS : c’est ce qui vous permet de passer MTA-STS de testing à enforce en confiance.