MTA-STS & TLS-RPT Check

Was ist MTA-STS?

MTA-STS steht für Mail Transfer Agent Strict Transport Security und wurde in RFC 8461 spezifiziert. Das Protokoll löst ein grundlegendes Problem der E-Mail-Verschlüsselung: Obwohl die meisten Mailserver heute STARTTLS unterstützen, ist diese Verschlüsselung rein opportunistisch. Ein aktiver Angreifer kann die STARTTLS-Aushandlung unterdrücken und den sendenden Server dazu bringen, E-Mails unverschlüsselt zu übertragen — ein sogenannter Downgrade-Angriff. MTA-STS verhindert das, indem es sendenden Mailservern über eine veröffentlichte Policy signalisiert, dass die Empfängerdomain TLS zwingend voraussetzt.

Im Unterschied zu DANE, das auf DNSSEC aufbaut und TLSA-Records im DNS verankert, nutzt MTA-STS ein anderes Vertrauensmodell: Die Policy wird als Textdatei unter einer HTTPS-URL bereitgestellt (https://mta-sts.example.de/.well-known/mta-sts.txt), und die Authentizität wird über das TLS-Zertifikat des Webservers sichergestellt. Das macht MTA-STS für viele Organisationen einfacher zu implementieren, da es kein DNSSEC voraussetzt — ein entscheidender Vorteil angesichts der nach wie vor geringen DNSSEC-Verbreitung in Deutschland.

Wie funktioniert MTA-STS?

Die Implementierung besteht aus zwei Komponenten. Erstens wird ein DNS-TXT-Record unter _mta-sts.example.de veröffentlicht, der die Existenz einer MTA-STS-Policy signalisiert und eine Versions-ID enthält. Diese ID ändert sich bei jeder Policy-Aktualisierung und signalisiert sendenden Servern, dass sie die Policy neu abrufen müssen. Zweitens wird die eigentliche Policy-Datei unter https://mta-sts.example.de/.well-known/mta-sts.txt bereitgestellt. Diese Datei enthält den Policy-Modus, die gültigen MX-Hostnamen und die maximale Cache-Dauer.

Wenn ein sendender Mailserver eine E-Mail an Ihre Domain zustellen will, prüft er zunächst den DNS-TXT-Record. Findet er einen _mta-sts-Eintrag, ruft er die Policy-Datei über HTTPS ab. Entsprechend dem Policy-Modus erzwingt er dann eine TLS-Verbindung zum MX-Server und verifiziert dessen Zertifikat gegen die in der Policy gelisteten Hostnamen. Stimmt das Zertifikat nicht überein oder unterstützt der Server kein TLS, wird die Zustellung — im Enforce-Modus — verweigert statt auf Klartext zurückzufallen.

Policy-Modi: Testing, Enforce, None

MTA-STS kennt drei Modi, die eine schrittweise Einführung ermöglichen. Der Modus testing ist der empfohlene Einstieg: Er signalisiert sendenden Servern, dass TLS erwartet wird, erzwingt es aber nicht. Fehlschläge werden über TLS-RPT gemeldet, E-Mails werden jedoch trotzdem zugestellt. So können Sie Probleme identifizieren, bevor sie den E-Mail-Fluss beeinträchtigen.

Im Modus enforce wird die TLS-Anforderung strikt durchgesetzt. Kann der sendende Server keine gültige TLS-Verbindung zum MX-Server aufbauen, wird die Zustellung verweigert. Dieser Modus bietet den höchsten Schutz gegen Downgrade-Angriffe, setzt aber voraus, dass alle MX-Server korrekt konfiguriert sind und gültige Zertifikate vorlegen.

Der Modus none deaktiviert die Policy und signalisiert sendenden Servern, dass keine MTA-STS-Anforderungen gelten. Er wird typischerweise verwendet, um eine bestehende Policy zurückzuziehen.

max_age: Cache-Dauer richtig wählen

Der max_age-Parameter in der Policy-Datei gibt an, wie lange sendende Server die Policy zwischenspeichern sollen — angegeben in Sekunden. Während der Testphase empfiehlt sich ein niedriger Wert von 86400 (ein Tag), damit Änderungen schnell wirksam werden. Sobald die Policy stabil im Enforce-Modus läuft, sollte max_age auf mindestens 604800 (eine Woche) oder idealerweise 2592000 (30 Tage) erhöht werden. Ein langer max_age-Wert schützt davor, dass ein Angreifer den DNS-TXT-Record temporär unterdrückt und der sendende Server mangels gecachter Policy auf unverschlüsselten Transport zurückfällt.

TLS-RPT: Transparenz über Zustellprobleme

TLS-RPT (TLS Reporting, RFC 8460) ist das Reporting-Gegenstück zu MTA-STS. Es wird über einen DNS-TXT-Record unter _smtp._tls.example.de konfiguriert und enthält eine E-Mail-Adresse oder HTTPS-URL, an die sendende Server tägliche Berichte über TLS-Zustellversuche senden. Diese Berichte enthalten Informationen darüber, welche sendenden Server eine TLS-Verbindung aufgebaut haben, ob Zertifikatsfehler aufgetreten sind und ob Zustellungen aufgrund der MTA-STS-Policy fehlgeschlagen sind.

TLS-RPT spielt für MTA-STS eine ähnliche Rolle wie DMARC-Reporting für die E-Mail-Authentifizierung: Es liefert die Datenbasis, um Probleme zu erkennen, bevor sie den E-Mail-Verkehr beeinträchtigen. Ohne TLS-RPT fliegen Sie im Blindflug — Zertifikatsfehler oder fehlkonfigurierte MX-Server bleiben unbemerkt, bis sich Absender über unzustellbare E-Mails beschweren.

MTA-STS vs. DANE: wann welches Verfahren?

Beide Verfahren verfolgen dasselbe Ziel — die Absicherung der SMTP-Transportverschlüsselung gegen Downgrade-Angriffe — nutzen aber unterschiedliche Vertrauensanker. DANE bietet durch die Verankerung in DNSSEC ein stärkeres kryptografisches Fundament und funktioniert ohne Abhängigkeit von Zertifizierungsstellen. MTA-STS ist einfacher zu implementieren und funktioniert auch ohne DNSSEC, setzt aber auf das klassische CA-Vertrauensmodell.

In der Praxis unterstützen die großen Mailprovider — Gmail, Microsoft, Yahoo — MTA-STS aktiv und werten die Policy bei der Zustellung aus. DANE-Unterstützung auf der sendenden Seite ist bei diesen Anbietern weniger verbreitet. Für Domains mit aktivem DNSSEC empfiehlt sich die parallele Implementierung beider Verfahren, um die größtmögliche Abdeckung zu erreichen.

Deployment in der Praxis

Die Einrichtung von MTA-STS erfordert drei Schritte. Zunächst wird eine Subdomain mta-sts.example.de angelegt, die auf einen Webserver mit gültigem TLS-Zertifikat zeigt. Dort wird die Policy-Datei unter /.well-known/mta-sts.txt bereitgestellt. Im zweiten Schritt wird der DNS-TXT-Record _mta-sts.example.de mit der Versions-ID veröffentlicht. Im dritten Schritt wird optional der TLS-RPT-Record unter _smtp._tls.example.de konfiguriert, um Berichte zu empfangen.

Unser MTA-STS-Check analysiert alle drei Komponenten: Er prüft den DNS-TXT-Record, ruft die Policy-Datei ab, validiert die MX-Hostnamen gegen die tatsächlichen MX-Records und prüft, ob TLS-RPT konfiguriert ist. Ergänzend empfiehlt sich der E-Mail Security Check, um sicherzustellen, dass neben der Transportverschlüsselung auch SPF, DKIM und DMARC korrekt konfiguriert sind. Der SMTP-TLS-Check zeigt darüber hinaus, ob Ihre Domain auch DANE/TLSA implementiert hat — für maximale Transportabsicherung sollten beide Verfahren parallel eingesetzt werden.