Vérifiez votre configuration MTA-STS

Saisissez votre domaine pour vérifier à la fois l'enregistrement DNS et le fichier de politique hébergé sur votre domaine.

Qu'est-ce que MTA-STS ?

MTA-STS (Mail Transfer Agent Strict Transport Security) est une norme de sécurité e-mail définie dans la RFC 8461 qui permet aux domaines de déclarer qu'ils prennent en charge le chiffrement TLS pour le courrier entrant et que les serveurs d'envoi doivent refuser de remettre les messages sur des connexions non chiffrées.

Sans MTA-STS, le courrier entre serveurs peut être intercepté par des attaques de type man-in-the-middle qui suppriment le chiffrement TLS - même si les deux serveurs le prennent en charge. C'est ce qu'on appelle une attaque par rétrogradation TLS. MTA-STS empêche cela en indiquant aux serveurs d'envoi d'exiger TLS et de valider le certificat.

MTA-STS comporte deux composants : un enregistrement DNS TXT à _mta-sts.votredomaine.com et un fichier de politique hébergé à https://mta-sts.votredomaine.com/.well-known/mta-sts.txt.

Configuration de la politique

Modes de politique MTA-STS

enforce

Le courrier qui ne peut être remis sur une connexion TLS valide est rejeté. C'est le mode le plus strict et il offre une protection maximale contre les attaques par rétrogradation.

testing

Les échecs TLS sont signalés via TLS-RPT mais le courrier est tout de même remis. Idéal pour un déploiement initial afin d'identifier les problèmes avant d'appliquer la politique.

none

MTA-STS est de fait désactivé. Aucune exigence TLS n'est communiquée aux serveurs d'envoi. Utilisé pour désactiver une politique précédemment publiée.

Étape par étape

Comment fonctionne MTA-STS

Découverte DNS

Le serveur d'envoi interroge _mta-sts.votredomaine.com pour un enregistrement TXT contenant v=STSv1; id=20240101.

Récupération de la politique

Si l'enregistrement TXT existe, l'expéditeur récupère le fichier de politique depuis https://mta-sts.votredomaine.com/.well-known/mta-sts.txt via HTTPS.

Application TLS

Selon le mode de la politique, l'expéditeur soit impose TLS (rejette les échecs), soit signale les échecs (mode testing), soit ne fait rien (mode none).

Validation MX

Le fichier de politique précise quels hôtes MX sont valides. L'expéditeur vérifie que le certificat du serveur MX correspond à l'un des hôtes autorisés avant la remise.

Référence RFC 8461

MTA-STS est défini dans la RFC 8461 (septembre 2018). Il complète la RFC 8460 (SMTP TLS Reporting) qui offre de la visibilité sur les échecs de connexion TLS.

Exemple de fichier de politique MTA-STS :

version: STSv1
mode: enforce
mx: mail.example.com
mx: *.example.com
max_age: 604800

Lire vos résultats

Comprendre votre vérification MTA-STS

MTA-STS est inhabituel parmi les enregistrements e-mail car il réside en deux endroits à la fois - un enregistrement DNS et un fichier de politique hébergé sur le web - et les deux doivent concorder. C'est pourquoi la plupart des problèmes MTA-STS sont des incohérences de configuration plutôt que des enregistrements manquants.

Ce que valide le vérificateur

Un contrôle complet confirme que quatre éléments s'accordent : l'enregistrement TXT _mta-sts existe et porte un id valide, le fichier de politique est accessible en HTTPS à mta-sts.votredomaine.com/.well-known/mta-sts.txt avec un certificat de confiance, le mode de la politique correspond à votre intention, et les hôtes mx qu'il liste correspondent bien à vos enregistrements MX publiés. Si l'un d'eux est incorrect, les serveurs d'envoi ne peuvent pas appliquer votre politique.

Échecs MTA-STS courants

Enregistrement TXT mais pas de fichier de politique. L'enregistrement DNS pointe vers une politique qui n'est pas servie - les expéditeurs reviennent à l'absence d'application.
Fichier de politique pas en HTTPS valide. Le sous-domaine mta-sts a besoin de son propre certificat TLS de confiance ; un certificat auto-signé ou expiré fait échouer la récupération.
Incohérence MX. Les lignes mx de la politique ne correspondent pas à vos vrais hôtes MX, donc des serveurs de messagerie valides échouent à la validation du certificat.
Bloqué en testing ou none. La politique est publiée mais n'applique pas réellement TLS.
id inchangé. Après modification de la politique, l'id de l'enregistrement DNS doit changer, sinon les expéditeurs conservent l'ancienne version en cache.

Déployer en toute sécurité : testing avant enforce

Déployez MTA-STS par étapes. Publiez d'abord avec mode: testing et associez-le à TLS-RPT afin de recevoir des rapports d'éventuels échecs TLS sans bloquer le courrier. Une fois les rapports propres et votre liste MX confirmée, passez à mode: enforce. Fixez un max_age raisonnable (une semaine est courante) pour que les expéditeurs mettent la politique en cache tout en récupérant les changements dans une fenêtre sensée.

MTA-STS et TLS-RPT fonctionnent ensemble

MTA-STS impose une remise chiffrée ; TLS-RPT (RFC 8460) vous donne la visibilité pour faire confiance à cette application. Sans rapports, vous appliquez à l'aveugle - déployez les deux ensemble pour qu'un certificat cassé apparaisse sous forme de rapport plutôt qu'en courrier silencieusement rejeté.

Où MTA-STS s'insère dans votre pile e-mail

MTA-STS sécurise le courrier entrant en transit, mais il n'authentifie pas les expéditeurs - c'est le rôle de SPF, DKIM et DMARC côté sortant. Lancez le vérificateur d'authentification de domaine complet pour les voir tous à la fois, et gardez votre enregistrement SPF valide et sous la limite de 10 recherches avec AutoSPF pour que la moitié authentification de votre pile soit aussi solide que la moitié chiffrement. Si vous vous demandez pourquoi vérifier SPF régulièrement, la dérive due aux nouveaux expéditeurs en est la raison.

Complétez votre pile de sécurité e-mail

MTA-STS protège le TLS entrant. AutoSPF protège votre SPF sortant - en aplatissant automatiquement les enregistrements pour rester sous la limite de 10 recherches.

Démarrer l'essai gratuit→Voir les offres et tarifs

Vérificateur MTA-STS gratuit