MTA-STS : définition et sécurisation de SMTP par TLS

Quelles sont les exigences ?

Le domaine publie un enregistrement de découverte MTA-STS

La RFC 8461 définit un enregistrement TXT à _mta-sts sous le domaine de la politique. Il contient v=STSv1 et une valeur id. L’id signale que la politique a pu changer : un expéditeur peut alors décider d’en récupérer une nouvelle.

_mta-sts.yourdomain.com. IN TXT "v=STSv1; id=20260811"

Ceci n’est qu’un exemple. Ne prenez pas l’id d’exemple pour une procédure. Changez l’id quand la politique change, et tenez compte des caches DNS et de politique avant de supposer que chaque expéditeur compatible a récupéré la nouvelle politique.

Un enregistrement DNS seul ne suffit pas. Il indique à l’expéditeur où se trouve MTA-STS, mais le mode d’application, les motifs MX et la durée de cache sont dans la politique HTTPS.

Le domaine héberge sa politique en HTTPS

La RFC 8461 fixe une URL de récupération HTTPS :

https://mta-sts.yourdomain.com/.well-known/mta-sts.txt

Le fichier contient version, mode, un ou plusieurs champs mx, et max_age.

version: STSv1
mode: testing
mx: mail.yourdomain.com
max_age: 86400

Cette politique n’est qu’un exemple. Remplacez l’hôte d’exemple par le vrai hôte MX de réception ou un motif générique pris en charge, après avoir vérifié l’infrastructure de messagerie en production.

L’hôte de la politique doit offrir un HTTPS validable par un expéditeur compatible. Les champs mx désignent les hôtes autorisés à recevoir les e-mails selon la politique. Ils ne créent pas de routage et ne remplacent pas les MX DNS du domaine.

Le mode fixe le comportement demandé à l’expéditeur

La RFC 8461 définit les modes enforce, testing et none.

• enforce indique à un expéditeur compatible que la livraison exige une connexion TLS valide vers un hôte MX conforme à la politique.
• testing demande à un expéditeur compatible d’évaluer la politique et de signaler les échecs, tout en livrant normalement.
• none indique à un expéditeur compatible que le domaine ne demande pas l’application de MTA-STS avec la politique actuelle.

Ne passez pas à enforce avant que chaque hôte MX de production actif présente un certificat valide pour son nom d’hôte SMTP. Un écart peut retarder ou bloquer la livraison des expéditeurs compatibles.

Pour le détail du champ mode, voir le sens de mode dans une politique MTA-STS.

L’expéditeur met la politique en cache

Le champ max_age fixe combien de temps un expéditeur compatible peut garder une politique en cache. La RFC 8461 s’appuie sur ce cache pour protéger le transport si une recherche ultérieure échoue.

Une mise à jour n’est donc pas un interrupteur global immédiat. Planifiez les changements de MX, renouvellements de certificats et modifications de politique selon la durée de cache publiée. L’id DNS signale un changement, mais ne garantit pas que chaque expéditeur compatible l’a actualisée en même temps. Voir le sens de max_age dans une politique MTA-STS pour le comportement du cache.

Quand l’exigence entre-t-elle en vigueur ?

La RFC 8461 a été publiée en septembre 2018 comme norme proposée de l’IETF. C’est la spécification de référence de MTA-STS. Elle n’a remplacé aucune RFC MTA-STS antérieure et ne fixe pas de date d’application universelle pour tous les domaines.

La politique d’un domaine entre en jeu quand il publie l’enregistrement DNS et le fichier de politique requis, et qu’un système d’envoi compatible RFC 8461 lui livre des e-mails. Le comportement effectif dépend aussi du mode et de toute politique en cache chez l’expéditeur.

SMTP TLS Reporting : définition

SMTP TLS Reporting, ou TLS-RPT, est défini dans la RFC 8460, publiée en septembre 2018 comme norme proposée en même temps que MTA-STS. Ce mécanisme recueille des informations sur les connexions TLS que les expéditeurs établissent pour livrer des e-mails à un domaine : un expéditeur qui produit des rapports indique quelles sessions TLS ont réussi, lesquelles ont échoué et pourquoi, par exemple un échec de négociation TLS, un problème lié au DNS ou un problème dans la politique MTA-STS elle-même. TLS-RPT ne rend pas MTA-STS obligatoire, et le guide de la spécification TLS-RPT couvre la norme en détail.

Pour recevoir des rapports, le domaine publie un enregistrement TXT DNS à _smtp._tls qui indique où les envoyer, y compris l’URI qui les reçoit. L’analyse des rapports montre si les expéditeurs compatibles joignent le domaine par des connexions sécurisées et désigne les échecs à examiner.

Structure d’un rapport TLS

Les rapports TLS sont des fichiers JSON compressés en gzip, de type application/tlsrpt+json. Un rapport contient :

