Pourquoi MTA-STS est indispensable
SMTP a été conçu en 1982 sans chiffrement. STARTTLS a été ajouté par la suite pour chiffrer les emails en transit. Son défaut : il est purement opportuniste. Le serveur expéditeur annonce le support STARTTLS, mais le serveur destinataire peut l'ignorer. Aucun mécanisme ne garantit que la connexion reste chiffrée.
Cela ouvre la porte aux attaques de downgrade SMTP. Un attaquant se positionne entre deux serveurs de messagerie via un détournement BGP, du spoofing DNS ou une interception réseau. Il supprime la commande STARTTLS du handshake SMTP. Le serveur expéditeur ne voit plus d'option de chiffrement. Il bascule en clair. L'email transite sans protection, lisible par quiconque se trouve sur le chemin.
MTA-STS (RFC 8461) comble cette faille. Il publie une politique claire : « ce domaine exige TLS. Si le chiffrement échoue, ne basculez pas en clair. » Le serveur expéditeur doit alors établir une connexion TLS valide. En cas d'échec, il met le message en file d'attente pour une nouvelle tentative.
L'obstacle au déploiement : MTA-STS exige l'hébergement d'un fichier de politique à l'adresse https://mta-sts.captaindns.com/.well-known/mta-sts.txt en HTTPS avec un certificat valide. Pour de nombreuses organisations, maintenir un serveur web dédié pour un simple fichier texte est disproportionné. CaptainDNS élimine cet obstacle.
Ce qui se passe sans MTA-STS
Sans MTA-STS, le transport de vos emails repose uniquement sur le TLS opportuniste. Voici ce que cela signifie en pratique :
- Interception en clair : tout attaquant positionné au niveau réseau peut lire vos emails en supprimant STARTTLS. Ce n'est pas théorique. Des programmes de surveillance étatiques et des interceptions au niveau des FAI ont été documentés.
- Aucune vérification côté expéditeur : sans politique publiée, les serveurs expéditeurs n'ont aucun moyen de savoir que votre domaine exige TLS. Ils basculeront silencieusement en clair au moindre problème.
- Exposition réglementaire : des réglementations comme le RGPD, HIPAA et PCI-DSS exigent le chiffrement des données sensibles en transit. Le TLS opportuniste seul ne satisfait pas cette exigence, car il peut être contourné.
- Échecs invisibles : sans TLS-RPT (le protocole de reporting associé), vous ne saurez jamais que des emails destinés à votre domaine ont été livrés sans chiffrement. Le problème est silencieux.
En 2014, des chercheurs ont documenté des suppressions massives de STARTTLS par des intermédiaires réseau dans plusieurs pays. Le Transparency Report de Google a ensuite confirmé qu'une part significative des emails entrants arrive encore sans chiffrement. MTA-STS est le protocole conçu pour mettre fin à cette situation.
Associé à TLS-RPT, il vous apporte à la fois l'application du chiffrement et la visibilité sur les échecs.
Fonctionnement de MTA-STS en détail
MTA-STS repose sur deux composants qui fonctionnent ensemble :
1. Un enregistrement DNS TXT à _mta-sts.captaindns.com
Cet enregistrement annonce votre politique MTA-STS. Il contient un identifiant unique de politique. Quand cet identifiant change, les serveurs expéditeurs récupèrent une copie à jour de la politique.
Exemple : v=STSv1; id=20260308120000
2. Un fichier de politique hébergé en HTTPS à https://mta-sts.captaindns.com/.well-known/mta-sts.txt
Ce fichier définit trois éléments :
- mode :
testing(signalement uniquement) ouenforce(rejet en cas d'échec TLS) - mx : les modèles de serveurs de messagerie qui doivent correspondre à vos enregistrements MX
- max_age : la durée de mise en cache de la politique par les serveurs expéditeurs (en secondes)
Exemple :
version: STSv1
mode: enforce
mx: *.mail.protection.outlook.com
max_age: 604800
Lorsqu'un serveur expéditeur souhaite livrer un email à votre domaine, il vérifie la présence de l'enregistrement TXT _mta-sts. S'il existe, il récupère le fichier de politique en HTTPS. Il valide ensuite le certificat TLS de vos serveurs MX par rapport aux modèles de la politique. La livraison ne se poursuit que si tout correspond.
Trust on first use (TOFU) : MTA-STS repose sur le fait que la première récupération de la politique soit légitime. La politique mise en cache protège ensuite contre les attaques futures pendant toute la durée du max_age. Un max_age long (7 jours ou plus) est donc recommandé en mode enforce.
Comment ça fonctionne
1. Créez votre politique
Connectez-vous et créez une nouvelle politique. Définissez votre domaine, le mode (testing ou enforce), les modèles MX et la durée de mise en cache (max_age).
2. Vérifiez la propriété du domaine
Ajoutez l'enregistrement TXT de vérification à votre DNS. Nous le détectons automatiquement en quelques secondes.
3. Ajoutez les enregistrements DNS de déploiement
Deux enregistrements DNS :
- CNAME : Pointe
mta-sts.captaindns.comvers notre serveur de politique - TXT : Annonce votre politique MTA-STS à
_mta-sts.captaindns.com
Votre politique MTA-STS est active.
Compatible avec les principaux fournisseurs de messagerie
MTA-STS fonctionne avec tout fournisseur de messagerie utilisant des enregistrements MX standards. Les modèles MX de votre politique doivent correspondre aux serveurs de messagerie de votre fournisseur :
| Fournisseur | Modèle MX |
|---|---|
| Microsoft 365 | *.mail.protection.outlook.com |
| Google Workspace | *.google.com et *.googlemail.com |
| Proton Mail | *.protonmail.ch |
| Zoho Mail | *.zoho.com |
| Auto-hébergé (Postfix, Exchange) | Votre propre nom d'hôte MX |
Lors de la création de votre politique sur CaptainDNS, saisissez les modèles MX correspondant à votre fournisseur. Le tableau de bord les valide par rapport à vos enregistrements MX réels pour éviter les incohérences.
Hébergé vs. auto-hébergé : quelle option choisir ?
| Critère | Hébergé (CaptainDNS) | Auto-hébergé |
|---|---|---|
| Configuration serveur | Aucune | Requise (Nginx, Apache, Caddy) |
| Certificat HTTPS | Automatique (Let's Encrypt) | Provisionnement et renouvellement manuels |
| Mises à jour de politique | Tableau de bord + rotation automatique de l'ID | Édition manuelle du fichier + mise à jour DNS |
| Domaines multiples | Jusqu'à 5 par compte | Une configuration serveur par domaine |
| Disponibilité | Infrastructure redondante | Dépend de votre configuration |
| Surveillance des certificats | Intégrée | Sous votre responsabilité |
| Coût | Gratuit | Coûts d'hébergement serveur |
Choisissez l'hébergement si vous voulez déployer MTA-STS en quelques minutes sans aucune infrastructure. Choisissez l'auto-hébergement si vous avez besoin d'un contrôle total sur le point de terminaison de la politique ou si vous opérez dans un environnement isolé.
De testing à enforce : une stratégie progressive
Déployer MTA-STS directement en mode enforce est risqué. Si vos modèles MX sont incorrects ou qu'un certificat TLS expire, les emails légitimes sont rejetés. L'approche recommandée est progressive :
Phase 1 : Déployer en mode testing (1 à 2 semaines)
Définissez mode: testing dans votre politique. Les serveurs expéditeurs tenteront la connexion TLS et signaleront les échecs via TLS-RPT, mais livreront tout de même les emails en cas d'échec TLS. Cela vous donne de la visibilité sans risque.
Phase 2 : Analyser les rapports TLS-RPT
Examinez les rapports pour identifier les problèmes : incompatibilités de certificats, modèles MX ne couvrant pas tous les serveurs de messagerie, ou expéditeurs tiers avec un TLS défaillant. Corrigez chaque problème avant de passer à l'étape suivante.
Phase 3 : Passer en mode enforce
Une fois que les rapports montrent zéro échec pendant au moins une semaine, passez le mode à enforce et augmentez le max_age à 604800 (7 jours) ou plus. Sur CaptainDNS, c'est un simple clic dans le tableau de bord. L'identifiant de politique est automatiquement mis à jour.
Retour en arrière d'urgence : si le mode enforce bloque des emails légitimes, repassez immédiatement en testing. Les serveurs expéditeurs récupéreront la politique mise à jour et cesseront de rejeter en quelques minutes (ou au maximum dans la fenêtre de l'ancien max_age).
MTA-STS et DANE : deux approches complémentaires
Deux protocoles permettent d'imposer le chiffrement du transport email : MTA-STS et DANE (DNS-based Authentication of Named Entities). Ils résolvent le même problème de manière différente.
| MTA-STS | DANE | |
|---|---|---|
| Mécanisme de confiance | HTTPS (autorité de certification) | DNSSEC (chaîne cryptographique) |
| Infrastructure requise | Serveur web HTTPS (ou service hébergé) | Zone signée DNSSEC |
| Modèle de confiance | Trust on first use (TOFU) | Pas de TOFU, cryptographique dès le départ |
| Support fournisseurs | Microsoft 365, Google Workspace, la plupart des fournisseurs | Nécessite DNSSEC sur votre domaine |
| Complexité de déploiement | Faible (2 enregistrements DNS + politique hébergée) | Élevée (DNSSEC + enregistrements TLSA) |
Si votre domaine n'utilise pas DNSSEC, MTA-STS est votre seule option pour imposer le chiffrement du transport.
Si votre domaine utilise DNSSEC, déployer les deux protocoles offre la meilleure protection : DANE élimine le TOFU pour les expéditeurs compatibles DNSSEC, tandis que MTA-STS couvre les expéditeurs qui ne supportent pas DANE.
Bonnes pratiques de déploiement MTA-STS
- Commencez en mode testing : identifiez les problèmes de connectivité TLS avant de passer en mode enforce.
- Configurez TLS-RPT : recevez des rapports sur les échecs de livraison TLS. Utilisez notre générateur TLS-RPT.
- Validez vos enregistrements MX : assurez-vous que les modèles MX dans votre politique correspondent à vos serveurs de messagerie réels. Les incohérences provoquent des échecs de livraison en mode enforce.
- Surveillez avant d'appliquer : analysez les rapports TLS-RPT pendant au moins une semaine avec zéro échec avant de passer en mode enforce.
- Utilisez un max_age long en mode enforce : 604800 secondes (7 jours) ou plus. Cela garantit que les serveurs expéditeurs mettent en cache votre politique suffisamment longtemps pour résister aux attaques de downgrade.
- Passez en mode enforce : une fois que les rapports TLS-RPT confirment que tout fonctionne, activez le mode enforce pour une protection complète.
Outils complémentaires
| Outil | Description |
|---|---|
| Vérificateur MTA-STS | Validez votre configuration MTA-STS existante |
| Générateur MTA-STS | Générez des enregistrements et fichiers de politique MTA-STS |
| Vérificateur de syntaxe MTA-STS | Validez la syntaxe MTA-STS hors ligne |
| Générateur TLS-RPT | Configurez le reporting TLS en complément de MTA-STS |
| Hébergement BIMI | Hébergez vos logos et certificats BIMI gratuitement |
| Monitoring TLS-RPT | Surveillez et analysez automatiquement les rapports TLS-RPT |
Guides et ressources
- MTA-STS : le guide complet pour sécuriser le transport de vos emails - Tout ce qu'il faut savoir sur la configuration et le déploiement de MTA-STS.
- De testing à enforce : stratégie de déploiement MTA-STS progressive - Bonnes pratiques pour un déploiement progressif de MTA-STS.
- Configurer MTA-STS pour Microsoft 365 et Google Workspace - Configuration étape par étape pour les deux plateformes email les plus populaires.
- MTA-STS ne fonctionne pas ? Guide de dépannage complet - Diagnostiquez et corrigez les erreurs de configuration MTA-STS les plus courantes.
- MTA-STS vs DANE : quel protocole choisir pour sécuriser le transport email ? - Comparaison détaillée pour choisir le bon protocole.