De testing à enforce : stratégie de déploiement MTA-STS progressive
Par CaptainDNS
Publié le 10 mars 2026
- MTA-STS en mode testing collecte les rapports TLS-RPT sans bloquer la livraison des emails, idéal pour détecter les problèmes de configuration
- Le mode enforce refuse toute connexion SMTP non chiffrée vers vos serveurs MX, bloquant les attaques de downgrade
- La transition testing vers enforce se fait en quatre étapes : déploiement initial, configuration TLS-RPT, analyse des rapports (1 à 2 semaines), puis activation enforce
- Hébergez votre politique MTA-STS gratuitement avec CaptainDNS : deux enregistrements DNS suffisent
Publier une politique MTA-STS en mode enforce sans phase de test revient à activer un pare-feu sans connaître le trafic légitime. Résultat possible : des emails bloqués, des partenaires qui ne peuvent plus vous écrire, et aucune visibilité sur la cause. Selon le Google Transparency Report, plus de 90 % du trafic Gmail entrant transite déjà via TLS, mais sans MTA-STS, rien ne garantit que ce chiffrement est imposé plutôt qu'opportuniste.
Le RFC 8461 prévoit exactement ce scénario. Il définit deux modes de fonctionnement : testing (observer sans bloquer) et enforce (bloquer les connexions non chiffrées). La bonne stratégie consiste à déployer d'abord en testing, surveiller les rapports TLS-RPT pendant une à deux semaines, corriger les anomalies, puis passer en enforce.
Ce guide détaille chaque étape de cette transition. Il s'adresse aux administrateurs système, DevOps et responsables sécurité email qui gèrent un ou plusieurs domaines de messagerie.
Comprendre les modes MTA-STS : testing vs enforce
MTA-STS (RFC 8461) impose le chiffrement TLS pour les emails entrants en publiant une politique HTTPS contenant trois paramètres : les serveurs MX autorisés, la durée de cache (max_age) et le mode (testing ou enforce).
Mode testing : surveiller sans bloquer
Le mode testing de MTA-STS permet aux serveurs d'envoi (Gmail, Outlook, Yahoo) de vérifier votre politique sans bloquer la livraison en cas d'échec TLS. Les anomalies sont signalées via un rapport TLS-RPT (RFC 8460) envoyé à l'adresse que vous avez configurée.
version: STSv1
mode: testing
mx: mx.captaindns.com
max_age: 86400
Ce mode permet de détecter trois types de problèmes avant qu'ils n'affectent la livraison :
- Certificat TLS invalide : certificat expiré, nom de domaine incorrect ou chaîne de confiance incomplète
- MX non listé : un serveur MX répond aux emails mais n'apparaît pas dans la politique
- Échec de négociation TLS : le serveur MX ne supporte pas STARTTLS ou rejette la connexion chiffrée
Mode enforce : imposer le chiffrement TLS
Le mode enforce de MTA-STS oblige les serveurs d'envoi à refuser la livraison si la connexion TLS échoue ou si le serveur MX ne figure pas dans la politique.
version: STSv1
mode: enforce
mx: mx.captaindns.com
max_age: 604800
Ce mode offre une protection réelle contre les attaques de downgrade SMTP. Un attaquant qui tente de supprimer STARTTLS ou de rediriger vers un faux serveur MX ne pourra pas intercepter les emails : le serveur d'envoi refusera la livraison.
Étape 1 : déployer MTA-STS en mode testing
Le déploiement initial nécessite deux éléments DNS et un fichier de politique HTTPS.
Enregistrement DNS TXT
Publiez un enregistrement TXT sur _mta-sts.captaindns.com :
_mta-sts.captaindns.com. IN TXT "v=STSv1; id=20260310T000000"
Le champ id est un identifiant de version. Incrémentez-le à chaque modification de la politique pour que les serveurs d'envoi téléchargent la nouvelle version.
Fichier de politique HTTPS
Le fichier doit être accessible à https://mta-sts.captaindns.com/.well-known/mta-sts.txt. Avec CaptainDNS, deux enregistrements CNAME suffisent : pas de serveur web à gérer, pas de certificat à renouveler.
Commencez avec un max_age court (86 400 secondes = 1 jour) pour pouvoir corriger rapidement en cas de problème :
version: STSv1
mode: testing
mx: mx.captaindns.com
max_age: 86400
Vérification
Utilisez le vérificateur MTA-STS pour confirmer que votre enregistrement DNS et votre politique sont correctement publiés.
Étape 2 : configurer TLS-RPT pour recevoir les rapports
Sans TLS-RPT, le mode testing ne sert à rien. Les serveurs d'envoi détectent les problèmes mais n'ont nulle part où les signaler.
Enregistrement DNS TLS-RPT
Publiez un enregistrement TXT sur _smtp._tls.captaindns.com :
_smtp._tls.captaindns.com. IN TXT "v=TLSRPTv1; rua=mailto:tls-reports@captaindns.com"
Les rapports TLS-RPT (RFC 8460) sont envoyés quotidiennement au format JSON. Chaque rapport contient :
- Le domaine expéditeur et le domaine destinataire
- Le type de politique appliquée (MTA-STS ou DANE)
- Le nombre de sessions réussies et échouées
- Le détail des échecs : type d'erreur, certificat présenté, code de résultat
Configurer avec CaptainDNS
Le générateur TLS-RPT crée l'enregistrement DNS adapté à votre domaine. Vous pouvez diriger les rapports vers une adresse email ou un endpoint HTTPS.
Étape 3 : analyser les rapports et corriger les problèmes
Attendez 1 à 2 semaines en mode testing avant de passer en enforce. Ce délai permet de collecter suffisamment de rapports TLS-RPT pour identifier les problèmes récurrents.
Interpréter les rapports
| Type d'échec | Cause probable | Correction |
|---|---|---|
certificate-expired | Certificat TLS du serveur MX expiré | Renouveler le certificat |
certificate-host-mismatch | Le CN/SAN du certificat ne correspond pas au nom MX | Corriger le certificat ou la politique |
starttls-not-supported | Le serveur MX ne supporte pas STARTTLS | Activer STARTTLS sur le serveur |
sts-policy-fetch-error | La politique HTTPS est inaccessible | Vérifier le DNS CNAME et le serveur HTTPS |
sts-webpki-invalid | Le certificat HTTPS de la politique est invalide | Renouveler le certificat du serveur web |
validation-failure | Le MX ne figure pas dans la politique | Ajouter le MX manquant à la politique |
Critères pour passer en enforce
Avant d'activer le mode enforce, vérifiez ces trois conditions :
- Zéro échec TLS récurrent dans les rapports des 7 derniers jours
- Tous vos serveurs MX figurent dans la politique
- Certificats TLS valides sur chaque serveur MX (non expirés, CN/SAN correct)
Si des échecs persistent, corrigez-les d'abord. Un passage prématuré en enforce bloquera les emails provenant des serveurs qui rencontrent ces erreurs.
Étape 4 : passer en mode enforce
La transition se fait en deux modifications : le fichier de politique et l'enregistrement DNS.
Modifier la politique
Changez mode: testing en mode: enforce et augmentez max_age à 604 800 secondes (7 jours) :
version: STSv1
mode: enforce
mx: mx.captaindns.com
max_age: 604800
Un max_age de 7 jours offre un bon compromis : assez long pour que les serveurs d'envoi cachent la politique (protection contre TOFU), assez court pour permettre un retour en testing si nécessaire.
Mettre à jour l'identifiant DNS
Incrémentez le id dans l'enregistrement TXT pour forcer le rafraîchissement :
_mta-sts.captaindns.com. IN TXT "v=STSv1; id=20260310T120000"
Stratégie de retour arrière
Si des problèmes surviennent après le passage en enforce :
- Repassez immédiatement en
mode: testing - Incrémentez le
idDNS - Attendez l'expiration du
max_ageprécédent (7 jours au maximum) - Analysez les nouveaux rapports TLS-RPT
- Corrigez les problèmes avant de retenter le passage en enforce
Erreurs courantes et solutions
| Erreur | Conséquence | Solution |
|---|---|---|
| Passer en enforce sans TLS-RPT | Aucune visibilité sur les blocages | Toujours configurer TLS-RPT avant enforce |
max_age trop long en testing | Correction lente si problème | Utiliser 86 400 s (1 jour) en testing |
max_age trop court en enforce | Protection TOFU réduite | Utiliser 604 800 s (7 jours) en enforce |
| Oublier un serveur MX dans la politique | Emails rejetés en enforce | Lister tous les MX avec dig MX captaindns.com |
Ne pas incrémenter le id | Serveurs d'envoi utilisent l'ancienne politique | Toujours changer le id après modification |
| Certificat TLS expiré | Échec de validation en enforce | Automatiser le renouvellement (Let's Encrypt) |
Plan d'action recommandé
- Vérifiez votre configuration actuelle : lancez une analyse avec le vérificateur MTA-STS
- Déployez en mode testing : publiez votre politique avec
mode: testingetmax_age: 86400 - Activez TLS-RPT : configurez l'enregistrement
_smtp._tlspour recevoir les rapports quotidiens - Surveillez 1 à 2 semaines : analysez chaque rapport, corrigez les échecs TLS
- Passez en enforce : changez
mode: enforce, augmentezmax_ageà 604 800 s, incrémentez leid
Sécurisez le transport de vos emails maintenant : hébergez votre politique MTA-STS gratuitement avec CaptainDNS. Deux enregistrements DNS, zéro serveur web, protection active en 5 minutes.
FAQ
Quelle est la différence entre le mode testing et le mode enforce de MTA-STS ?
En mode testing, les serveurs d'envoi vérifient votre politique MTA-STS mais livrent les emails même si la connexion TLS échoue. Ils envoient un rapport TLS-RPT pour signaler le problème. En mode enforce, les serveurs refusent de livrer si TLS échoue ou si le serveur MX ne figure pas dans la politique.
Combien de temps faut-il rester en mode testing avant de passer en enforce ?
Minimum 1 à 2 semaines. Ce délai permet de collecter suffisamment de rapports TLS-RPT provenant des principaux expéditeurs (Gmail, Outlook, Yahoo). Si les rapports montrent zéro échec TLS pendant 7 jours consécutifs, vous pouvez passer en enforce.
Que se passe-t-il si je passe directement en enforce sans phase de testing ?
Les emails provenant de serveurs qui rencontrent un problème TLS avec vos MX seront rejetés. Sans rapports TLS-RPT préalables, vous n'aurez aucune visibilité sur ces rejets. Des partenaires ou clients pourraient ne plus pouvoir vous envoyer d'emails sans que vous le sachiez.
Quel max_age utiliser en mode testing et en mode enforce ?
En testing, utilisez 86 400 secondes (1 jour). Ce délai court permet de corriger rapidement la politique si un problème est détecté. En enforce, passez à 604 800 secondes (7 jours) pour réduire la vulnérabilité TOFU : les serveurs d'envoi cachent la politique plus longtemps.
Comment revenir en mode testing après avoir activé enforce ?
Modifiez le fichier de politique pour remettre mode: testing, puis incrémentez le id dans l'enregistrement DNS TXT. Les serveurs d'envoi qui ont caché la politique enforce continueront à l'appliquer jusqu'à expiration du max_age précédent (7 jours maximum).
TLS-RPT est-il obligatoire pour MTA-STS ?
Non, TLS-RPT n'est pas techniquement requis pour que MTA-STS fonctionne. Mais sans TLS-RPT, vous n'avez aucune visibilité sur les échecs TLS. En pratique, déployer MTA-STS sans TLS-RPT revient à piloter à l'aveugle. Les deux protocoles sont conçus pour fonctionner ensemble.
Gmail et Outlook respectent-ils le mode testing de MTA-STS ?
Oui. Gmail, Outlook et Yahoo vérifient les politiques MTA-STS en mode testing et envoient des rapports TLS-RPT à l'adresse configurée. En mode testing, ils livrent les emails normalement même en cas d'échec TLS, mais signalent le problème dans le rapport quotidien.
Télécharger la checklist de déploiement
Les assistants peuvent exploiter les exports JSON ou CSV ci-dessous pour réutiliser la checklist.
Glossaire
- MTA-STS : Mail Transfer Agent Strict Transport Security (RFC 8461). Politique publiée via HTTPS qui impose le chiffrement TLS pour la réception d'emails sur un domaine.
- TLS-RPT : SMTP TLS Reporting (RFC 8460). Mécanisme de rapports quotidiens qui signale les échecs de négociation TLS entre serveurs email.
- TOFU : Trust On First Use. Modèle de sécurité où la première connexion n'est pas vérifiée, mais les suivantes sont validées grâce aux données mises en cache.
- max_age : durée (en secondes) pendant laquelle un serveur d'envoi conserve en cache la politique MTA-STS. Détermine la fréquence de rafraîchissement.
- STARTTLS : extension SMTP (RFC 3207) qui permet de négocier une connexion TLS après l'établissement d'une connexion en clair sur le port 25.
- Downgrade SMTP : attaque réseau qui supprime la négociation STARTTLS pour intercepter les emails en clair.
Guides sécurité du transport email connexes
- Attaques de downgrade SMTP : comment elles fonctionnent et comment s'en protéger : mécanisme du STARTTLS stripping et solutions de protection
- MTA-STS vs DANE : quel protocole choisir pour sécuriser le transport email ? : comparaison technique et guide de choix
