SaaSFort La plupart des équipes SaaS considèrent la sécurité e-mail comme réglée dès que SPF, DKIM et DMARC sont au vert. Ces trois mécanismes répondent bien à une question : ce message vient-il réellement de vous ?
Ils ne répondent pas du tout à une question entièrement différente : le message a-t-il voyagé chiffré ?
Le trou que personne ne vérifie
SMTP négocie le chiffrement avec une commande en clair. Un serveur émetteur se connecte, le serveur destinataire annonce STARTTLS, et la session bascule en TLS.
Cette annonce n’est pas authentifiée. Un attaquant placé sur le chemin réseau retire la capacité STARTTLS de la réponse du destinataire. L’émetteur, ne voyant aucune offre de chiffrement, délivre en TCP clair. Les deux parties croient s’être comportées correctement. Rien dans SPF, DKIM ou DMARC ne se déclenche, car tous trois valident le message, pas le tunnel.
C’est une attaque par déclassement, praticable depuis aussi longtemps que SMTP existe.
Ce que fait réellement MTA-STS
MTA-STS (RFC 8461) permet à un domaine destinataire de publier un engagement : le courrier qui m’est adressé doit arriver en TLS authentifié, et voici les hôtes autorisés à le recevoir. Un émetteur compatible récupère cette politique, la met en cache, et refuse de délivrer si la connexion ne peut pas être sécurisée.
Elle comporte deux parties, et les deux doivent exister.
Un enregistrement DNS sur _mta-sts.votredomaine.fr :
v=STSv1; id=20260913120000
Un fichier de politique servi en HTTPS sur https://mta-sts.votredomaine.fr/.well-known/mta-sts.txt :
version: STSv1
mode: enforce
mx: mail.votredomaine.fr
mx: *.mail.protection.outlook.com
max_age: 604800
L’exigence HTTPS est le point central : la politique est authentifiée par le système d’autorités de certification, donc un attaquant capable d’altérer le DNS ne peut pas pour autant forger la politique.
Le champ mode résume tout
Trois valeurs sont légales, et une seule protège quoi que ce soit.
| Mode | Comportement | Protège le courrier ? |
|---|---|---|
none | La politique existe mais n’affirme rien | Non |
testing | Les échecs sont signalés, le courrier part quand même en clair | Non |
enforce | L’émetteur refuse de délivrer sur une connexion non protégée | Oui |
Un domaine resté un an en testing a l’apparence d’un contrôle et aucun de ses effets. Cela mérite d’être dit clairement, car c’est l’issue la plus fréquente : les équipes déploient en mode test, les rapports semblent corrects, et personne ne planifie la bascule.
TLS-RPT est ce qui rend enforce sans danger
Passer directement en enforce risque de bloquer silencieusement du courrier légitime, par exemple si un hôte MX manque dans la politique ou présente un certificat qui ne valide pas.
TLS-RPT (RFC 8460) est le canal de retour. Un seul enregistrement TXT :
_smtp._tls.votredomaine.fr. IN TXT "v=TLSRPTv1; rua=mailto:[email protected]"
Les fournisseurs émetteurs livrent alors des synthèses JSON quotidiennes des négociations TLS réussies et échouées vers votre domaine : erreurs de validation de certificat, échecs de handshake, hôtes n’offrant aucun TLS.
La séquence qui fonctionne :
- Publiez TLS-RPT en premier.
- Publiez MTA-STS en
mode: testing. - Lisez les rapports pendant deux à quatre semaines. Corrigez chaque échec qu’ils révèlent.
- Basculez en
mode: enforceune fois les rapports propres. - Continuez à les lire : un certificat qui expire sur un hôte MX y apparaîtra avant qu’un client ne le remarque.
Respecter cet ordre fait la différence entre un contrôle et une panne.
L’adoption est faible, et c’est justement pourquoi les acheteurs le remarquent
Les mesures publiées sur le million de domaines les plus visités situent l’adoption de MTA-STS sous la barre du pour cent en 2026. La conséquence pratique pour un éditeur SaaS B2B est asymétrique : presque personne ne l’a, donc l’avoir est un différenciateur visible dans un questionnaire de sécurité, pour un coût de deux enregistrements DNS et d’un fichier statique.
Pour les éditeurs qui vendent en Allemagne, ce n’est pas un raffinement optionnel. La BSI TR-03108 exige la sécurité du transport pour l’e-mail, et traite DANE, MTA-STS et TLS-RPT comme un ensemble plutôt que comme des alternatives. Si vous répondez à un courrier d’audit de la BSI, l’absence de MTA-STS est un constat que vous pouvez clore en un après-midi.
Où cela se mappe en conformité
- NIS2 article 21(2)(h), cryptographie et chiffrement : chiffrement du transport pour un canal de communication porteur de données métier.
- NIS2 article 21(2)(e), sécurité des réseaux.
- ISO/IEC 27001:2022 A.8.24 (usage de la cryptographie) et A.5.14 (transfert d’information).
- DORA article 9, protection des données en transit, pour les entités financières et leurs prestataires.
Comment le vérifier depuis l’extérieur
Tout l’intérêt d’un contrôle externe est que n’importe qui peut le vérifier sans votre concours, ce qui est aussi la façon dont un acheteur s’y prendra.
# 1. Une politique est-elle annoncée ?
dig +short TXT _mta-sts.votredomaine.fr
# 2. La politique existe-t-elle, et dans quel mode ?
curl -s https://mta-sts.votredomaine.fr/.well-known/mta-sts.txt
# 3. Existe-t-il un canal de remontée ?
dig +short TXT _smtp._tls.votredomaine.fr
Un scan SaaSFort exécute les trois et rapporte le mode, pas seulement la présence d’un enregistrement, car une politique en testing n’est pas un contrôle satisfait.
En résumé
SPF, DKIM et DMARC protègent votre marque de l’usurpation. MTA-STS protège le courrier de vos clients d’une lecture en transit. Ce sont deux problèmes distincts, et le second reste aujourd’hui non traité chez l’écrasante majorité des éditeurs SaaS.
Deux enregistrements DNS et un fichier statique. Commencez en test, lisez les rapports, puis passez en enforce.
Passez de la lecture à l'action
Scannez votre domaine gratuitement. Premiers résultats en moins de 10 secondes — sans inscription.