Contrôle e-mailpar Jarod Capella
Contrôle e-mail / Vérifier MTA-STS et TLS-RPT d'un domaine

Vérifier MTA-STS et TLS-RPT d'un domaine

Par Jarod Capella · Mis à jour le 14 novembre 2026 · 3 min de lecture

SPF, DKIM et DMARC protègent l'identité de l'expéditeur. MTA-STS protège autre chose : le trajet. Sans lui, un serveur qui envoie du courrier vers votre domaine accepte de retomber en clair si le chiffrement STARTTLS est refusé, et un attaquant placé sur le réseau peut provoquer ce refus. MTA-STS (RFC 8461) permet de déclarer que vos serveurs imposent TLS. TLS-RPT (RFC 8460) vous renvoie des rapports quand ça échoue. Règles lues dans le texte des deux RFC le 6 novembre 2026.

Vérifier un domaine

La requête DNS part de votre navigateur vers dns.google (secours : cloudflare-dns.com). Rien n'est stocké. Le fichier de politique, lui, se trouve sur un site web que le navigateur ne peut pas lire depuis cette page : collez son contenu plus bas.

Valider le fichier mta-sts.txt

Le fichier se lit à l'adresse https://mta-sts.VOTRE-DOMAINE/.well-known/mta-sts.txt. Ouvrez-la dans un onglet, copiez le texte et collez-le ici. Si vous avez lancé la vérification ci-dessus, les lignes mx sont aussi comparées aux serveurs MX réels du domaine.

Ce que disent les RFC

L'enregistrement _mta-sts

Un TXT au nom _mta-sts.votre-domaine, de la forme v=STSv1; id=20261106T1200. L'étiquette id est obligatoire, 1 à 32 lettres ou chiffres. Elle sert à signaler un changement : modifiez-la à chaque modification de la politique, sinon les expéditeurs gardent l'ancienne version en cache. Si plusieurs enregistrements commencent par v=STSv1;, ou si l'enregistrement est invalide, l'expéditeur considère que vous n'avez aucune politique.

Le fichier de politique

Servi en HTTPS par l'hôte mta-sts.votre-domaine, en text/plain. Il contient version: STSv1, mode, au moins une ligne mx (sauf si le mode est none) et max_age, en secondes, au plus 31 557 600 (un an). Chaque mx sur sa ligne : un nom complet ou un motif *.exemple.net.

Les trois modes

  • testing : le courrier est livré même si la validation échoue. Si TLS-RPT est en place, l'expéditeur envoie un rapport. C'est le mode de départ.
  • enforce : l'expéditeur ne doit pas livrer vers un serveur dont le certificat ou le nom ne correspond pas, ou qui n'offre pas STARTTLS. Le courrier est retenu et réessayé plus tard.
  • none : comme s'il n'y avait pas de politique. C'est la voie de sortie pour retirer MTA-STS proprement.

TLS-RPT

Un TXT au nom _smtp._tls.votre-domaine : v=TLSRPTv1; rua=mailto:tls@exemple.fr. L'étiquette rua accepte mailto: ou https:, plusieurs adresses séparées par des virgules.

Déployer sans casser le courrier

  1. Vérifiez que chaque serveur MX présente un certificat valide dont le nom correspond à l'enregistrement MX.
  2. Publiez TLS-RPT d'abord, pour recevoir les rapports.
  3. Publiez la politique en testing avec un max_age court (86 400, un jour). Lisez les rapports quelques semaines.
  4. Passez en enforce et changez l'id. Allongez ensuite max_age (les RFC attendent des valeurs de l'ordre de semaines ou plus).

Pour retirer MTA-STS : publiez mode: none avec un nouvel id, attendez que le max_age précédent soit écoulé, puis supprimez les enregistrements. Supprimer d'un coup laisse l'ancienne politique active dans les caches des expéditeurs.

Voir aussi le vérificateur SPF, DKIM et DMARC et l'alignement DMARC.