• ID de rapport : un identifiant unique attribué à chaque rapport, pour le suivre et le citer.
• Période : les dates de début et de fin de la période couverte.
• Nom de l’organisation : l’émetteur qui a généré le rapport.
• Contact : comment joindre l’émetteur en cas de question.
• Politiques : les politiques évaluées par l’expéditeur pour le domaine. La RFC 8460 en définit trois types : sts (MTA-STS), tlsa (DANE) et no-policy-found. Pour MTA-STS, cette section reprend le fichier de politique.
• Synthèse : le nombre total de sessions TLS réussies et échouées sur la période du rapport.
• Détails des échecs : le type de chaque échec, par exemple un échec de négociation TLS, un problème DNS ou un problème MTA-STS, ainsi que le serveur d’envoi, l’IP de réception et le nom d’hôte MX de la connexion échouée.

Comment mettre en œuvre l’exigence ?

1. Recensez tous les MX de réception en production

Récupérez les MX du domaine et listez chaque hôte qui peut recevoir des e-mails de production. Incluez les hôtes de secours actifs et tout hôte d’un fournisseur qui reçoit des e-mails pour le domaine.

Comparez la liste aux noms des certificats présentés lors de la négociation TLS SMTP. Une politique MTA-STS doit autoriser les hôtes réellement utilisés par les expéditeurs compatibles.

2. Vérifiez le TLS et les certificats de chaque hôte

Testez sur chaque hôte MX de production le TLS SMTP et la validation du certificat. Vérifiez que l’identité du certificat couvre le nom d’hôte joint par l’expéditeur.

Un résultat DNS public peut montrer les MX publiés, mais ne prouve pas le comportement réel du certificat sur chaque chemin d’envoi SMTP. Gardez les tests de livraison et les journaux du serveur pour enquêter sur un échec TLS.

3. Publiez le TXT DNS et la politique HTTPS

Publiez le TXT _mta-sts avec v=STSv1 et un nouvel id. Servez la politique au chemin HTTPS défini par la RFC.

Commencez en testing en comparant les champs mx aux enregistrements MX actifs, aux certificats TLS et aux chemins de secours. Changez l’id DNS à chaque modification de la politique.

4. Ajoutez TLS-RPT pour les rapports d’échec

Publiez TLS-RPT à part, selon les exigences de la RFC 8460 sur les rapports TLS SMTP. Envoyez les rapports à une boîte surveillée ou un point de traitement consulté par l’équipe.

Utilisez les rapports pour examiner les échecs de récupération de politique, de certificat et les écarts de MX. L’absence de rapport ne prouve pas que tous les systèmes d’envoi ont joint le domaine.

5. Passez à enforce quand les preuves le justifient

Ne passez à enforce que lorsque chaque hôte MX actif a réussi les contrôles TLS et certificat, que la politique HTTPS est joignable et que ses motifs MX correspondent au chemin de production.

Gardez un plan de repli. Si une migration MX ou un problème de certificat survient après l’application, ne rétablissez un mode sûr qu’après avoir identifié les hôtes touchés et l’impact sur la livraison.

Comment valider la conformité ?

Validez la conformité MTA-STS en cinq couches distinctes, de l’enregistrement DNS jusqu’aux preuves issues des envois réels :

• Vérifiez le DNS : confirmez que la réponse faisant autorité et au moins un résolveur public renvoient le TXT _mta-sts prévu.
• Vérifiez l’hôte de la politique : récupérez /.well-known/mta-sts.txt en HTTPS et confirmez que syntaxe, mode, motifs MX et max_age sont ceux prévus.
• Vérifiez le TLS SMTP : testez la négociation TLS et la validation du certificat de chaque MX actif, sous son nom de livraison.
• Vérifiez les preuves d’envoi : lisez les rapports TLS-RPT s’ils existent et les journaux SMTP ou traces de livraison du vrai chemin d’envoi.
• Vérifiez dans la durée : recontrôlez après tout changement de MX, certificat, DNS ou fournisseur.

Un test public peut repérer les erreurs de configuration MTA-STS publiée. Il ne peut pas prouver que chaque expéditeur de production prend en charge MTA-STS, tester en continu chaque chemin SMTP, ni dire comment un fournisseur donné a traité un message précis.

Vérifiez la politique MTA-STS publiée avant de l’appliquer

Passez le domaine de réception dans le test MTA-STS pour inspecter l’enregistrement DNS et la politique HTTPS publiés. Comparez le résultat à l’inventaire MX réel du domaine et aux preuves TLS SMTP avant de passer de testing à enforce.

Pour qui gère de nombreux domaines, Palisade est un logiciel DMARC agentique : il analyse les rapports agrégés DMARC, repère les problèmes d’authentification et d’alignement et crée des tickets de correction priorisés. Il peut aider à organiser l’authentification des expéditeurs dans un programme plus large de sécurité des domaines, un humain examinant les preuves et appliquant les changements de politique.

Commencez avec Palisade

Palisade peut aussi héberger la politique MTA-STS d’un domaine par délégation CNAME : l’agent propose les changements, un humain les approuve avant toute application. Il ne prouve pas le comportement TLS SMTP de chaque expéditeur et ne garantit pas la livraison future.