MTA-STS : le guide complet pour sécuriser le transport de vos emails

⚡TL;DR

• MTA-STS (RFC 8461) force le chiffrement TLS sur les emails entrants et empêche les attaques de type downgrade et man-in-the-middle sur SMTP
• Deux composants à déployer : un record DNS TXT _mta-sts et un fichier de politique hébergé en HTTPS sur mta-sts.captaindns.com/.well-known/mta-sts.txt
• Trois modes disponibles : none (désactivé), testing (surveillance via TLS-RPT) et enforce (rejet si le chiffrement TLS échoue)
• Toujours commencer par le mode testing et configurer TLS-RPT pour recevoir les rapports d'échec avant de passer en enforce

Vos emails transitent chaque jour entre serveurs SMTP. Mais savez-vous si ces échanges sont réellement chiffrés ? Par défaut, SMTP utilise STARTTLS de manière opportuniste : si le serveur distant ne répond pas au chiffrement, le message part en clair. Un attaquant positionné sur le réseau peut forcer ce comportement et intercepter vos communications.

MTA-STS (Mail Transfer Agent Strict Transport Security) résout ce problème. Défini dans la RFC 8461, ce standard permet à un domaine de déclarer publiquement qu'il exige le chiffrement TLS pour recevoir des emails. Les serveurs émetteurs qui respectent MTA-STS refuseront d'envoyer un message si la connexion TLS échoue.

Ce guide vous explique comment fonctionne MTA-STS, quels sont ses composants, comment le déployer étape par étape, et pourquoi il est devenu un complément indispensable à DMARC, SPF et DKIM dans la stack de sécurité email.

Qu'est-ce que MTA-STS ? (RFC 8461)

MTA-STS, Mail Transfer Agent Strict Transport Security, est un mécanisme qui permet au propriétaire d'un domaine de publier une politique de sécurité du transport pour ses serveurs de réception email (MX). Cette politique indique aux serveurs émetteurs qu'ils doivent :

