Objectif
Renforcer le transport SMTP entrant d’un domaine avec MTA-STS tout en obtenant de la visibilité grâce à TLS-RPT. La procédure commence par vérifier que tous les MX légitimes proposent STARTTLS avec un certificat Web PKI valide, publie ensuite une policy MTA-STS en mode testing avec un max_age prudent, active les rapports TLS, puis ne passe en enforce qu’après validation des flux et des rapports.
Prérequis
- Contrôle de la zone DNS du domaine destinataire et de tous les enregistrements MX.
- Accès à l’hébergement HTTPS de mta-sts.<domaine> avec certificat Web PKI valide.
- Inventaire des MX actifs et de leurs certificats SMTP STARTTLS.
- Adresse dédiée ou service capable de recevoir et analyser les rapports TLS-RPT.
- Fenêtre de changement et possibilité de modifier rapidement la policy et le TXT _mta-sts.
Procédure pas à pas
Inventorier les MX réellement publiés
Commencez par résoudre les MX du domaine depuis plusieurs résolveurs si l’infrastructure utilise un DNS externalisé. Pour chaque cible, notez priorité, FQDN, fournisseur et rôle. Retirez ou corrigez les anciens MX avant MTA-STS : une policy stricte doit décrire les serveurs légitimes que les expéditeurs peuvent utiliser. Vérifiez aussi qu’aucun relais de secours historique n’est encore publié sans être supervisé.
Resolve-DnsName -Type MX <DOMAINE>nslookup -type=mx <DOMAINE>- La liste des MX légitimes est exhaustive et les noms sont stables.
- Aucun MX obsolète ou non maîtrisé ne reste publié.
Tester STARTTLS et le certificat de chaque MX
MTA-STS exige que les serveurs conformes à la policy offrent TLS et présentent un certificat pouvant être validé pour le nom attendu. Testez chaque MX sur TCP 25 depuis un réseau autorisé. Avec OpenSSL, démarrez une session SMTP STARTTLS et contrôlez le sujet/SAN, l’émetteur, la date et la chaîne. Un certificat expiré, auto-signé ou ne couvrant pas le FQDN doit être corrigé avant tout mode enforce.
Test-NetConnection <MX-FQDN> -Port 25openssl s_client -starttls smtp -connect <MX-FQDN>:25 -servername <MX-FQDN> -verify_return_error- Tous les MX répondent sur TCP 25.
- STARTTLS fonctionne et la validation du certificat ne retourne pas d’erreur.
Préparer le sous-domaine HTTPS mta-sts
Créez mta-sts.<domaine> et faites-le pointer vers un serveur HTTPS stable. Le fichier doit être disponible à l’URL exacte /.well-known/mta-sts.txt. Servez-le comme texte, sans page HTML autour. Le certificat HTTPS doit être valide et renouvelé automatiquement. Le service doit rester joignable indépendamment du serveur de messagerie afin qu’une panne d’un MX ne rende pas simultanément la policy inaccessible.
Resolve-DnsName mta-sts.<DOMAINE>curl -I https://mta-sts.<DOMAINE>/.well-known/mta-sts.txt- Le nom mta-sts résout publiquement.
- L’URL répond en HTTPS sans erreur de certificat et sans authentification.
Publier une policy MTA-STS en mode testing
Commencez par une policy STSv1 en mode testing. Déclarez chaque MX autorisé avec une ligne mx:. Les jokers ne doivent être utilisés que s’ils correspondent réellement à l’architecture du fournisseur. Pendant le pilote, utilisez un max_age volontairement court, par exemple 86400 secondes, afin de limiter la durée d’une mauvaise policy en cache. Le fichier est constitué de paires clé/valeur sur des lignes séparées.
version: STSv1
mode: testing
mx: <MX1.EXEMPLE.NET>
mx: <MX2.EXEMPLE.NET>
max_age: 86400curl https://mta-sts.<DOMAINE>/.well-known/mta-sts.txt- La policy contient exactement les MX autorisés.
- Le fichier téléchargé publiquement correspond au contenu attendu.
Publier le TXT _mta-sts avec un identifiant de version
Ajoutez le TXT _mta-sts.<domaine> avec v=STSv1 et un id unique représentant cette version de policy. L’id n’est pas un numéro de version ordonné : il doit simplement changer chaque fois que la policy change afin d’inciter les expéditeurs à la récupérer. Un horodatage UTC lisible simplifie l’exploitation. Vérifiez qu’il n’existe pas plusieurs TXT MTA-STS concurrents.
TXT _mta-sts.<DOMAINE> = "v=STSv1; id=20260810T140000Z;"Resolve-DnsName -Type TXT _mta-sts.<DOMAINE>- Un seul enregistrement MTA-STS est visible.
- L’id publié correspond à la version actuellement servie en HTTPS.
Activer TLS-RPT avant l’enforcement
Publiez le TXT _smtp._tls.<domaine> pour demander des rapports agrégés sur les échecs de négociation TLS et de validation de policy. Utilisez une boîte ou un service capable de traiter du JSON compressé et de gérer le volume reçu. Le mécanisme rua accepte notamment mailto: ou HTTPS selon RFC 8460. Évitez d’envoyer les rapports vers une boîte personnelle et appliquez les règles de conservation appropriées.
TXT _smtp._tls.<DOMAINE> = "v=TLSRPTv1; rua=mailto:tlsrpt@<DOMAINE>"Resolve-DnsName -Type TXT _smtp._tls.<DOMAINE>- Le TXT TLS-RPT est publié sous _smtp._tls.
- La destination de rapports accepte les messages ou requêtes prévues.
Observer les rapports et corriger tous les échecs légitimes
Laissez le mode testing fonctionner pendant plusieurs cycles de trafic représentatifs. Analysez les erreurs certificate-host-mismatch, certificate-expired, starttls-not-supported, sts-policy-invalid ou policy-fetch-error. Pour chaque échec, déterminez s’il concerne un vrai expéditeur, un MX légitime ou un scanner externe. Ne passez pas en enforce tant qu’un chemin de réception légitime présente des erreurs récurrentes.
- Les rapports ne montrent plus d’échec structurel sur les MX légitimes.
- Les anomalies sont reliées à une cause et documentées.
Passer progressivement en mode enforce
Lorsque les MX, certificats et rapports sont stables, remplacez mode: testing par mode: enforce. Gardez d’abord un max_age prudent et changez l’id du TXT _mta-sts. Après quelques jours sans incident, augmentez max_age selon votre politique. Le passage en enforce signifie que les expéditeurs compatibles doivent refuser une livraison qui ne respecte pas la policy au lieu de rétrograder silencieusement en SMTP non conforme.
version: STSv1
mode: enforce
mx: <MX1.EXEMPLE.NET>
mx: <MX2.EXEMPLE.NET>
max_age: 604800TXT _mta-sts.<DOMAINE> = "v=STSv1; id=20260817T090000Z;"- La nouvelle policy est récupérable et son id a changé.
- Les rapports TLS-RPT restent stables après enforcement.
Superviser le certificat, le HTTPS et les MX dans la durée
Ajoutez des contrôles sur l’expiration des certificats SMTP et HTTPS, la disponibilité du fichier, la résolution DNS et les rapports TLS-RPT. Une future migration de passerelle ou de MX doit inclure la mise à jour MTA-STS avant la bascule. Conservez l’historique des ids et des policies pour pouvoir expliquer un rejet de transport survenu pendant une période donnée.
curl -fsS https://mta-sts.<DOMAINE>/.well-known/mta-sts.txtResolve-DnsName -Type MX <DOMAINE>Resolve-DnsName -Type TXT _mta-sts.<DOMAINE>- La supervision détecte une policy inaccessible, un certificat proche de l’expiration ou un changement de MX.
Validation
La procédure est validée lorsque :
- Tous les MX publiés proposent STARTTLS avec un certificat valide pour leur nom.
- La policy HTTPS STSv1 est accessible sur le chemin standard et reflète les MX légitimes.
- Les TXT _mta-sts et _smtp._tls sont uniques et valides.
- Les rapports TLS-RPT ne montrent plus d’échecs structurels avant et après le passage en enforce.
- Le renouvellement des certificats et toute modification future de MX sont intégrés à la supervision.
Retour arrière
- Si un incident apparaît pendant le pilote, conserver mode: testing ou remettre une policy prudente et changer immédiatement l’id _mta-sts.
- Si enforce provoque des échecs légitimes, corriger d’abord le MX/certificat ; si un retour est nécessaire, publier une policy mode: none ou testing selon le plan et incrémenter l’id.
- Tenir compte du cache : les expéditeurs ayant encore une ancienne policy peuvent continuer à l’appliquer jusqu’à expiration de max_age.
- TLS-RPT peut rester actif pendant le rollback afin de conserver la visibilité sur les erreurs de transport.
Dépannage / erreurs fréquentes
- policy-fetch-error : vérifier DNS mta-sts, certificat HTTPS, chaîne, redirections et disponibilité de /.well-known/mta-sts.txt.
- certificate-host-mismatch : comparer les lignes mx: de la policy aux SAN du certificat présenté sur TCP 25.
- starttls-not-supported : confirmer que le bon MX répond et que STARTTLS n’est pas supprimé par un équipement intermédiaire.
- Aucun rapport TLS-RPT : vérifier le TXT _smtp._tls, l’adresse rua, les filtres antispam de la boîte de rapports et simplement le fait qu’aucun expéditeur compatible n’ait encore envoyé de rapport.
- Un nouveau MX doit être ajouté : publier d’abord la policy qui l’autorise et le certificat valide, changer l’id, attendre la propagation puis basculer le trafic.