Le problème : STARTTLS est opportuniste
La majorité des e-mails entre serveurs est chiffrée avec STARTTLS, une extension SMTP qui met à niveau la connexion en clair vers TLS. Cependant, STARTTLS présente un défaut fondamental : il est opportuniste. Si la négociation TLS échoue pour quelque raison que ce soit — un attaquant qui bloque la commande STARTTLS, un certificat expiré, une erreur de configuration — la plupart des serveurs expéditeurs continuent en clair, envoyant les e-mails sans chiffrement. Un attaquant positionné sur le réseau (man-in-the-middle) peut simplement intercepter la commande STARTTLS et forcer la connexion en clair, lisant tous les e-mails en transit.
MTA-STS (Mail Transfer Agent Strict Transport Security, RFC 8461) résout ce problème en permettant au domaine destinataire de déclarer : « les e-mails pour mon domaine ne doivent être livrés que via des connexions TLS valides ». Si le serveur expéditeur prend en charge MTA-STS et que la négociation TLS échoue, l'e-mail n'est pas envoyé en clair — il est retenu et l'expéditeur est notifié. Cela élimine la possibilité d'attaques de rétrogradation.
Comment fonctionne MTA-STS
MTA-STS nécessite deux composants : un enregistrement DNS TXT sur _mta-sts.domaine.com qui signale la présence de la politique et inclut un identifiant unique (typiquement un horodatage) mis à jour à chaque modification, et un fichier de politique servi via HTTPS sur https://mta-sts.domaine.com/.well-known/mta-sts.txt. Le fait que la politique soit servie via HTTPS (et non DNS) ajoute une couche de sécurité supplémentaire : un attaquant devrait également compromettre le certificat HTTPS pour falsifier la politique.
La politique spécifie : la version (STSv1), le mode (testing ou enforce), les noms d'hôte des serveurs de messagerie autorisés (mx:), et la durée de mise en cache de la politique (max_age en secondes). Le mode testing signale les problèmes dans les rapports TLS-RPT sans bloquer la livraison, permettant d'identifier et de résoudre les problèmes avant de passer en mode enforce.
MTA-STS et TLS-RPT : le duo parfait
MTA-STS sans TLS-RPT Lookup est comme un système de sécurité sans alarme : il bloque les problèmes mais ne vous alerte pas. TLS-RPT (RFC 8460) fournit des rapports détaillés sur les échecs TLS, vous permettant de surveiller combien de connexions TLS réussissent, combien échouent, et pourquoi. Configurez toujours TLS-RPT en parallèle de MTA-STS pour avoir une visibilité complète sur la sécurité des connexions e-mail entrantes.
Notre MTA-STS Lookup vérifie les deux composants : l'enregistrement DNS et la politique HTTPS. Il contrôle que l'enregistrement existe et possède un identifiant valide, que le fichier de politique est accessible via HTTPS avec un certificat valide, que les serveurs MX dans la politique correspondent aux enregistrements MX réels du domaine, et que le mode et le max_age sont correctement configurés.
Mise en œuvre étape par étape
La mise en œuvre de MTA-STS nécessite un serveur web HTTPS pour servir la politique. Si vous disposez déjà d'un site web pour le domaine, vous pouvez créer un sous-domaine mta-sts.votredomaine.com avec un certificat SSL valide. Sinon, des services comme Cloudflare Workers ou GitHub Pages peuvent héberger le fichier de politique gratuitement. Le certificat HTTPS doit être valide et délivré par une CA publique — les certificats auto-signés ne sont pas acceptés.
Commencez avec mode: testing pour collecter des données sans impact sur la livraison. Surveillez les rapports TLS-RPT pendant au moins 2 semaines. Vérifiez que votre certificat SSL Check est valide et que vos serveurs MX prennent en charge TLS 1.2+. Une fois que vous avez confirmé l'absence de problèmes, passez en mode: enforce. Mettez à jour l'identifiant dans l'enregistrement DNS à chaque modification de la politique pour forcer le rafraîchissement du cache des serveurs expéditeurs.