Vérificateur de politique MTA-STS

Récupère l'enregistrement TXT _mta-sts et le fichier de politique mta-sts.txt d'un domaine pour diagnostiquer si le chiffrement TLS obligatoire du transport des e-mails (MTA-STS) est correctement configuré.

Dernière mise à jour : 2026-09-20

Diagnostiquer le TLS imposé à la remise du courrier (MTA-STS)

Le chiffrement dans SMTP est à l'origine une affaire facultative, tentée là où c'est possible, ce qui signifie qu'un attaquant interposé retirant l'annonce de STARTTLS peut ramener l'échange au texte clair. MTA-STS est l'arrangement qui ferme cette porte, **enjoignant aux serveurs expéditeurs que le courrier destiné au domaine passe par TLS.** Cet outil récupère à la fois l'enregistrement TXT `_mta-sts` et le fichier de politique, et rapporte si la configuration est complète.

**Ce qui déroute dans cet arrangement, c'est que la politique elle-même ne réside pas dans le DNS.** Tout ce que porte l'enregistrement TXT est un `id` marquant la version ; **la substance est servie en HTTPS depuis `https://mta-sts.votredomaine/.well-known/mta-sts.txt`.** La confiance de ce mécanisme repose donc sur les certificats web et non sur le DNS. **Et l'endroit où l'on s'enlise le plus souvent est de laisser `mode` à `testing`.** Dans cet état la remise passe malgré un échec de TLS, et **l'obligation ne prend effet qu'une fois la valeur à `enforce`.** L'ordre d'adoption établi consiste à demeurer à `testing`, à suivre les rapports TLS-RPT jusqu'à s'assurer que rien ne casse, et à ne passer qu'ensuite à `enforce`.

Comment s'en servir

Saisissez le domaine Indiquez le seul domaine, sous la forme `example.com`.
Contrôlez l'enregistrement TXT **Cherchez `v=STSv1` et un `id=`.** L'`id` se change à chaque mise à jour de la politique.
Lisez le contenu du fichier de politique Trois entrées y figurent : `mx`, `max_age` et `mode`.
Confirmez le mode **À `testing`, rien n'est imposé.** C'est `enforce` qui donne effet à la politique.

Astuces pour en tirer le meilleur parti

MTA-STS est vérifié par le serveur expéditeur, pas par le destinataire. Une fois publié, les serveurs tiers exigeront TLS pour envoyer du courrier vers votre domaine.
Déployez d'abord en mode testing pendant quelques semaines à un mois avant de passer en enforce, afin d'éviter une mauvaise surprise en cas de rejet de remise inattendu.
max_age est généralement fixé entre 604800 secondes (7 jours) et 31557600 secondes (1 an). Une valeur trop courte oblige à récupérer le fichier de politique plus fréquemment.
Un caractère générique (*.example.com) est utilisable dans le champ mx, mais le SAN (Subject Alternative Name) du certificat TLS doit correspondre à ce générique.
Publier uniquement l'enregistrement DNS ou uniquement le fichier de politique n'a aucun effet : MTA-STS ne s'active que lorsque les deux sont présents simultanément.

Dans quels cas s'en servir

Pour inspecter votre propre domaine

**Le mécanisme réclamant à la fois le DNS et HTTPS, vous découvrez laquelle des deux moitiés manque.**

Pour vérifier avant de passer à enforce

Les erreurs de configuration se dissipent tant que l'on demeure à `testing`.

Pour revoir après l'ajout d'un MX

**Oublier d'ajouter un nouvel hôte MX à la liste `mx` de la politique fait refuser la remise vers cet hôte.**

Pour savoir où en est un correspondant

Vous voyez s'il impose TLS pour son propre courrier.

Vocabulaire de MTA-STS

