MTA-STS Generator gratuit

Qu'est-ce que MTA-STS ?

MTA-STS (Mail Transfer Agent Strict Transport Security) est un standard de sécurité email défini dans la RFC 8461. Il permet à un propriétaire de domaine de déclarer que ses serveurs de messagerie prennent en charge le chiffrement TLS, et d'imposer aux serveurs émetteurs de refuser la livraison plutôt que d'envoyer un message en clair.

Le problème qu'il résout est ancien. SMTP négocie TLS de façon opportuniste : si la commande STARTTLS échoue, le message part quand même, non chiffré. Un attaquant placé sur le chemin réseau exploite cette tolérance : il supprime STARTTLS et force un envoi en clair qu'il intercepte, c'est l'attaque dite de downgrade. MTA-STS supprime ce repli. Sans TLS valide vers vos serveurs MX, l'email n'est tout simplement pas livré.

Au-delà de la protection contre l'interception et les attaques man-in-the-middle, publier MTA-STS signale que votre domaine applique les bonnes pratiques de chiffrement en transit. Google et Microsoft 365 le prennent en charge côté émetteur, et le couplent à TLS-RPT pour remonter les échecs de connexion.

Composants MTA-STS

Une configuration MTA-STS repose sur deux éléments publiés séparément : un enregistrement DNS qui annonce la politique, et la politique elle-même, hébergée en HTTPS. Les deux doivent rester cohérents pour qu'un serveur émetteur applique vos règles.

1. Enregistrement DNS

Un enregistrement TXT publié à _mta-sts.votredomaine.com annonce que votre domaine prend en charge MTA-STS :

_mta-sts.exemple.com.  IN  TXT  "v=STSv1; id=20240115120000"

• v=STSv1 : version du protocole (toujours STSv1)
• id : identifiant de la version courante ; modifiez-le à chaque mise à jour de la politique

2. Fichier de politique

La politique est un fichier texte hébergé à https://mta-sts.votredomaine.com/.well-known/mta-sts.txt :

version: STSv1
mode: enforce
mx: mail.exemple.com
mx: *.backup-mail.exemple.com
max_age: 604800

La directive mx peut apparaître plusieurs fois pour lister tous vos serveurs de réception. Le champ mode accepte enforce, testing ou none.

Checklist de déploiement

Déployez MTA-STS dans cet ordre : d'abord la politique et son certificat HTTPS, ensuite seulement l'enregistrement DNS. Tant que la politique n'est pas joignable, l'enregistrement n'a aucun effet : les serveurs émetteurs n'ont rien à appliquer.

Étape 1 : Configurez l'hôte de la politique

1. Créez un sous-domaine : mta-sts.votredomaine.com
2. Obtenez un certificat HTTPS (Let's Encrypt fonctionne)
3. Configurez votre serveur web pour servir le fichier de politique

Étape 2 : Créez et hébergez le fichier de politique

1. Utilisez le générateur ci-dessus pour créer votre politique
2. Sauvegardez-la sous le nom mta-sts.txt
3. Hébergez-la à /.well-known/mta-sts.txt

Étape 3 : Ajoutez l'enregistrement DNS

1. Générez l'enregistrement DNS avec l'outil ci-dessus
2. Ajoutez-le à votre DNS comme enregistrement TXT à _mta-sts

Étape 4 : Testez et surveillez

1. Validez votre configuration avec le Vérificateur MTA-STS
2. Restez en mode testing le temps d'identifier les problèmes
3. Passez en mode enforce une fois la configuration confirmée

FAQ - Questions fréquentes

Q : Qu'est-ce que MTA-STS et pourquoi en ai-je besoin ?

R : MTA-STS (Mail Transfer Agent Strict Transport Security) est un standard défini dans la RFC 8461 qui laisse un propriétaire de domaine déclarer que ses serveurs de messagerie exigent TLS. Sans lui, SMTP retombe en clair dès que la négociation TLS échoue, ce qu'un attaquant peut provoquer pour intercepter le courrier. MTA-STS supprime ce repli et protège vos emails entrants contre l'interception et les attaques man-in-the-middle.

Q : Quelle est la différence entre les modes testing et enforce ?

R : En mode testing, les serveurs émetteurs signalent les échecs via TLS-RPT mais livrent quand même le courrier si TLS échoue : rien n'est bloqué, vous observez. En mode enforce, ils doivent établir une connexion TLS valide ou refuser la livraison. Démarrez toujours en testing pour vérifier que tous vos serveurs MX répondent en TLS, puis passez à enforce.

Q : Comment déployer le fichier de politique MTA-STS ?

R : Hébergez le fichier de politique à https://mta-sts.votredomaine.com/.well-known/mta-sts.txt. Le sous-domaine mta-sts doit présenter un certificat HTTPS valide, servir le fichier avec l'en-tête Content-Type: text/plain et rester accessible sans redirection. Une seule de ces conditions manquante et la politique est ignorée.

Q : Quelle valeur max_age dois-je utiliser ?

R : La directive max_age fixe la durée, en secondes, pendant laquelle les émetteurs gardent votre politique en cache. Les valeurs courantes vont de 86400 (1 jour) en phase de testing à 604800 (1 semaine) en production, jusqu'à 31557600 (1 an) pour une configuration stable. Évitez de descendre sous 86400 : certains fournisseurs comme Gmail ignorent une politique au cache trop court.

Q : Puis-je utiliser des wildcards dans les patterns MX ?

R : Oui. MTA-STS accepte un astérisque (*) comme label le plus à gauche d'un pattern MX. Par exemple, *.mail.exemple.com couvre n'importe quel sous-domaine de mail.exemple.com, ce qui évite de lister chaque serveur un par un.

Q : Ai-je aussi besoin d'un enregistrement TLS-RPT ?

R : Ce n'est pas obligatoire, mais c'est vivement recommandé. Un enregistrement TLS-RPT (RFC 8460) demande aux serveurs émetteurs de vous envoyer un rapport quotidien des échecs de connexion TLS. C'est votre seule visibilité sur ce que MTA-STS bloque ou laisse passer : sans lui, un problème de certificat passe inaperçu.

Q : Comment configurer MTA-STS pour Microsoft 365 / Office 365 ?

R : Entrez votre domaine dans le générateur, choisissez le mode (commencez par testing) et ajoutez le pattern MX *.mail.protection.outlook.com, qui couvre les serveurs Exchange Online. Copiez l'enregistrement DNS TXT, puis hébergez le fichier de politique sur le sous-domaine mta-sts de votre domaine.

Q : Comment configurer MTA-STS pour Google Workspace ?

R : Entrez votre domaine, puis ajoutez les patterns MX que votre domaine publie réellement : smtp.google.com pour un domaine Workspace récent (MX unique en priorité 1 depuis 2023), ou le jeu historique aspmx.l.google.com pour le MX principal, *.aspmx.l.google.com pour les quatre MX alternatifs et *.googlemail.com pour les MX de secours. Le générateur produit l'enregistrement DNS TXT et le fichier de politique prêts à déployer.

Votre chiffrement en transit est prêt à être verrouillé ? Générez votre configuration ci-dessus, déployez la politique, puis validez le tout avec le Vérificateur MTA-STS.

Outils complémentaires

Ressources utiles

• RFC 8461 - SMTP MTA Strict Transport Security (spécification officielle de MTA-STS)
• RFC 8460 - SMTP TLS Reporting (TLS-RPT, le reporting recommandé avec MTA-STS)
• Documentation MTA-STS Google (guide Google Workspace pour activer MTA-STS)