MTA-STS (SMTP MTA Strict Transport Security)

Le problème : STARTTLS est vulnérable

Le protocole SMTP a été conçu au début des années 1980 (RFC 821), à une époque où le chiffrement n’était pas une préoccupation. Les emails circulaient en clair entre les serveurs, lisibles par quiconque pouvait intercepter le trafic réseau.

STARTTLS a été introduit en 2002 (RFC 3207) pour corriger ce problème. Le mécanisme est simple : quand deux serveurs email établissent une connexion SMTP, le serveur destinataire annonce qu’il supporte TLS via la commande 250-STARTTLS. Le serveur expéditeur peut alors basculer la connexion vers un canal chiffré avant de transmettre le message.

Le problème est dans le mot “peut”. STARTTLS est opportuniste. La négociation se fait en clair, et le serveur expéditeur est libre de continuer en clair si le chiffrement échoue ou n’est pas proposé.

L’attaque downgrade STARTTLS

Un attaquant positionné entre deux serveurs email (position man-in-the-middle sur le réseau) peut exploiter cette faiblesse de deux façons :

STARTTLS stripping : l’attaquant intercepte la réponse du serveur destinataire et supprime la ligne 250-STARTTLS des capacités annoncées. Le serveur expéditeur croit que le destinataire ne supporte pas TLS et envoie l’email en clair. L’attaquant lit le contenu, puis le retransmet au vrai destinataire.

Faux certificat : l’attaquant laisse la négociation TLS se faire, mais présente son propre certificat. Comme STARTTLS seul ne vérifie pas la validité du certificat (pas de correspondance obligatoire avec le nom du serveur), la connexion est “chiffrée” mais vers l’attaquant, qui déchiffre, lit, et rechiffre vers le vrai destinataire.

Ce n’est pas théorique

Ces attaques ne sont pas de la science-fiction. Le Google Transparency Report montre qu’en 2025, environ 5 % des emails entrants vers Gmail sont encore transmis sans chiffrement TLS. Certains pays présentent des taux de chiffrement anormalement bas, ce qui suggère une interception à l’échelle nationale.

En 2014, des chercheurs ont documenté des cas de STARTTLS stripping systématique par des fournisseurs d’accès internet dans plusieurs pays. L’objectif : permettre la surveillance du contenu des emails en transit. Des infrastructures réseau entre la Tunisie et l’étranger supprimaient la commande STARTTLS sur les connexions SMTP sortantes, forçant la transmission en clair de tous les emails.

Pour une entreprise, le risque est concret : un email contenant des données clients, un contrat, des coordonnées bancaires ou des documents stratégiques peut être lu en transit sans que ni l’expéditeur ni le destinataire ne s’en aperçoive. SPF, DKIM et DMARC ne protègent pas contre ce scénario — ils authentifient l’expéditeur mais ne chiffrent pas le contenu.

Comment MTA-STS résout le problème

MTA-STS (RFC 8461, publié en 2018) adopte une approche directe : le propriétaire du domaine destinataire publie une politique qui déclare “mon serveur supporte TLS — exigez-le”. Les serveurs d’envoi qui respectent MTA-STS refusent de transmettre l’email si une connexion chiffrée valide ne peut pas être établie.

Le protocole repose sur deux composants :

1. L’enregistrement DNS TXT

Un enregistrement DNS TXT à _mta-sts.votre-domaine.fr signale l’existence d’une politique MTA-STS et fournit un identifiant de version :

_mta-sts.votre-domaine.fr.  IN  TXT  "v=STSv1; id=20260416001"

L’identifiant (id) change à chaque mise à jour de la politique. Les serveurs d’envoi comparent cet identifiant avec la version qu’ils ont en cache pour savoir s’il faut télécharger une nouvelle politique.

2. Le fichier de politique hébergé en HTTPS

La politique elle-même est un fichier texte hébergé à une URL précise :

https://mta-sts.votre-domaine.fr/.well-known/mta-sts.txt

Le choix du HTTPS n’est pas anodin. Un fichier servi par DNS (comme SPF ou DMARC) pourrait être intercepté et modifié par le même attaquant qui fait du STARTTLS stripping. En servant la politique via HTTPS avec un certificat TLS valide, MTA-STS crée un canal de distribution de la politique qui ne dépend pas de la sécurité DNS. L’attaquant devrait compromettre l’autorité de certification en plus du réseau, ce qui rend l’attaque beaucoup plus difficile.

Le fonctionnement en pratique

