SaaSFort Les éditeurs qui vendent en Allemagne rencontrent souvent une question qui les surprend : comment le chiffrement du transport est-il imposé pour le courrier envoyé à votre domaine ?
Elle surprend parce que, de leur propre évaluation, leur sécurité e-mail est en ordre. SPF est publié, DKIM signe le courrier sortant, DMARC est en p=quarantine ou plus strict. Tous les vérificateurs courants affichent vert.
La question porte sur tout autre chose, et elle vient de la BSI TR-03108.
Ce qu’exige la directive
TR-03108 est la directive technique allemande pour le transport sécurisé du courrier. Sa particularité est qu’elle ne traite pas les mécanismes de sécurité du transport comme un menu. Elle attend DANE, MTA-STS et TLS-RPT ensemble, et le raisonnement mérite d’être compris, car il explique pourquoi « nous avons DMARC » n’est pas une réponse.
Les trois répondent à des questions différentes :
| Mécanisme | Question à laquelle il répond |
|---|---|
| SPF / DKIM / DMARC | Ce message vient-il réellement de l’expéditeur annoncé ? |
| MTA-STS | Les émetteurs doivent-ils utiliser du TLS authentifié pour m’atteindre ? |
| DANE | Idem, mais authentifié par DNSSEC plutôt que par une autorité de certification |
| TLS-RPT | La remise en TLS a-t-elle réellement réussi, et sinon pourquoi ? |
Authentification de l’expéditeur et chiffrement du transport sont orthogonaux. Un domaine peut avoir un DMARC parfait et accepter tout de même du courrier sur une connexion qu’un attaquant a ramenée au clair, car l’annonce STARTTLS elle-même n’est pas authentifiée.
DANE et MTA-STS ne sont pas des alternatives
C’est le point que la plupart des équipes comprennent de travers à la première lecture.
DANE publie un enregistrement TLSA dans le DNS, authentifié par DNSSEC. Il ne dépend pas du système d’autorités de certification, ce qui le rend cryptographiquement plus fort. Il exige DNSSEC sur votre zone, ce qui reste la principale raison de sa faible adoption.
MTA-STS publie une politique en HTTPS, authentifiée par le système d’autorités. Aucun DNSSEC requis, donc déployable aujourd’hui sur pratiquement n’importe quel domaine.
Les émetteurs qui prennent en charge les deux préfèrent DANE et retombent sur MTA-STS quand la validation DNSSEC n’est pas disponible. Déployer les deux relève donc de la défense en profondeur et non de la redondance, et c’est précisément pourquoi la directive attend les deux.
Pour un éditeur SaaS sans DNSSEC sur sa zone, l’ordre pratique est : MTA-STS et TLS-RPT d’abord, car ils peuvent partir cette semaine, puis DNSSEC et DANE comme projet distinct.
Pourquoi cela apparaît dans les évaluations NIS2
La transposition allemande de NIS2 confie au BSI le rôle de supervision, et la supervision du BSI s’appuie sur ses directives techniques pour définir ce que « l’état de l’art » signifie en pratique.
L’article 21(2)(h) de NIS2 exige des politiques de cryptographie et de chiffrement. La directive n’énumère aucun mécanisme. TR-03108 comble ce vide pour l’e-mail en contexte allemand, et c’est ainsi qu’une directive qui ne vous lie pas finit par façonner la question qu’on vous pose.
Si vous avez reçu un courrier du BSI, la sécurité du transport e-mail est un constat qui se clôt vite et démontre votre réactivité, ce qui vaut plus, dans cette conversation, que son poids technique.
Le déploiement, concrètement
Trois enregistrements DNS et un fichier statique.
; 1. Annoncer la politique MTA-STS
_mta-sts.example.de. IN TXT "v=STSv1; id=20260919120000"
; 2. Canal de remontée
_smtp._tls.example.de. IN TXT "v=TLSRPTv1; rua=mailto:[email protected]"
Puis, servi sur https://mta-sts.example.de/.well-known/mta-sts.txt :
version: STSv1
mode: enforce
mx: mx1.example.de
mx: mx2.example.de
max_age: 604800
Le sous-domaine a besoin d’un certificat valide, que tout hébergeur statique fournit. Les tenants Microsoft 365 utilisent le motif *.mail.protection.outlook.com dans le champ mx.
Commencez en mode: testing, lisez les rapports TLS-RPT quelques semaines, puis passez en enforce. Basculer directement en enforce avec une liste mx incomplète est le seul scénario où cela provoque une panne.
Ce que le marché allemand récompense
L’adoption de MTA-STS sur le million de domaines les plus visités est inférieure à un pour cent. L’asymétrie qui en résulte est l’argument pratique : le contrôle coûte un après-midi, presque aucun concurrent ne l’a, et il est vérifiable de l’extérieur par quiconque vous évalue.
Pour un éditeur qui se positionne face au Mittelstand ou répond à un questionnaire aligné sur le BSI IT-Grundschutz, cette combinaison est rare : la plupart des différenciateurs sont coûteux et invisibles. Celui-ci est bon marché et vérifiable.
Comment le vérifier
dig +short TXT _mta-sts.example.de
curl -s https://mta-sts.example.de/.well-known/mta-sts.txt
dig +short TXT _smtp._tls.example.de
dig +short TLSA _25._tcp.mx1.example.de # DANE, nécessite DNSSEC
Un scan SaaSFort rapporte le mode MTA-STS plutôt que la simple présence d’un enregistrement, car une politique en testing satisfait une case à cocher et ne protège rien.
En résumé
Les acheteurs allemands interrogent le transport e-mail parce que leur directive nationale le traite comme un contrôle distinct de l’authentification de l’expéditeur. À juste titre.
MTA-STS et TLS-RPT sont déployables dès maintenant sur n’importe quel domaine. DANE est le mécanisme le plus fort et attend DNSSEC. Faire la première paire immédiatement est le bon ordre.
Passez de la lecture à l'action
Scannez votre domaine gratuitement. Premiers résultats en moins de 10 secondes — sans inscription.