MTA-STS ne protège pas vos envois

par Francis Rozange | Sep 8, 2026 | Emailing

Abstract 3D render: a glass tunnel enclosing one stream of particles, another travelling exposed

Vous avez peut-être publié SPF, DKIM et DMARC. Vous avez donc réglé la question de savoir qui a le droit d’écrire en votre nom.

Vous n’avez rien réglé du tout quant à savoir si vos messages voyagent chiffrés, ni si l’on peut vous en priver.

Deux normes traitent exactement ce point. Elles ont huit ans, elles sont signées conjointement par Google, Microsoft, Comcast et Yahoo, et presque personne ne les publie.

Ce que STARTTLS ne garantit pas

Le chiffrement du transport SMTP repose sur une commande optionnelle. Le serveur destinataire annonce qu’il sait faire du TLS, l’expéditeur en profite. Si l’annonce n’arrive pas, le message part en clair.

C’est une négociation, donc c’est manipulable. Un intermédiaire qui supprime l’annonce fait basculer l’échange en clair sans que personne ne s’en aperçoive, et le message arrive quand même. Rien n’échoue, rien n’alerte.

La RFC 8461 nomme le problème dans son abstract, en septembre 2018 :

« SMTP MTA Strict Transport Security (MTA-STS) is a mechanism enabling mail service providers to declare their ability to receive Transport Layer Security (TLS) secure SMTP connections and to specify whether sending SMTP servers should refuse to deliver to MX hosts that do not offer TLS with a trusted server certificate. »

Le sens de la publication, qui surprend tout le monde

Voici le point qui fait échouer la moitié des mises en œuvre, et il tient en une phrase.

MTA-STS ne protège pas vos envois. Il protège le courrier que l’on vous adresse.

Vous publiez une politique pour dire aux serveurs du monde entier : quand vous m’écrivez, exigez TLS, vérifiez mon certificat, et refusez de livrer si ce n’est pas le cas. La règle s’applique à eux, sur le trafic entrant chez vous.

Pour que vos propres envois soient protégés, c’est le domaine de votre destinataire qui doit avoir publié une politique, et c’est votre serveur d’envoi qui doit savoir la lire. Deux conditions dont vous ne maîtrisez qu’une.

Beaucoup d’entreprises publient MTA-STS en croyant sécuriser leur emailing sortant. Elles sécurisent leur boîte aux lettres.

Comment cela se publie, concrètement

Deux objets, et pas un de plus.

Un enregistrement DNS de type TXT sur _mta-sts.votredomaine.fr, qui ne contient qu’une version et un identifiant de politique :

v=STSv1; id=20260908120000Z

Et un fichier texte servi en HTTPS à une adresse fixe, https://mta-sts.votredomaine.fr/.well-known/mta-sts.txt, dont la RFC donne l’exemple :

version: STSv1 mode: enforce mx: mail.example.com mx: *.example.net max_age: 604800

L’identifiant dans le DNS sert d’horloge : quand vous modifiez le fichier, vous changez l’identifiant, et les expéditeurs savent qu’il faut le relire. C’est tout le mécanisme de mise à jour.

Les trois modes, et le seul qui compte

La section 5 de la RFC définit exactement ce que fait un expéditeur selon le mode que vous déclarez.

« « enforce »: In this mode, Sending MTAs MUST NOT deliver the message to hosts that fail MX matching or certificate validation or that do not support STARTTLS. »

« « testing »: In this mode, Sending MTAs that also implement the TLSRPT specification send a report indicating policy application failures […]; in any case, messages may be delivered as though there were no MTA-STS validation failure. »

« « none »: In this mode, Sending MTAs should treat the Policy Domain as though it does not have any active policy. »

Le mode testing ne protège rien. Il observe. C’est précisément son intérêt : vous le publiez d’abord, vous lisez les rapports, et vous ne passez en enforce qu’une fois certain qu’aucun de vos MX ne fait échouer la validation.

Passer directement en enforce avec un certificat expiré sur un MX secondaire, c’est refuser son propre courrier entrant. La RFC prévoit d’ailleurs un garde-fou : « In all cases, MTAs SHOULD treat such failures as transient errors and retry delivery later. » L’erreur est temporaire, donc réparable, mais pendant ce temps le courrier attend.

Un dernier réglage mérite attention. La durée de vie maximale de la politique est bornée : « max_age: Max lifetime of the policy (plaintext non-negative integer seconds, maximum value of 31557600). » Un an au plus, et la RFC recommande de rester « in the range of weeks or greater ». Une valeur trop courte multiplie les relectures, une valeur trop longue rend une correction lente à se propager.

Le rapport, sans lequel vous êtes aveugle

La norme jumelle, RFC 8460, publiée le même mois, décrit le canal de retour. Son abstract est explicite sur le fait qu’elle couvre aussi bien STARTTLS que DANE et MTA-STS :

« These protocols can fail due to misconfiguration or active attack, leading to undelivered messages or delivery over unencrypted or unauthenticated channels. This document describes a reporting mechanism and format by which sending systems can share statistics and specific information about potential failures with recipient domains. »

La publication est aussi légère que celle de MTA-STS : un enregistrement TXT sur _smtp._tls.votredomaine.fr désignant une adresse de réception. Vous recevez ensuite, chaque jour, des rapports JSON envoyés par les serveurs qui vous écrivent.

Le rapport est ce qui distingue un déploiement sérieux d’un enregistrement DNS décoratif. Sans lui, vous publiez une exigence sans jamais savoir combien de connexions y échouent.

Ce qui prouve que ce n’est pas théorique

Microsoft publie, dans sa liste des codes de non-remise d’Exchange Online, un code dédié :

« 5.7.5 — Remote certificate failed MTA-STS validation. »

Un opérateur de cette taille n’inscrit pas un code de rejet dans sa documentation pour une norme qu’il n’applique pas. Quand un domaine destinataire publie une politique en enforce et que son certificat ne valide pas, Microsoft refuse la remise et le dit avec ce code.

C’est aussi un rappel utile : l’obligation de TLS figure déjà dans les exigences imposées aux expéditeurs groupés. MTA-STS ne fait qu’ajouter la partie que ces exigences ne couvrent pas : la vérification du certificat et l’interdiction du repli en clair.

Ce que vous faites demain matin

Interrogez d’abord votre propre domaine : dig +short TXT _mta-sts.votredomaine.fr et dig +short TXT _smtp._tls.votredomaine.fr. Deux réponses vides sont le cas le plus fréquent, y compris dans des entreprises qui ont soigné DMARC.

Commencez par TLS-RPT seul. Il ne change rien au comportement des expéditeurs, il ne peut donc rien casser, et il vous donne en quelques jours une mesure de ce qui se passe réellement sur vos connexions entrantes.

Publiez ensuite MTA-STS en mode testing, avec la liste exacte de vos MX. Vérifiez que chacun présente un certificat valide pour le nom annoncé, y compris les secondaires que personne ne surveille.

Ne passez en enforce qu’après une période sans échec dans les rapports. Et notez la date de renouvellement de vos certificats MX dans le même agenda que celle de vos noms de domaine : à partir de ce jour, un certificat expiré ne dégrade plus le chiffrement, il arrête le courrier.

Sources

LaFactory travaille l’emailing sur pièces : en-têtes, enregistrements DNS, journaux de rejet. Aucune promesse de taux d’ouverture, jamais. Contactez-nous pour un audit de délivrabilité.