Quand un serveur email (par exemple Gmail) veut envoyer un message à utilisateur@votre-domaine.fr, voici ce qui se passe si MTA-STS est configuré :

1. Le serveur d’envoi interroge le DNS pour _mta-sts.votre-domaine.fr et découvre la politique.
2. Il télécharge le fichier de politique à https://mta-sts.votre-domaine.fr/.well-known/mta-sts.txt.
3. Il vérifie que le serveur MX destinataire figure dans la politique.
4. Il établit la connexion SMTP et exige une connexion TLS avec un certificat valide correspondant au nom du serveur MX.
5. Si la connexion TLS échoue ou si le certificat est invalide, le serveur d’envoi refuse de transmettre l’email (en mode enforce).

Le serveur d’envoi met ensuite la politique en cache pour la durée spécifiée par max_age. Pendant cette période, toute tentative de STARTTLS stripping ou de faux certificat entraîne le rejet de la transmission.

Structure de la politique MTA-STS

Le fichier de politique contient quatre champs :

version: STSv1
mode: enforce
mx: mail.votre-domaine.fr
mx: mail2.votre-domaine.fr
max_age: 604800

version

Toujours STSv1. Ce champ permet l’évolution future du protocole sans casser la compatibilité.

mode

Le mode détermine le comportement du serveur d’envoi quand la connexion TLS échoue :

Mode	Comportement en cas d’échec TLS	Usage
testing	Transmet l’email quand même, mais génère un rapport TLS-RPT	Phase de test et de surveillance
enforce	Refuse de transmettre l’email	Production, protection active
none	Ignore la politique MTA-STS	Désactivation propre de la politique

Commencez toujours par testing. Ce mode vous permet de voir quels serveurs ne parviennent pas à établir une connexion TLS valide vers votre domaine, sans bloquer de vrais emails. Passez à enforce une fois que les rapports confirment que tout fonctionne.

mx

La liste de vos serveurs MX légitimes. Le serveur d’envoi vérifie que le serveur auquel il se connecte figure dans cette liste. Les wildcards sont supportés : mx: *.votre-domaine.fr.

Ce champ protège contre un scénario où un attaquant modifie les enregistrements MX DNS pour rediriger le trafic email vers un serveur qu’il contrôle. Même si l’attaquant redirige le DNS, le serveur d’envoi constatera que le serveur MX de destination ne figure pas dans la politique MTA-STS en cache et refusera la connexion.

max_age

La durée de mise en cache de la politique, en secondes. Une fois la politique téléchargée, le serveur d’envoi la conserve pendant cette période sans la re-télécharger.

Valeur	Durée	Usage recommandé
86400	1 jour	Phase de test (permet des corrections rapides)
604800	1 semaine	Transition vers enforce
2592000	30 jours	Production stable
31557600	1 an	Protection maximale (attention : difficile à révoquer)

Un max_age long offre une meilleure protection (la politique reste active même si l’attaquant bloque l’accès au fichier de politique), mais rend les modifications plus lentes à propager. Trouvez l’équilibre adapté à votre contexte.

TLS-RPT : les rapports de chiffrement

TLS-RPT (SMTP TLS Reporting, RFC 8460) est le protocole compagnon de MTA-STS. Il fonctionne sur le même principe que les rapports DMARC : les serveurs d’envoi vous envoient des rapports quotidiens sur les résultats des négociations TLS vers votre domaine.

Configuration

Un enregistrement DNS TXT à _smtp._tls.votre-domaine.fr :

_smtp._tls.votre-domaine.fr.  IN  TXT  "v=TLSRPTv1; rua=mailto:tls-reports@votre-domaine.fr"

Vous pouvez aussi spécifier une URL HTTPS pour recevoir les rapports via un endpoint API :

v=TLSRPTv1; rua=https://reporting.votre-domaine.fr/tls-rpt

Contenu des rapports

Les rapports TLS-RPT sont au format JSON et contiennent :

• Organisation d’envoi : quel serveur a tenté de vous envoyer un email
• Type de politique : MTA-STS, DANE ou aucune
• Résultat : nombre de sessions réussies et échouées
• Type d’échec : certificat expiré, nom de domaine non correspondant, STARTTLS non supporté, etc.

Exemple simplifié d’un rapport :

