MTA-STS und TLS-RPT: E-Mail-Verschlüsselung erzwingen

Warum SPF, DKIM und DMARC den Transportweg nicht schützen

E-Mail-Authentifizierung und Transportverschlüsselung lösen zwei völlig verschiedene Probleme. SPF, DKIM und DMARC sind Authentifizierungsverfahren: Sie belegen, dass eine Nachricht tatsächlich von der Domain stammt, die im Absender steht, und schützen so vor Spoofing und Phishing. Was sie nicht tun: den Übertragungskanal zwischen den Mailservern absichern. Eine perfekt signierte, DMARC-konforme E-Mail kann trotzdem im Klartext über das Netz laufen, wenn der sendende Server keine TLS-Verbindung erzwingt.

Die Trennung ist wichtig, weil beide Ebenen unabhängig angegriffen werden. Authentifizierung wehrt gefälschte Absender ab; Transportverschlüsselung verhindert das Mitlesen und Manipulieren unterwegs. Wer nur die eine Seite absichert, lässt die andere offen. Deshalb ist MTA-STS kein Ersatz für DMARC, sondern die logische Ergänzung. Wie man die Authentifizierungsseite auswertet, zeigt der Beitrag DMARC-Reports auswerten und Spoofing erkennen; dieser Artikel widmet sich dem Transportweg.

Die letzte Spalte macht den Unterschied deutlich: Erst MTA-STS verwandelt die opportunistische, jederzeit abschaltbare TLS-Verbindung in eine verbindliche Anforderung. TLS-RPT wiederum schützt nicht selbst, sondern liefert die Sichtbarkeit, ohne die eine Durchsetzung blind bliebe.

STARTTLS, opportunistische Verschlüsselung und der Downgrade-Angriff

SMTP wurde in den 1980er-Jahren ohne jede Verschlüsselung entworfen. Die später nachgerüstete STARTTLS-Erweiterung ermöglicht es zwei Mailservern, innerhalb der bestehenden Klartext-Verbindung auf TLS umzuschalten. Der Haken: STARTTLS ist opportunistisch. Bietet die Gegenseite kein TLS an oder schlägt der Handshake fehl, fällt die Zustellung stillschweigend auf Klartext zurück — Hauptsache, die Mail kommt an. Diese Nachgiebigkeit ist genau die Schwachstelle.

Der Angriff ist kein theoretisches Konstrukt: Die MTA-STS-Spezifikation nennt STARTTLS-Downgrade und Man-in-the-Middle ausdrücklich als Motivation (RFC 8461). Transportsicherheit ist außerdem ein bewegliches Ziel — parallel zur Verschlüsselung von heute steht die Migration auf quantensichere Verfahren an, die der Beitrag Post-Quantum-TLS mit ML-KEM überwachen behandelt. MTA-STS bildet dabei die Klammer, die verhindert, dass eine vorhandene TLS-Fähigkeit überhaupt umgangen werden kann.

Wie MTA-STS funktioniert: DNS-Record, Policy-Datei und Zertifikat

MTA-STS besteht aus drei Bausteinen, die zusammenpassen müssen. Fehlt einer oder ist er falsch konfiguriert, ignoriert der sendende Server die Policy und fällt auf opportunistisches Verhalten zurück. Die drei Bausteine sind ein DNS-Record als Signal, eine über HTTPS ausgelieferte Policy-Datei und ein gültiges Zertifikat auf dem MX-Host.

_mta-sts.ihre-domain.de.  IN TXT  "v=STSv1; id=2026070701"

# v   = Versionskennung, aktuell nur STSv1 zulässig
# id  = beliebige alphanumerische Kennung der aktuellen Policy;
#       muss bei jeder Änderung der Policy-Datei neu gesetzt werden,
#       damit sendende Server die Policy erneut laden

version: STSv1
mode: enforce
mx: mail.ihre-domain.de
mx: *.ihre-domain.de
max_age: 604800

Ein sendender Server lädt die Policy beim ersten Kontakt, prüft das MX-Zertifikat gegen die mx:-Muster und speichert die Policy für die Dauer von max_age im Cache. Dieses Trust-on-First-Use-Modell (TOFU) bedeutet: Nur der allererste Abruf ist ungeschützt, danach gilt die zwischengespeicherte Anforderung. max_age kann laut Spezifikation bis zu 31.557.600 Sekunden — ein Jahr — betragen (RFC 8461); in der Praxis wählt man in der Testphase kurze Werte und verlängert sie beim Umstieg auf enforce. Welche Zertifizierungsstellen überhaupt Zertifikate für die Domain ausstellen dürfen, lässt sich zusätzlich über CAA-Records zur DNS-Härtung eingrenzen.

Die drei Policy-Modi: none, testing und enforce

Der mode-Wert in der Policy-Datei entscheidet, wie ein sendender Server auf einen fehlgeschlagenen TLS-Check reagiert. Genau dieser eine Parameter trennt einen reinen Beobachtungsbetrieb von der echten Durchsetzung — und ist der Hebel für eine risikoarme Einführung.

