MTA-STS (Mail Transfer Agent Strict Transport Security)
HTTPS-basiertes Verfahren zur Erzwingung von TLS-Verschlüsselung zwischen Mailservern — verhindert Downgrade-Angriffe auf den E-Mail-Transport ohne DNSSEC-Abhängigkeit.
MTA-STS (Mail Transfer Agent Strict Transport Security) ist ein in RFC 8461 spezifiziertes Protokoll, das sendenden Mailservern signalisiert, dass die Empfängerdomain TLS-Verschlüsselung zwingend voraussetzt. Es verhindert sogenannte Downgrade-Angriffe, bei denen ein Angreifer die STARTTLS-Aushandlung zwischen zwei Mailservern unterdrückt und die Verbindung auf unverschlüsselten Klartext zurückfällt.
Das Problem: Opportunistisches STARTTLS
Obwohl nahezu alle Mailserver heute STARTTLS unterstützen, ist diese Verschlüsselung standardmäßig nicht erzwungen. Wenn der sendende Server eine STARTTLS-Aushandlung initiiert und die Antwort des Empfängers von einem Angreifer unterdrückt wird, fällt die Verbindung stillschweigend auf unverschlüsselten Transport zurück. Weder der Absender noch der Empfänger bemerken den Angriff. Dieses Verhalten ist kein Bug, sondern das beabsichtigte Design von opportunistischem STARTTLS — Kompatibilität wurde über Sicherheit gestellt.
MTA-STS ändert dieses Verhalten grundlegend: Durch die veröffentlichte Policy weiß der sendende Server, dass TLS nicht optional ist. Schlägt die TLS-Verbindung fehl, wird die Zustellung verweigert statt auf Klartext zurückzufallen.
Architektur: DNS-Record und Policy-Datei
MTA-STS kombiniert zwei Komponenten. Ein DNS-TXT-Record unter _mta-sts.example.de signalisiert die Existenz einer Policy und enthält eine Versions-ID (z. B. v=STSv1; id=20260301). Die eigentliche Policy wird als Textdatei unter https://mta-sts.example.de/.well-known/mta-sts.txt bereitgestellt und über das TLS-Zertifikat des Webservers authentifiziert.
Die Policy-Datei enthält drei wesentliche Felder: mode (den Durchsetzungsmodus), mx (die gültigen MX-Hostnamen, für die TLS erzwungen wird) und max_age (die Cache-Dauer in Sekunden). Ein sendender Mailserver, der den DNS-Record entdeckt, ruft die Policy ab und speichert sie für die angegebene max_age-Dauer zwischen. Solange die Policy im Cache ist, wird TLS für alle Zustellungen an diese Domain erzwungen — selbst wenn der DNS-Record zwischenzeitlich nicht erreichbar sein sollte.
Policy-Modi im Detail
Der Modus testing ist der empfohlene Einstieg. Sendende Server werten die Policy aus und melden Probleme über TLS-RPT, liefern E-Mails aber auch bei TLS-Fehlern zu. So können Konfigurationsfehler identifiziert werden, ohne den E-Mail-Fluss zu unterbrechen.
Im Modus enforce wird TLS strikt durchgesetzt: Keine gültige TLS-Verbindung bedeutet keine Zustellung. Dieser Modus bietet maximalen Schutz, erfordert aber die Gewissheit, dass alle MX-Server gültige Zertifikate vorlegen und TLS korrekt konfiguriert haben.
Der Modus none deaktiviert die Policy und wird verwendet, um MTA-STS zurückzuziehen. In der Praxis sollte zwischen der Testing- und der Enforce-Phase ausreichend Zeit liegen — je nach E-Mail-Volumen und Infrastrukturkomplexität mehrere Wochen.
TLS-RPT: Das Reporting-Gegenstück
TLS Reporting (RFC 8460) ergänzt MTA-STS um eine Reporting-Funktion, die konzeptionell mit DMARC-Reporting vergleichbar ist. Über einen DNS-TXT-Record unter _smtp._tls.example.de wird eine Berichtsadresse konfiguriert. Sendende Mailserver schicken tägliche Berichte im JSON-Format, die TLS-Verbindungsversuche, Zertifikatsfehler und Policy-Auswertungen dokumentieren.
TLS-RPT ist nicht nur für MTA-STS relevant, sondern meldet auch Probleme mit DANE/TLSA-Validierungen. Ohne TLS-RPT fehlt jegliche Sichtbarkeit darüber, ob die Transportverschlüsselung in der Praxis tatsächlich funktioniert. Die Berichte zeigen, welche sendenden Server Schwierigkeiten mit der TLS-Verbindung haben und ob Zertifikatswechsel Probleme verursachen.
MTA-STS vs. DANE
MTA-STS und DANE verfolgen dasselbe Ziel, nutzen aber grundverschiedene Vertrauensmodelle. DANE verankert das Zertifikat über TLSA-Records im DNS und nutzt DNSSEC als kryptografischen Vertrauensanker — das ist konzeptionell eleganter und kryptografisch stärker, setzt aber DNSSEC voraus. MTA-STS nutzt das HTTPS-Zertifikat des Webservers als Vertrauensanker und funktioniert ohne DNSSEC.
Für die meisten deutschen Unternehmen, deren Domains kein DNSSEC haben, ist MTA-STS derzeit der pragmatischere Weg zur Transportabsicherung. Unternehmen mit aktivem DNSSEC sollten idealerweise beide Verfahren parallel implementieren: DANE für Mailserver, die DNSSEC-validierend arbeiten, und MTA-STS als Fallback für alle anderen.
max_age und Sicherheitsüberlegungen
Die Wahl des max_age-Werts hat unmittelbare Sicherheitsimplikationen. Ein kurzer Wert (z. B. 86400 Sekunden = ein Tag) erleichtert Policy-Änderungen, bietet aber ein schmales Zeitfenster, in dem ein Angreifer den DNS-Record unterdrücken und sendende Server dazu bringen könnte, die Policy nicht zu erneuern. Ein langer Wert (z. B. 2592000 Sekunden = 30 Tage) schützt besser gegen solche Angriffe, da die gecachte Policy über Wochen hinweg gültig bleibt. In der Praxis empfiehlt sich ein kurzer max_age während der Testphase und ein Wert von mindestens einer Woche im Enforce-Modus.
Praxistipp
Ob Ihre Domain MTA-STS korrekt konfiguriert hat, prüfen Sie mit dem MTA-STS-Check. Das Tool analysiert den DNS-TXT-Record, ruft die Policy-Datei ab und validiert die MX-Hostnamen gegen die tatsächlichen MX-Records. Ergänzend zeigt der SMTP-TLS-Check, ob Ihre Domain auch DANE/TLSA implementiert hat. Für eine vollständige E-Mail-Sicherheit sollten neben der Transportverschlüsselung auch SPF, DKIM und DMARC korrekt konfiguriert sein — prüfbar mit dem E-Mail Security Check.