{
  "organization-name": "Google Inc.",
  "date-range": {
    "start-datetime": "2026-04-15T00:00:00Z",
    "end-datetime": "2026-04-15T23:59:59Z"
  },
  "policies": [{
    "policy": {
      "policy-type": "sts",
      "policy-string": ["version: STSv1", "mode: enforce", "mx: mail.votre-domaine.fr", "max_age: 604800"]
    },
    "summary": {
      "total-successful-session-count": 1245,
      "total-failure-session-count": 3
    },
    "failure-details": [{
      "result-type": "certificate-expired",
      "sending-mta-ip": "209.85.210.45",
      "failed-session-count": 3
    }]
  }]
}

Ce rapport indique que Google a tenté 1 248 connexions vers votre domaine. 1 245 ont réussi avec TLS. 3 ont échoué à cause d’un certificat expiré. Sans TLS-RPT, vous ne sauriez jamais que votre certificat a expiré sur l’un de vos serveurs MX secondaires.

Outils d’analyse

Analyser les rapports TLS-RPT en JSON brut est fastidieux. Plusieurs options :

• Parseur en ligne : des outils comme Report-URI ou EasyDMARC parsent et visualisent les rapports TLS-RPT automatiquement
• Script maison : les rapports JSON sont simples à parser avec Python ou Node.js — comptez quelques dizaines de lignes
• Plateforme DMARC : les outils de monitoring DMARC (comme ceux de PowerDMARC, dmarcian ou Valimail) intègrent souvent le TLS-RPT dans leur tableau de bord

Configurer MTA-STS étape par étape

Étape 1 : vérifier le support TLS de vos serveurs MX

Avant tout, confirmez que vos serveurs MX supportent TLS avec un certificat valide. Si vous utilisez Microsoft 365, Google Workspace ou un hébergeur email professionnel, c’est déjà le cas. Si vous gérez vos propres serveurs, vérifiez que :

• TLS 1.2 minimum est activé (TLS 1.3 recommandé)
• Le certificat est valide et couvre le nom d’hôte exact du serveur MX
• Le certificat n’est pas auto-signé

Outils de vérification : CheckTLS ou openssl s_client -starttls smtp -connect mail.votre-domaine.fr:25.

Étape 2 : créer le fichier de politique

Créez le fichier texte suivant :

version: STSv1
mode: testing
mx: mail.votre-domaine.fr
mx: mail2.votre-domaine.fr
max_age: 86400

Commencez avec mode: testing et max_age: 86400 (1 jour). Le mode testing permet de recevoir des rapports sans bloquer de vrais emails. Le max_age court vous permet de corriger rapidement les erreurs.

Étape 3 : héberger le fichier de politique

Hébergez le fichier à l’URL exacte :

https://mta-sts.votre-domaine.fr/.well-known/mta-sts.txt

Contraintes techniques :

• Le sous-domaine mta-sts.votre-domaine.fr doit résoudre vers un serveur web
• HTTPS obligatoire avec un certificat TLS valide (pas auto-signé)
• Le Content-Type de la réponse doit être text/plain
• Pas de redirection vers un autre domaine

Options d’hébergement : un simple serveur Nginx ou Apache, un bucket S3/GCS avec un CDN devant, ou un service dédié comme GitHub Pages avec un domaine personnalisé.

Étape 4 : ajouter l’enregistrement DNS MTA-STS

Ajoutez un enregistrement TXT dans votre zone DNS :

_mta-sts.votre-domaine.fr.  IN  TXT  "v=STSv1; id=20260416001"

L’identifiant (id) doit changer à chaque modification de la politique. Convention courante : un timestamp ou un numéro de version incrémental.

Étape 5 : ajouter l’enregistrement DNS TLS-RPT

Ajoutez un second enregistrement TXT :

_smtp._tls.votre-domaine.fr.  IN  TXT  "v=TLSRPTv1; rua=mailto:tls-reports@votre-domaine.fr"

Utilisez une adresse email dédiée ou un service de collecte de rapports. Le volume de rapports dépend du nombre d’emails que votre domaine reçoit.

Étape 6 : surveiller les rapports (2 à 4 semaines)

Pendant la phase testing, analysez les rapports TLS-RPT reçus. Identifiez :

• Les serveurs qui ne parviennent pas à établir une connexion TLS (problème côté expéditeur ou réseau)
• Les erreurs de certificat (certificat expiré, nom non correspondant)
• Les incohérences entre vos serveurs MX et la liste dans la politique

Si les rapports montrent 0 échec (ou uniquement des échecs côté serveurs expéditeurs mal configurés que vous ne pouvez pas corriger), passez à l’étape suivante.

Étape 7 : passer en mode enforce

Mettez à jour le fichier de politique :

version: STSv1
mode: enforce
mx: mail.votre-domaine.fr
mx: mail2.votre-domaine.fr
max_age: 604800

