Qu’est-ce que le MTA-STS ?
MTA-STS (Mail Transfer Agent Strict Transport Security) permet à un domaine de déclarer que les connexions SMTP entrantes doivent utiliser TLS avec un certificat valide. Il combine un enregistrement DNS TXT sur _mta-sts.yourdomain.com avec un fichier de stratégie servi via HTTPS sur mta-sts.yourdomain.com/.well-known/mta-sts.txt. L'enregistrement DNS annonce qu'une stratégie existe et porte un identifiant qui change chaque fois que la stratégie est mise à jour.
Sans MTA-STS, le TLS opportuniste de SMTP peut être supprimé silencieusement par un attaquant sur le chemin, forçant ainsi la livraison du courrier en texte brut. MTA-STS comble cette lacune en demandant aux serveurs d'envoi de refuser la livraison si TLS ne peut pas être négocié. Il s'associe naturellement à TLS-RPT, qui vous envoie des rapports par courrier électronique lorsqu'un expéditeur ne peut pas honorer la politique. La norme est définie dans la RFC 8461.
Pourquoi vérifier votre dossier MTA-STS ?
1Confirmez que la stratégie est détectable
Si l'enregistrement DNS est manquant ou mal formé, les expéditeurs ne recherchent jamais votre fichier de stratégie : vérifiez qu'il est résolu.
2Attrapez une identité qui ne change jamais
L'identifiant doit être mis à jour à chaque changement de politique, sinon les caches servent une politique obsolète : un vérificateur fait apparaître la valeur actuelle.
3Empêcher les rétrogradations TLS silencieuses
Un dossier de travail signale aux expéditeurs qu'ils doivent exiger le cryptage, protégeant ainsi le courrier en transit contre toute interception.
4Valider avant d'appliquer le mode
Confirmez que l'enregistrement et la politique s'alignent en mode test afin que le passage à l'application ne renvoie pas le courrier légitime.
Comment fonctionne MTA-STS – étape par étape
Vous hébergez un fichier de stratégie sur https://mta-sts.yourdomain.com/.well-known/mta-sts.txt décrivant le mode, les hôtes MX et max_age.
Vous publiez un enregistrement TXT sur _mta-sts.yourdomain.com contenant la version et un identifiant unique.
Un serveur d'envoi sur le point de transmettre des requêtes de courrier électronique enregistrées par TXT et voyant une stratégie est annoncé.
Il récupère le fichier de stratégie HTTPS, valide le MX récepteur et son certificat TLS par rapport à celui-ci.
Si la stratégie est en mode application et que TLS ne peut pas être validé, l'expéditeur refuse de livrer plutôt que de revenir au texte en clair.
Syntaxe d'enregistrement MTA-STS
_mta-sts.example.com. 3600 IN TXT "v=STSv1; id=20240118T120000Z"
# https://mta-sts.example.com/.well-known/mta-sts.txt
version: STSv1
mode: enforce
mx: mail.example.com
max_age: 604800Répartition des balises DNS
v=STSv1— version du protocole, toujours en premieridentifiant =— jeton unique, changements à chaque mise à jour de la politiqueChamps du fichier de stratégie
Pannes et correctifs courants du MTA-STS
Fichier de stratégie inaccessible
Le fichier .well-known doit être chargé via HTTPS avec un certificat valide : corrigez l'hôte avant que les expéditeurs puissent l'appliquer.
Identifiant périmé
Oublier de modifier l'identifiant après avoir modifié la politique oblige les expéditeurs à conserver l'ancien - le modifier à chaque mise à jour
Inadéquation MX
Si les entrées MX ne correspondent pas à vos enregistrements MX réels, le mode Appliquer bloque le courrier légitime – gardez-les synchronisés.
Sauter directement pour faire respecter
Commencez les tests avec TLS-RPT afin de détecter les problèmes avant que le mode d'application ne puisse renvoyer les messages
Foire aux questions
MTA-STS (Mail Transfer Agent Strict Transport Security) permet à votre domaine d'indiquer aux serveurs d'envoi que le courrier doit être livré via TLS avec un certificat valide. Il combine un enregistrement DNS TXT sur _mta-sts.yourdomain.com avec un fichier de stratégie hébergé par HTTPS. Sans cela, le cryptage opportuniste de SMTP peut être supprimé par un attaquant sur le chemin réseau, obligeant votre courrier à voyager en texte brut.
L'enregistrement TXT sur _mta-sts.yourdomain.com contient deux éléments : la version (v=STSv1) et un identifiant – un jeton unique que vous devez modifier à chaque fois que vous mettez à jour le fichier de stratégie. L'enregistrement ne contient pas la politique elle-même ; il annonce simplement qu'une politique existe et signale, via un identifiant modifié, quand les expéditeurs doivent la récupérer à nouveau.
Le mode est défini dans le fichier de stratégie HTTPS, et non dans l'enregistrement DNS. En mode test, les expéditeurs signalent les échecs TLS (via TLS-RPT) mais continuent de livrer le courrier, vous permettant de trouver les problèmes en toute sécurité. En mode appliqué, les expéditeurs refusent de livrer si TLS ne peut pas être validé. La meilleure pratique consiste à exécuter d'abord des tests avec les rapports activés, puis à passer à l'application une fois que vous avez confirmé que tout fonctionne.
Les deux nécessitent TLS pour le courrier entrant, mais ils ancrent la confiance différemment. DANE utilise les enregistrements DNSSEC et TLSA pour épingler les certificats, cela dépend donc du déploiement du DNSSEC. MTA-STS utilise la PKI Web publique et une politique hébergée par HTTPS, il fonctionne donc sans DNSSEC. De nombreux domaines adoptent d'abord MTA-STS car il est plus simple à déployer sur l'infrastructure existante.
Les raisons courantes sont un enregistrement TXT manquant ou mal formé, un identifiant qui n'a pas été mis à jour après un changement de stratégie ou un fichier de stratégie qui ne se charge pas via HTTPS avec un certificat valide. Ce vérificateur vérifie l'enregistrement DNS ; confirmez également que le fichier /.well-known/mta-sts.txt est accessible et que ses entrées mx correspondent à vos vrais enregistrements MX.