MTA-STS et TLS-RPT : chiffrer le transport de vos e-mails
SPF, DKIM et DMARC forment la première ligne de défense de votre e-mail : ils empêchent qu'on usurpe votre nom de domaine. Mais ils ne disent rien de la confidentialité du transport lui-même. Or, par défaut, la remise d'un e-mail entre deux serveurs (SMTP) tente le chiffrement TLS de façon « opportuniste » : si la négociation échoue ou est sabotée, le message part quand même… en clair.
C'est précisément cette faille qu'un attaquant placé sur le réseau peut exploiter : en rétrogradant la connexion (downgrade), il force l'échange en clair et lit vos e-mails entrants. MTA-STS (RFC 8461) referme cette porte en déclarant que votre domaine EXIGE le TLS, et TLS-RPT (RFC 8460) vous fait remonter chaque tentative d'échec. Ensemble, ils rendent le transport de vos e-mails robuste et supervisé.
Ce que MTA-STS ajoute à SPF/DMARC
SPF et DMARC répondent à la question « cet e-mail vient-il vraiment de ce domaine ? ». MTA-STS répond à une question différente et complémentaire : « la connexion qui achemine cet e-mail vers moi est-elle bien chiffrée et authentifiée ? ». Sans MTA-STS, un attaquant peut supprimer la commande STARTTLS pendant la négociation SMTP pour forcer un envoi en clair, ou usurper votre serveur de messagerie avec un certificat invalide.
Avec MTA-STS en mode « enforce », les serveurs expéditeurs compatibles (Gmail, Outlook, la plupart des grands fournisseurs) refusent de délivrer l'e-mail si le TLS échoue ou si le certificat de votre serveur n'est pas valide. Le message est différé plutôt qu'exposé. C'est une protection sans contrepartie pour la confidentialité et l'intégrité de vos communications.
Les trois pièces à mettre en place
MTA-STS repose sur trois éléments cohérents. D'abord un enregistrement DNS TXT sur _mta-sts.votre-domaine, qui signale l'existence d'une politique et sa version (un identifiant que vous changez à chaque modification). Ensuite un fichier de politique servi en HTTPS sur un sous-domaine dédié : https://mta-sts.votre-domaine/.well-known/mta-sts.txt, qui liste vos serveurs de messagerie (MX) et le mode souhaité.
Le mode se décline en trois valeurs : « testing » (on observe sans bloquer, idéal pour démarrer), « enforce » (on bloque en cas d'échec TLS) et « none » (désactivation). On commence toujours en « testing » couplé à TLS-RPT, le temps de confirmer qu'aucun flux légitime n'est cassé, avant de passer en « enforce ».
Exemple de configuration
Voici une configuration type. Adaptez les noms de serveurs MX à ceux de votre hébergeur de messagerie, et incrémentez l'identifiant de version (« id ») à chaque changement de la politique pour que les serveurs expéditeurs rechargent le fichier.
_mta-sts.exemple.com. IN TXT "v=STSv1; id=20260705120000Z"
_smtp._tls.exemple.com. IN TXT "v=TLSRPTv1; rua=mailto:tls-reports@exemple.com"version: STSv1
mode: testing
mx: mail.exemple.com
mx: *.exemple.com
max_age: 604800Passer en production sans risque
Restez en mode « testing » au moins une à deux semaines et lisez les rapports TLS-RPT que vous recevez : ils listent les tentatives de remise et leurs éventuels échecs de négociation TLS. Tant que vous voyez des échecs de serveurs légitimes, corrigez (certificat de votre MX, chaîne de confiance, correspondance des noms) avant d'aller plus loin.
Une fois les rapports propres, basculez le fichier de politique en « mode: enforce » et augmentez « max_age » (par exemple 1209600, soit deux semaines) pour que les expéditeurs mémorisent durablement votre exigence de TLS. Relancez un audit CheckCyber : le vecteur « transport e-mail sécurisé » doit passer au vert.
[ FAQ // QUESTIONS FRÉQUENTES ]
▸MTA-STS remplace-t-il SPF et DMARC ?
Non, il les complète. SPF, DKIM et DMARC authentifient l'expéditeur et empêchent l'usurpation de votre domaine ; MTA-STS protège la confidentialité et l'intégrité du transport TLS des e-mails entrants. Les deux couches répondent à des menaces différentes et doivent coexister.
▸Ai-je besoin de MTA-STS si je n’envoie pas d’e-mails ?
MTA-STS concerne surtout la réception : il protège les e-mails que d'autres vous envoient. Si votre domaine possède des enregistrements MX (il reçoit donc des e-mails), MTA-STS est pertinent. S'il n'a aucun MX, la protection ne s'applique pas et CheckCyber ne la réclame pas.
▸Le mode « testing » protège-t-il vraiment ?
Le mode « testing » ne bloque encore rien : il sert à collecter des rapports TLS-RPT pour vérifier que le passage à « enforce » ne cassera aucun flux légitime. La protection effective (refus de remise en clair) n'est active qu'en mode « enforce » : c'est l'objectif à atteindre après une phase d'observation.
[ PASSEZ À L’ACTION ]
Votre site est-il concerné ?
Lancez un audit de surface gratuit et obtenez en quelques secondes la liste exacte de vos failles, avec le correctif pour chacune. Anonyme, sans inscription.
▶ Auditer mon site[ À LIRE AUSSI ]
[ CheckCyber // MIS À JOUR LE 2026-07-05 ]