Et incrémentez l’identifiant dans l’enregistrement DNS :

_mta-sts.votre-domaine.fr.  IN  TXT  "v=STSv1; id=20260416002"

Étape 8 : augmenter progressivement le max_age

Une fois en mode enforce et après quelques semaines sans problème, augmentez le max_age à 2592000 (30 jours) ou plus. Un cache plus long signifie qu’un attaquant qui bloquerait temporairement l’accès à votre fichier de politique ne pourrait pas forcer l’expiration du cache chez les serveurs d’envoi.

MTA-STS dans l’écosystème d’authentification email

SPF, DKIM, DMARC et MTA-STS protègent contre des menaces différentes. Comprendre leur complémentarité permet de construire une défense email complète.

Protocole	Protège contre	Mécanisme
SPF	Envoi non autorisé depuis votre domaine	Liste les serveurs d’envoi légitimes dans le DNS
DKIM	Modification du contenu en transit	Signature cryptographique du message
DMARC	Spoofing du domaine From	Vérifie l’alignement SPF/DKIM avec l’adresse From visible
ARC	Perte d’authentification après transfert	Préserve les résultats d’authentification à travers les intermédiaires
MTA-STS	Interception du contenu en transit	Force le chiffrement TLS entre serveurs
TLS-RPT	Problèmes TLS non détectés	Rapports d’échec de négociation TLS
BIMI	Manque de confiance visuelle	Affiche le logo de marque dans le client email

En résumé : SPF, DKIM et DMARC répondent à la question “qui envoie cet email et est-il légitime ?”. MTA-STS répond à la question “quelqu’un peut-il lire cet email pendant son trajet entre les serveurs ?”. Les deux questions sont indépendantes. Un domaine avec DMARC p=reject mais sans MTA-STS bloque le spoofing mais reste vulnérable à l’écoute du contenu en transit.

Testez la configuration email de votre domaine (SPF, DKIM, DMARC) avec notre vérificateur de sécurité email. L’outil analyse vos enregistrements DNS et identifie les lacunes de votre protection.

Qui utilise MTA-STS ?

Les grands fournisseurs

Google a été le premier grand fournisseur à déployer MTA-STS sur gmail.com. Vous pouvez vérifier leur politique vous-même : https://mta-sts.gmail.com/.well-known/mta-sts.txt. Microsoft a suivi avec outlook.com et les domaines Microsoft 365. Ces deux acteurs gèrent une part majoritaire du trafic email mondial, ce qui signifie que si vous configurez MTA-STS sur votre domaine, les emails en provenance de Gmail et Outlook respecteront votre politique.

L’adoption en France

Parmi les PME et ETI françaises, l’adoption de MTA-STS est très faible. Plusieurs raisons expliquent ce retard :

• Méconnaissance : MTA-STS est moins connu que SPF, DKIM et DMARC, eux-mêmes encore insuffisamment déployés. Beaucoup de responsables informatiques ne savent pas que STARTTLS est vulnérable.
• Complexité perçue : héberger un fichier sur un sous-domaine HTTPS semble plus lourd qu’ajouter un enregistrement DNS (en réalité, c’est quelques minutes de configuration).
• Pas d’obligation directe : aucune réglementation française n’impose explicitement MTA-STS — pour l’instant.

NIS2 et les perspectives réglementaires

La directive européenne NIS2, transposée en droit français, impose aux entités essentielles et importantes de mettre en place des mesures de gestion des risques de cybersécurité. La sécurité des communications email entre dans ce périmètre. Si votre entreprise est concernée par NIS2, documenter la protection du transport email (incluant MTA-STS) renforce votre posture de conformité.

Par ailleurs, l’ANSSI recommande depuis plusieurs années le chiffrement systématique des communications email. MTA-STS est l’outil technique qui transforme cette recommandation en obligation vérifiable pour votre domaine.

Le coût de l’inaction

Un domaine sans MTA-STS signifie que chaque email entrant peut potentiellement être lu en transit par un attaquant positionné sur le réseau. Pour une entreprise qui échange des contrats, des données RH, des informations financières ou des données clients par email, c’est un risque de confidentialité mesurable. MTA-STS ne coûte rien à déployer (un fichier texte, deux enregistrements DNS) et élimine ce vecteur d’attaque.

La sécurité email complète se construit couche par couche : SPF + DKIM + DMARC p=reject pour l’authentification, MTA-STS + TLS-RPT pour le chiffrement du transport. Chaque couche couvre un angle mort de la précédente.