Im Modus testing verhält sich der sendende Server so, als gäbe es die Policy noch nicht — er stellt auch bei fehlgeschlagenem TLS zu, meldet den Fehlversuch aber über TLS-RPT zurück. Erst enforce macht die TLS-Anforderung verbindlich: Passt das MX-Zertifikat nicht oder kommt kein TLS zustande, wird die Nachricht nicht zugestellt, sondern mit einem Fehler an den Absender zurückgegeben (RFC 8461).

TLS-RPT: fehlgeschlagene Verbindungen sichtbar machen

MTA-STS allein arbeitet im Verborgenen: Ohne Rückmeldung wissen Sie nicht, ob sendende Server Ihre Policy überhaupt korrekt anwenden oder an welchen MX-Hosts TLS scheitert. Diese Lücke schließt TLS-RPT (RFC 8460). Ein zusätzlicher DNS-Record lädt sendende Server ein, täglich aggregierte Berichte über Erfolg und Misserfolg der TLS-Aushandlung an eine von Ihnen bestimmte Adresse zu schicken.

_smtp._tls.ihre-domain.de.  IN TXT  "v=TLSRPTv1; rua=mailto:tls-reports@ihre-domain.de"

# v    = Versionskennung (TLSRPTv1)
# rua  = Zieladresse der Aggregatberichte; mailto: oder https: erlaubt

Die Berichte kommen als maschinenlesbares JSON, in der Regel einmal pro Tag pro meldendem Anbieter (RFC 8460). Jede Zeile nennt den Policy-Typ (sts, tlsa oder no-policy-found), die Zahl erfolgreicher und fehlgeschlagener Verbindungen sowie den konkreten Fehlertyp. Diese Fehlertypen sind das eigentliche Diagnosewerkzeug:

• starttls-not-supported — der MX-Host bietet gar kein STARTTLS an oder das Kommando wurde unterdrückt.
• certificate-expired — das Zertifikat des MX-Hosts ist abgelaufen.
• certificate-host-mismatch — der Zertifikatsname passt nicht zur MX-Adresse.
• validation-failure — die Zertifikatskette ließ sich nicht bis zu einer vertrauenswürdigen Wurzel prüfen.
• sts-policy-fetch-error — die Policy-Datei war beim Abruf nicht erreichbar.

Gerade in der Testphase sind diese Meldungen unverzichtbar: Sie zeigen, welche legitimen Gegenstellen noch Probleme haben, bevor enforce daraus abgelehnte Mails macht. Wer parallel die Zertifikate im Blick behält — etwa über Certificate-Transparency-Logs überwachen —, erkennt ablaufende oder unpassende Zertifikate, bevor sie in den TLS-RPT-Berichten als Fehler auftauchen.

Der sichere Weg von testing zu enforce

Die größte Sorge bei der Einführung: Werden legitime Mails plötzlich abgewiesen? Berechtigt — ein zu früher Sprung auf enforce kann Zustellungen an Gegenstellen mit veraltetem TLS blockieren. Deshalb erfolgt der Übergang in kontrollierten Stufen, gestützt auf die TLS-RPT-Daten. Das UK NCSC empfiehlt, mindestens einen Monat im Testmodus zu beobachten, bevor auf enforce umgestellt wird (UK NCSC).

1. Records vorbereiten: DNS-TXT _mta-sts und _smtp._tls anlegen, die Policy-Datei mit mode: testing unter der mta-sts.-Subdomain über HTTPS bereitstellen. Das NCSC nennt für die Testphase ein max_age von 86.400 Sekunden — also 24 Stunden (UK NCSC).
2. Beobachten: Mindestens einen Monat die TLS-RPT-Berichte auswerten und prüfen, ob und wo TLS-Verbindungen scheitern (UK NCSC).
3. Fehlerquellen beheben: Abgelaufene Zertifikate erneuern, MX-Muster in der Policy an die tatsächlichen MX-Records angleichen, fehlendes STARTTLS auf eigenen Hosts nachrüsten.
4. Auf enforce umstellen: Wenn über mehrere Wochen keine unerwarteten Fehler mehr auftreten, mode: enforce setzen und max_age erhöhen — das NCSC nennt für den Produktivbetrieb mindestens 1.209.600 Sekunden, also zwei Wochen (UK NCSC).
5. Dauerhaft überwachen: Neue MX-Hosts, ein Provider-Wechsel oder ein abgelaufenes Zertifikat können die Lage jederzeit ändern. Die Beobachtung endet nicht mit dem Umstieg.

Verbreitung und Realität: unter einem Prozent — und oft fehlerhaft

Trotz klarer Vorteile bleibt die Verbreitung niedrig. Die ACM-IMC-2025-Studie hat über 87 Millionen Domains aus vier TLDs über 31 Monate vermessen. Zum Stichtag September 2024 veröffentlichten nur 0,07 % der .com-Domains mit MX-Record, 0,09 % der .net- und 0,13 % der .org-Domains eine MTA-STS-Policy (ACM IMC 2025). Selbst unter den populärsten Domains ist das Bild dünn: Bei den Top-10.000-Domains liegt die Quote bei 1,2 %, bei den hinteren Rangbereichen nur bei 0,4 % (ACM IMC 2025).