_mta-sts TXT: **L'enregistrement DNS portant l'`id` qui marque la version de la politique.** La politique elle-même n'y réside pas.
Fichier de politique: La substance, placée à `https://mta-sts.votredomaine/.well-known/mta-sts.txt`. **Servie en HTTPS, elle réclame un certificat valide.**
Mode: L'un de `enforce`, `testing` ou `none`. **Sous `testing`, le courrier est remis même quand le contrôle échoue.**
Max_age: Combien de secondes un expéditeur peut garder la politique en cache. Une valeur plus longue renforce la protection mais ralentit la diffusion de tout changement.
Mx: La liste des hôtes MX auxquels TLS doit être imposé. **La remise vers un hôte absent de cette liste est refusée.**
Rétrogradation de STARTTLS: L'attaque où un interposé retire l'annonce de STARTTLS pour imposer le texte clair. **MTA-STS a été conçu pour l'empêcher.**

Questions fréquentes

Pas nécessairement : la plupart des domaines n'utilisent pas encore MTA-STS. Mais si vous souhaitez renforcer la protection contre les attaques de STARTTLS stripping, il vaut la peine d'envisager son adoption.

SPF, DKIM et DMARC authentifient l'expéditeur pour empêcher l'usurpation. MTA-STS n'a aucun rapport avec l'authentification de l'expéditeur : il impose le chiffrement TLS sur le trajet de transport lui-même, se défendant contre un type de menace différent.

Pas sur votre propre domaine, mais à l'adresse /.well-known/mta-sts.txt d'un sous-domaine préfixé par « mta-sts. » (par exemple mta-sts.example.com), servi avec un certificat TLS valide.

Ce n'est pas recommandé. Faites tourner le mode testing pendant quelques semaines à un mois, surveillez la remise avec TLS-RPT, et ne passez en enforce que lorsque vous êtes sûr qu'aucun rejet inattendu ne se produira.

Cet outil vérifie uniquement la syntaxe et les champs obligatoires de l'enregistrement TXT et du fichier de politique. Il ne valide ni le certificat TLS ni n'effectue de véritable négociation TLS avec les hôtes MX listés ; pour une vérification plus stricte, combinez-le avec un outil spécialisé comme checktls.com.

Anecdote — Pourquoi STARTTLS ne suffisait pas et comment MTA-STS est né

Pendant des décennies, le chiffrement en transit de SMTP a reposé sur STARTTLS (normalisé en 1999), qui ouvre la connexion en clair avant de basculer vers TLS. En 2014, des chercheurs en sécurité ont confirmé des attaques réelles de « STARTTLS stripping » : comme la négociation STARTTLS elle-même se déroule avant que le chiffrement n'entre en jeu, un attaquant présent sur le trajet pouvait réécrire la réponse du serveur pour masquer sa prise en charge de STARTTLS, incitant l'autre partie à revenir au texte en clair.

La cause profonde tenait au fait que STARTTLS était délibérément conçu pour revenir au texte en clair lorsque l'autre partie ne prenait pas TLS en charge — une fonctionnalité de compatibilité que les attaquants pouvaient exploiter en feignant simplement l'absence de support TLS. Vers 2015, les propres mesures de Google ont montré que le STARTTLS stripping se produisait à grande échelle dans certains pays et chez certains fournisseurs d'accès.

MTA-STS (RFC 8461, publié en 2018) fut la réponse de l'industrie, développée conjointement par Google, Microsoft, Yahoo et d'autres. Un domaine déclare sa prise en charge de MTA-STS via un enregistrement TXT du DNS, puis publie un fichier de politique récupéré en HTTPS listant les hôtes MX autorisés et les exigences TLS. Une fois récupérée, la politique est mise en cache pendant max_age, ce qui permet de détecter et de rejeter une tentative de rétrogradation ultérieure au lieu de l'accepter silencieusement.

MTA-STS est souvent associé à TLS-RPT (TLS Reporting, RFC 8460), qui permet aux propriétaires de domaine de recevoir des rapports lorsqu'un serveur expéditeur échoue à établir une connexion TLS. MTA-STS assure l'application forcée, TLS-RPT l'observabilité — utiliser les deux ensemble est aujourd'hui la pratique recommandée.

Voir toutes les anecdotes