SaaSFort Anbieter, die nach Deutschland verkaufen, treffen oft auf eine Frage, die sie überrascht: Wie wird die Transportverschlüsselung für E-Mails an Ihre Domain durchgesetzt?
Sie überrascht, weil ihre E-Mail-Sicherheit nach eigener Einschätzung in Ordnung ist. SPF ist veröffentlicht, DKIM signiert ausgehende Mail, DMARC steht auf p=quarantine oder strenger. Jedes gängige Prüfwerkzeug meldet grün.
Die Frage zielt auf etwas ganz anderes, und sie kommt aus BSI TR-03108.
Was die Richtlinie verlangt
TR-03108 ist die deutsche Technische Richtlinie für sicheren E-Mail-Transport. Ihr Kennzeichen ist, dass sie Transportsicherheitsmechanismen nicht als Auswahlmenü behandelt. Sie erwartet DANE, MTA-STS und TLS-RPT gemeinsam, und die Begründung lohnt das Verständnis, denn sie erklärt, warum “wir haben DMARC” keine Antwort ist.
Die drei beantworten verschiedene Fragen:
| Mechanismus | Beantwortete Frage |
|---|---|
| SPF / DKIM / DMARC | Stammt diese Nachricht wirklich vom angegebenen Absender? |
| MTA-STS | Müssen Absender authentifiziertes TLS nutzen, um mich zu erreichen? |
| DANE | Dasselbe, aber über DNSSEC statt über eine Zertifizierungsstelle authentifiziert |
| TLS-RPT | Hat die TLS-Zustellung tatsächlich geklappt, und wenn nicht, warum? |
Absenderauthentifizierung und Transportverschlüsselung sind orthogonal. Eine Domain kann perfektes DMARC haben und dennoch Mail über eine Verbindung annehmen, die ein Angreifer auf Klartext heruntergestuft hat, weil die STARTTLS-Ankündigung selbst nicht authentifiziert ist.
DANE und MTA-STS sind keine Alternativen
Das ist der Punkt, den die meisten Teams beim ersten Lesen der Richtlinie falsch verstehen.
DANE veröffentlicht einen TLSA-Eintrag im DNS, authentifiziert durch DNSSEC. Es hängt nicht am System der Zertifizierungsstellen, was es kryptografisch stärker macht. Es setzt DNSSEC in Ihrer Zone voraus, und das bleibt der Hauptgrund für die geringe Verbreitung.
MTA-STS veröffentlicht eine Richtlinie über HTTPS, authentifiziert durch das CA-System. Kein DNSSEC nötig, wodurch es heute auf praktisch jeder Domain einsetzbar ist.
Absender, die beides unterstützen, bevorzugen DANE und fallen auf MTA-STS zurück, wenn keine DNSSEC-Validierung verfügbar ist. Beides auszurollen ist daher gestaffelte Verteidigung und keine Redundanz, und genau deshalb erwartet die Richtlinie beides.
Für einen SaaS-Anbieter ohne DNSSEC in der Zone lautet die praktische Reihenfolge: zuerst MTA-STS und TLS-RPT, weil sie diese Woche ausrollbar sind, danach DNSSEC und DANE als eigenes Vorhaben.
Warum es in NIS2-Bewertungen auftaucht
Die deutsche NIS2-Umsetzung weist dem BSI die Aufsichtsrolle zu, und die BSI-Aufsicht stützt sich bei der Frage, was “Stand der Technik” praktisch bedeutet, auf ihre Technischen Richtlinien.
NIS2 Artikel 21(2)(h) verlangt Konzepte für Kryptografie und Verschlüsselung. Die Richtlinie zählt keine Mechanismen auf. TR-03108 füllt diese Lücke für E-Mail im deutschen Kontext, und so prägt eine Richtlinie, die für Sie selbst nicht bindend ist, am Ende die Frage, die man Ihnen stellt.
Wenn Sie ein BSI-Schreiben erhalten haben, ist Transportsicherheit für E-Mail ein Befund, der sich schnell schließen lässt und Reaktionsfähigkeit belegt, was in diesem Gespräch mehr wiegt als sein technisches Gewicht.
Die Umsetzung, konkret
Drei DNS-Einträge und eine statische Datei.
; 1. MTA-STS-Richtlinie ankündigen
_mta-sts.example.de. IN TXT "v=STSv1; id=20260919120000"
; 2. Meldekanal
_smtp._tls.example.de. IN TXT "v=TLSRPTv1; rua=mailto:[email protected]"
Und unter 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
Die Subdomain braucht ein gültiges Zertifikat, das jeder Statik-Hoster mitbringt. Microsoft-365-Tenants tragen im Feld mx das Muster *.mail.protection.outlook.com ein.
Starten Sie mit mode: testing, lesen Sie einige Wochen TLS-RPT-Berichte, dann wechseln Sie auf enforce. Der direkte Sprung auf enforce mit unvollständiger mx-Liste ist der eine Weg, auf dem das einen Ausfall verursacht.
Was der deutsche Markt honoriert
Die MTA-STS-Verbreitung über die eine Million meistbesuchten Domains liegt unter einem Prozent. Die daraus entstehende Asymmetrie ist das praktische Argument: Der Mechanismus kostet einen Nachmittag, fast kein Wettbewerber hat ihn, und jeder, der Sie bewertet, kann ihn extern prüfen.
Für einen Anbieter, der sich gegenüber Mittelstandskunden positioniert oder einen an BSI IT-Grundschutz orientierten Fragebogen beantwortet, ist diese Kombination ungewöhnlich: Die meisten Unterscheidungsmerkmale sind teuer und unsichtbar. Dieses ist billig und überprüfbar.
Prüfung
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, benötigt DNSSEC
Ein SaaSFort-Scan meldet den MTA-STS-Modus statt bloß das Vorhandensein eines Eintrags, denn eine Richtlinie in testing erfüllt ein Häkchen und schützt nichts.
Kurzfassung
Deutsche Kunden fragen nach dem Mailtransport, weil ihre nationale Richtlinie ihn als eigenen Kontrollmechanismus neben der Absenderauthentifizierung führt. Zu Recht.
MTA-STS und TLS-RPT sind heute auf jeder Domain ausrollbar. DANE ist der stärkere Mechanismus und wartet auf DNSSEC. Das erste Paar sofort zu erledigen ist die richtige Reihenfolge.
Von der Theorie zur Praxis
Scannen Sie Ihre Domain kostenlos. Erste Ergebnisse in unter 10 Sekunden — ohne Registrierung.