Comment vérifier MTA-STS avant de passer en mode enforce

Avant de faire passer MTA-STS de testing à enforce, vérifiez quatre choses : l'enregistrement _mta-sts, le fichier de politique, que chaque hôte MX est couvert par la politique, et que les rapports TLS-RPT ne montrent aucun échec. Collez vos domaines dans le vérificateur MTA-STS en masse pour les trois premières ; vos rapports TLS-RPT couvrent la quatrième.

Vérifier MTA-STS sur une liste de domaines →

Les vérifier en masse

1. Ouvrez le vérificateur MTA-STS en masse.
2. Collez les domaines, un par ligne : jusqu'à 100 par passage, ou 500 après une connexion Google gratuite.
3. Cliquez sur Check MTA-STS (vérifier MTA-STS). Les enregistrements _mta-sts et _smtp._tls et les enregistrements MX de chaque domaine sont lus, et le fichier de politique est récupéré une fois en HTTPS.
4. Lisez chaque ligne : Enforced, Testing, Off, Broken ou Not set up, avec le mode, max_age, tout hôte MX que la politique ne couvre pas et l'adresse TLS-RPT.
5. Tout domaine marqué Broken, ou avec un MX non couvert, n'est pas prêt pour le mode enforce.

Le faire à la main

L'enregistrement et le fichier de politique, ici pour un domaine en mode testing :

dig +short txt _mta-sts.fastmail.com
# "v=STSv1; id=20260728T132000"

curl -s https://mta-sts.fastmail.com/.well-known/mta-sts.txt
# version: STSv1
# mode: testing
# mx: *.messagingengine.com
# max_age: 86400

Vérifiez ensuite chaque hôte MX par rapport aux lignes mx: de la politique (à lancer avec bash) :

d=fastmail.com
pol=$(curl -s https://mta-sts.$d/.well-known/mta-sts.txt | tr -d '\r')
for mx in $(dig +short mx $d | awk '{print $2}' | sed 's/\.$//'); do
  ok=no
  for p in $(echo "$pol" | awk '/^mx:/{print $2}'); do
    [ "$mx" = "$p" ] && ok=yes
    [ "${p#\*.}" != "$p" ] && [ "${mx#*.}" = "${p#\*.}" ] && ok=yes
  done
  echo "$mx covered=$ok"
done
# in2-smtp.messagingengine.com covered=yes
# in1-smtp.messagingengine.com covered=yes

Et le certificat que présente chaque MX, dont dépend la politique :

openssl s_client -starttls smtp -connect in1-smtp.messagingengine.com:25 \
  -verify_hostname in1-smtp.messagingengine.com -verify_return_error -brief < /dev/null 2>&1 | grep -E "Verification|Peer certificate"
# Peer certificate: CN=*.messagingengine.com
# Verification: OK

Nous avons lancé ces commandes le 9 novembre 2026. Le test du joker suit la RFC 8461, section 4.1 : *.example.com correspond à mail.example.com "but not example.com or foo.bar.example.com" (mais pas à example.com ni à foo.bar.example.com). Beaucoup de réseaux domestiques et de bureau bloquent le port 25 sortant, donc l'étape openssl peut devoir être lancée depuis un serveur. Le vérificateur en masse ne teste pas les certificats MX ; cette commande, si.

Ce qu'il faut corriger avant le mode enforce

• Un MX non couvert. Ajoutez-lui une ligne mx:. La RFC 8461, section 5 indique qu'en mode enforce, les expéditeurs "MUST NOT deliver the message to hosts that fail MX matching or certificate validation or that do not support STARTTLS." (ne doivent pas livrer le message aux hôtes qui échouent à la correspondance MX ou à la validation du certificat, ou qui ne prennent pas en charge STARTTLS). Cela coince après l'ajout d'un MX de secours ou un changement de fournisseur de messagerie.
• Le fichier de politique ne se charge pas. Il doit répondre HTTP 200 sur mta-sts.<domain> avec un certificat valide pour ce nom. La RFC indique que "HTTP 3xx redirects MUST NOT be followed" (les redirections HTTP 3xx ne doivent pas être suivies), donc une redirection vers www équivaut à aucune politique.
• Pas de TLS-RPT. Publiez _smtp._tls.<domain> avec v=TLSRPTv1; rua=mailto:... (RFC 8460). En mode testing, les rapports sont le seul moyen de voir les échecs.
• Le basculement. Changez d'abord mode: testing en mode: enforce dans le fichier de politique, puis modifiez l'id dans l'enregistrement TXT pour que les expéditeurs récupèrent la nouvelle politique. La section 8.1 donne cet ordre, pour que les expéditeurs n'associent jamais un nouvel id à l'ancien fichier. max_age peut valoir au plus 31557600 secondes (un an) ; la RFC 8461 s'attend à des semaines ou plus une fois que vous êtes sûr de vous.

La plupart des domaines ne publient pas du tout MTA-STS ; voir notre étude sur l'adoption de MTA-STS. Pour rédiger les enregistrements, utilisez le générateur MTA-STS.

Étape suivante : vérifier les adresses auxquelles vous écrivez

MTA-STS protège les emails qui arrivent vers votre domaine. Les rebonds qui nuisent à vos envois viennent des adresses de votre propre liste. Importez-la sur /verify pour vérifier chaque boîte sans rien envoyer. Les 100 premières vérifications sont gratuites avec une connexion Google, sans carte.

Pro, 39 $ par mois : vérification d'emails illimitée.* Jamais décomptée, jamais coupée. Voir les tarifs.

*Usage raisonnable : les 100 000 premières vérifications du mois à pleine vitesse, puis plus lentement, jamais coupées.

À lire aussi : auditer l'authentification email de votre domaine, SPF, DKIM et DMARC expliqués.