Noch aufschlussreicher als die reine Verbreitung ist die Qualität der Umsetzung. Von den fehlerhaften Setups führen laut Studie 3,2 % zu tatsächlichen Zustellfehlern gegenüber MTA-STS-konformen Sendern (ACM IMC 2025). Ein Großteil der Einzelfehler entsteht am Policy-Host: 35 % der selbst betriebenen und 3,9 % der über Dritte betriebenen Policy-Server scheitern schon am TLS-Handshake (ACM IMC 2025). Und auf der Senderseite prüfen nur 19,6 % der Domains MTA-STS überhaupt, wenn sie an eine MTA-STS-fähige Domain zustellen (ACM IMC 2025) — die Durchsetzung hängt also an beiden Enden.

Typische Fallstricke bei MTA-STS und TLS-RPT

Die Studienlage zeigt, dass die meisten Probleme nicht aus dem Konzept, sondern aus der Betriebspraxis stammen. Vier Fehlerbilder tauchen besonders häufig auf — und alle lassen sich durch kontinuierliche Überwachung frühzeitig erkennen.

MTA-STS, DANE und BSI TR-03108: Einordnung und Compliance

MTA-STS ist nicht der einzige Weg zu erzwungener Transportverschlüsselung. Die Alternative heißt DANE (DNS-based Authentication of Named Entities) und bindet den Zertifikatsschlüssel über DNSSEC-signierte TLSA-Records an den MX-Host. Beide Verfahren verfolgen dasselbe Ziel, setzen aber an unterschiedlichen Vertrauensankern an — DANE an DNSSEC, MTA-STS an öffentlich vertrauenswürdigen Zertifikaten plus HTTPS.

Der Unterschied hat auch eine Compliance-Dimension. Die technische Richtlinie BSI TR-03108 macht DANE für den sicheren E-Mail-Transport verbindlich und unterstützt MTA-STS ab Version 2.0 lediglich optional als Alternative (BSI TR-03108). Der Grund: DANE identifiziert die Gegenstelle robuster, weil es nicht auf ein Trust-on-First-Use angewiesen ist. In der Praxis ist DANE aber an DNSSEC gebunden und global nur bei rund 4 % der Domains umgesetzt (ACM IMC 2025) — MTA-STS ist ohne DNSSEC leichter einzuführen. Beide Verfahren schließen sich nicht aus; viele Betreiber veröffentlichen beides parallel.

MTA-STS-Policy und Zertifikate kontinuierlich überwachen

MTA-STS ist kein Einmal-Projekt. Genau die Elemente, die es tragen, können unbemerkt driften: Der DNS-Record kann verschwinden, die Policy-Datei nach einem Server-Umzug 404 liefern, das HTTPS-Zertifikat der mta-sts.-Subdomain ablaufen oder ein neuer MX-Host aus den mx:-Mustern herausfallen. Jede dieser Abweichungen macht die Durchsetzung entweder wirkungslos oder — bei enforce — zur Zustellsperre. Die hohe Fehlerquote von 29,6 % (ACM IMC 2025) ist letztlich ein Betriebsproblem, kein Konzeptfehler.

• DNS-Records: _mta-sts und _smtp._tls auf Existenz und korrekten Inhalt prüfen — verschwindet der Record, ist die Policy tot.
• Policy-Erreichbarkeit: Die Datei unter https://mta-sts.ihre-domain.de/.well-known/mta-sts.txt muss abrufbar bleiben und valides version/mode/mx/max_age enthalten.
• Zertifikate: Sowohl der Policy-Host als auch die MX-Hosts brauchen gültige, zeitlich ausreichende Zertifikate mit passendem Namen.
• MX-Konsistenz: Die mx:-Muster der Policy müssen mit den tatsächlichen MX-Records übereinstimmen.
• TLS-RPT-Auswertung: Die täglichen Berichte auf neue Fehlertypen und steigende Fehlerraten kontrollieren.

Genau hier setzt das DNS- und Domain-Monitoring von XICTRAQ an: Es überwacht die MTA-STS-Policy-Erreichbarkeit, die relevanten DNS-Records und die zugehörigen Zertifikate und meldet Abweichungen, sobald sie auftreten. In Kombination mit Benachrichtigungen über alle relevanten Kanäle erfahren Sie von einem verschwundenen Record oder einem ablaufenden Zertifikat, bevor Mails bouncen. Ergänzend deckt die Blacklist-Überwachung der Mailserver-IPs die Zustellbarkeitsseite ab, während der Security-Scan und die Erkennung von Defacement-Angriffen das Bild zur Gesamtsicherheit der Domain abrunden. So bleibt die mühsam erreichte enforce-Stufe dauerhaft wirksam, statt nach dem nächsten Server-Umzug still zu zerbrechen.

Häufige Fragen zu MTA-STS und TLS-RPT