1. Négocier une connexion TLS valide avant d'envoyer un email
2. Vérifier le certificat du serveur destinataire (nom d'hôte, chaîne de confiance, expiration)
3. Refuser l'envoi si le chiffrement TLS échoue (en mode enforce)

Pourquoi STARTTLS ne suffit pas ?

STARTTLS est le mécanisme standard pour chiffrer les connexions SMTP. Mais il souffre de deux failles fondamentales :

• Attaque downgrade : un attaquant peut supprimer la commande STARTTLS de la réponse du serveur, forçant l'envoi en clair. Le serveur émetteur ne sait pas que le chiffrement était disponible.
• Pas de validation de certificat : même si STARTTLS est négocié, SMTP ne vérifie pas l'identité du serveur destinataire par défaut. Un faux serveur avec un certificat auto-signé peut intercepter les messages.

MTA-STS corrige ces deux problèmes : la politique, récupérée via HTTPS (canal séparé et authentifié), impose le chiffrement TLS et la validation du certificat.

Les deux composants de MTA-STS

MTA-STS repose sur deux éléments qui fonctionnent ensemble.

Le record DNS TXT _mta-sts

Un enregistrement TXT publié dans votre zone DNS à _mta-sts.captaindns.com :

_mta-sts.captaindns.com. 300 IN TXT "v=STSv1; id=20260205120000"

Tag	Obligatoire	Description
v	Oui	Version du protocole, toujours STSv1
id	Oui	Identifiant unique de la politique, à changer à chaque mise à jour

Le champ id sert de signal de mise à jour. Quand un serveur émetteur détecte un changement de id, il re-télécharge la politique. Utilisez un horodatage (ex : 20260205120000) ou un numéro incrémental.

Le fichier de politique mta-sts.txt

Un fichier texte hébergé à l'URL exacte https://mta-sts.captaindns.com/.well-known/mta-sts.txt :

version: STSv1
mode: testing
mx: mail.captaindns.com
mx: backup.captaindns.com
max_age: 604800

Directive	Obligatoire	Description
version	Oui	Toujours STSv1
mode	Oui	none, testing ou enforce
mx	Oui	Pattern(s) MX autorisés (un par ligne, wildcards autorisés comme *.captaindns.com)
max_age	Oui	Durée de cache en secondes (max 31 557 600 = 1 an)

Hébergement HTTPS obligatoire

Le fichier de politique doit être servi via HTTPS avec un certificat TLS valide sur le sous-domaine mta-sts. C'est un élément fondamental de la sécurité de MTA-STS : contrairement au DNS (qui peut être usurpé sans DNSSEC), HTTPS garantit l'authenticité de la politique via la validation du certificat.

Les 3 modes MTA-STS : testing, enforce, none

Mode testing : surveiller sans bloquer

mode: testing

En mode testing, les serveurs émetteurs tentent de négocier TLS et signalent les échecs via TLS-RPT (RFC 8460), mais livrent quand même le message si le chiffrement échoue. C'est le mode de démarrage recommandé.

Mode enforce : chiffrement ou rejet

mode: enforce

En mode enforce, les serveurs émetteurs refusent de livrer le message si la connexion TLS échoue ou si le certificat n'est pas valide. C'est le mode cible pour une protection complète.

Mode none : désactivation

mode: none

Le mode none indique que MTA-STS est désactivé. Utilisez-le pour désactiver proprement une politique existante (les serveurs émetteurs qui ont une politique en cache doivent attendre l'expiration de max_age).

Quelle valeur max_age choisir ?

Phase de déploiement	max_age recommandé	Durée
Début (testing)	86 400	1 jour
Stabilisation	604 800	7 jours
Production (enforce)	2 592 000 à 31 557 600	30 jours à 1 an

Un max_age court en phase de test permet de corriger rapidement les erreurs. Une fois en enforce, un max_age long réduit la fréquence de re-téléchargement et renforce la protection contre les attaques DNS temporaires.

Déployer MTA-STS étape par étape

Étape 1 : Vérifier vos MX et certificats TLS

Avant de déployer MTA-STS, assurez-vous que tous vos serveurs MX disposent d'un certificat TLS valide (TLS 1.2 minimum) avec un nom d'hôte correspondant. Un certificat expiré ou mal configuré causera des rejets en mode enforce.

Étape 2 : Créer le fichier de politique

Créez le fichier mta-sts.txt avec vos serveurs MX. Vous pouvez utiliser le générateur MTA-STS CaptainDNS pour le créer automatiquement :

version: STSv1
mode: testing
mx: mail.captaindns.com
mx: backup.captaindns.com
max_age: 86400

Étape 3 : Héberger la politique à l'URL .well-known

Publiez le fichier à l'URL exacte :

https://mta-sts.captaindns.com/.well-known/mta-sts.txt

Le sous-domaine mta-sts doit résoudre vers un serveur web HTTPS avec un certificat valide. Options d'hébergement courantes :

• Cloudflare Pages / Cloudflare Workers : gratuit, HTTPS automatique
• GitHub Pages : gratuit, certificat Let's Encrypt
• Azure Static Web Apps : intégration Microsoft 365
• Serveur web existant : Apache, Nginx avec Let's Encrypt

Le Content-Type de la réponse doit être text/plain.

Étape 4 : Publier le record DNS TXT

Ajoutez dans votre zone DNS :

_mta-sts.captaindns.com. 300 IN TXT "v=STSv1; id=20260205120000"

Étape 5 : Valider votre configuration

Utilisez le vérificateur MTA-STS CaptainDNS pour contrôler que tout est en place : record DNS, fichier de politique, certificat TLS, correspondance MX.

MTA-STS vs DANE vs STARTTLS

Trois mécanismes coexistent pour sécuriser le transport SMTP. Voici leurs différences :

Critère	STARTTLS seul	MTA-STS	DANE
Protection	Chiffrement opportuniste	Chiffrement obligatoire	Chiffrement obligatoire
Validation du certificat	Non	Oui (via HTTPS/CA)	Oui (via DNSSEC/TLSA)
Résiste aux attaques downgrade	Non	Oui	Oui
Prérequis	Rien	HTTPS sur sous-domaine mta-sts	DNSSEC sur la zone DNS
Complexité de déploiement	Faible	Moyenne	Élevée
Adoption	Universelle	Croissante (Google, Microsoft)	Limitée (prérequis DNSSEC)
RFC	RFC 3207	RFC 8461	RFC 7671

En pratique : MTA-STS est le choix pragmatique. DANE offre une sécurité théoriquement supérieure (pas de dépendance aux CA) mais nécessite DNSSEC, encore peu déployé. Les deux approches sont complémentaires et peuvent coexister.

TLS-RPT : surveiller votre déploiement MTA-STS

TLS-RPT (SMTP TLS Reporting, RFC 8460) est le compagnon indispensable de MTA-STS. Il permet de recevoir des rapports JSON quotidiens décrivant les succès et échecs de négociation TLS vers votre domaine.

Pour activer TLS-RPT, publiez un record DNS :

_smtp._tls.captaindns.com. 300 IN TXT "v=TLSRPTv1; rua=mailto:tls-reports@captaindns.com"

Ces rapports sont essentiels en mode testing : ils vous permettent d'identifier les problèmes (certificats expirés, MX non couverts, serveurs incompatibles TLS 1.2) avant de passer en mode enforce.

Plan d'action recommandé

1. Vérifiez vos certificats TLS : tous vos serveurs MX doivent avoir un certificat valide avec TLS 1.2+
2. Déployez en mode testing : créez la politique et le record DNS avec mode: testing et max_age: 86400
3. Activez TLS-RPT : publiez le record _smtp._tls pour recevoir les rapports d'échec
4. Surveillez pendant 2-4 semaines : analysez les rapports TLS-RPT et corrigez les problèmes identifiés
5. Passez en mode enforce : une fois les rapports propres, changez mode: enforce et augmentez max_age

---

Vérifiez votre configuration MTA-STS maintenant : Utilisez notre vérificateur MTA-STS pour analyser votre domaine en quelques secondes.

---

FAQ

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

MTA-STS (Mail Transfer Agent Strict Transport Security) est un standard internet (RFC 8461) qui permet à un domaine de déclarer qu'il exige le chiffrement TLS pour recevoir des emails. Sans MTA-STS, les connexions SMTP utilisent STARTTLS de manière opportuniste, ce qui les rend vulnérables aux attaques downgrade et man-in-the-middle. MTA-STS garantit que vos emails entrants sont toujours chiffrés en transit.

MTA-STS est-il obligatoire pour la sécurité email ?

MTA-STS n'est pas encore obligatoire au sens réglementaire, mais il est fortement recommandé. Google et Microsoft l'ont activé sur leurs domaines et vérifient la présence de MTA-STS sur les domaines qu'ils contactent. Pour les organisations soumises à des exigences de conformité (RGPD, PCI-DSS), MTA-STS renforce la posture de sécurité du transport email.

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

En mode testing, les serveurs émetteurs tentent la connexion TLS et signalent les échecs via TLS-RPT, mais livrent quand même le message. En mode enforce, les serveurs refusent de livrer le message si le TLS échoue. Commencez toujours par testing pour identifier les problèmes avant de passer en enforce.

Comment MTA-STS se compare-t-il à DANE ?

MTA-STS utilise HTTPS et les autorités de certification (CA) pour authentifier la politique, tandis que DANE utilise DNSSEC et les records TLSA. DANE offre une sécurité supérieure (pas de dépendance aux CA) mais nécessite DNSSEC, encore peu déployé. MTA-STS est plus simple à déployer et plus largement adopté. Les deux mécanismes sont complémentaires.

Faut-il aussi configurer TLS-RPT avec MTA-STS ?

Oui, fortement recommandé. TLS-RPT (RFC 8460) vous envoie des rapports quotidiens sur les succès et échecs de négociation TLS vers votre domaine. Sans TLS-RPT, vous n'avez aucune visibilité sur les problèmes de votre déploiement MTA-STS. Publiez un record _smtp._tls avec une adresse de réception.

Comment configurer MTA-STS pour Microsoft 365 ?

Pour Microsoft 365, utilisez le pattern MX *.mail.protection.outlook.com dans votre politique MTA-STS. Hébergez le fichier de politique sur Azure Static Web Apps, Cloudflare Pages ou tout serveur HTTPS. Microsoft supporte MTA-STS en émission (il vérifie la politique de vos destinataires) et en réception (vous pouvez publier une politique pour votre domaine M365).

Comment configurer MTA-STS pour Google Workspace ?

Pour Google Workspace, incluez les patterns MX suivants dans votre politique : aspmx.l.google.com, *.google.com et *.googlemail.com. Google vérifie activement les politiques MTA-STS des domaines qu'il contacte et publie des rapports TLS-RPT. Hébergez le fichier de politique sur un serveur HTTPS avec un certificat valide pour le sous-domaine mta-sts.

Que se passe-t-il si le fichier de politique n'est pas accessible ?

Si le fichier mta-sts.txt n'est pas accessible (erreur HTTP, timeout, certificat invalide), le serveur émetteur ne peut pas appliquer la politique. En l'absence de politique en cache, il revient au comportement STARTTLS opportuniste standard. Si une politique est en cache (non expirée selon max_age), elle continue de s'appliquer. C'est pourquoi un max_age suffisamment long protège contre les interruptions temporaires.

Glossaire

• MTA-STS : Mail Transfer Agent Strict Transport Security. Standard RFC 8461 imposant le chiffrement TLS pour la réception d'emails.
• STARTTLS : Extension SMTP qui permet de passer une connexion en clair vers une connexion chiffrée TLS. Opportuniste par défaut.
• TLS-RPT : SMTP TLS Reporting (RFC 8460). Mécanisme de rapport sur les succès et échecs de négociation TLS.
• DANE : DNS-based Authentication of Named Entities (RFC 7671). Utilise DNSSEC et les records TLSA pour valider les certificats TLS.
• Attaque downgrade : Technique où un attaquant force une connexion à utiliser un protocole moins sécurisé (ex : supprimer STARTTLS pour forcer l'envoi en clair).
• max_age : Directive de la politique MTA-STS indiquant la durée de mise en cache en secondes.

Guides MTA-STS connexes

• Configurer MTA-STS pour Microsoft 365 et Google Workspace (à venir)
• MTA-STS ne fonctionne pas ? Guide de dépannage complet (à venir)

Sources

• RFC 8461 - SMTP MTA Strict Transport Security (MTA-STS)
• RFC 8460 - SMTP TLS Reporting
• RFC 7671 - The DNS-Based Authentication of Named Entities (DANE)
• Google Support - Renforcer la sécurité des emails avec MTA-STS et TLS-RPT