MTA-STS, DANE und TLS-RPT: Was zwanzig Domains beim Mailtransport absichern

SMTP überträgt E-Mails zwischen Mailservern; STARTTLS ergänzt die Verbindung um Verschlüsselung. Ohne eine verbindliche Sicherheitsrichtlinie bleibt der Aufbau jedoch häufig opportunistisch: Fehlt das STARTTLS-Angebot in der Antwort auf EHLO, kann die Zustellung unverschlüsselt weitergehen. Ein Angreifer auf dem Übertragungsweg könnte dieses Angebot entfernen. Ob danach tatsächlich Klartext erlaubt ist, hängt von der Konfiguration und weiteren Richtlinien des sendenden Servers ab.

MX-Einträge nennen die Server, die E-Mails für eine Domain empfangen. MTA-STS und DANE schaffen verbindliche Prüfregeln für unterstützende Absender. TLS-RPT liefert Berichte über erfolgreiche und fehlgeschlagene TLS-Sitzungen. Keines dieser Verfahren ersetzt Ende-zu-Ende-Verschlüsselung: Abgesichert wird der Transport zwischen Servern.

Drei Verfahren mit unterschiedlichen Aufgaben

MTA-STS: Ein TXT-Eintrag unter _mta-sts.example.com kündigt eine Richtlinie an. Die Datei https://mta-sts.example.com/.well-known/mta-sts.txt enthält erlaubte MX-Namen, Modus und Geltungsdauer. Bei enforce darf ein unterstützender Absender keine Nachricht an einen MX mit fehlendem TLS, unzulässigem Namen oder ungeeignetem Zertifikat übergeben. Bei testing blockiert allein ein MTA-STS-Verstoß die Zustellung nicht; andere Sicherheitsregeln gelten weiterhin.

DANE: TLSA-Einträge unter dem Namen des Mailservers binden den TLS-Endpunkt an ein Zertifikat, einen Schlüssel oder einen Vertrauensanker. Für SMTP-DANE müssen die maßgeblichen MX- und TLSA-Daten über DNSSEC vertrauenswürdig sein. Dazu gehören eine gültige Vertrauenskette und korrekte Fehlerbehandlung. TLSA erfordert eine eigene DNS-Abfrage; die TTL bestimmt, wie lange eine zwischengespeicherte DNS-Antwort erneut genutzt werden darf. Zusätzlich begrenzt der Ablauf der Signatur die Verwendbarkeit.

TLS-RPT: Ein TXT-Eintrag unter _smtp._tls.example.com benennt Berichtsempfänger. Unterstützende Absender melden zusammengefasste Erfolge und Fehler. Das ergänzt eigene Protokolle und aktive Prüfungen. Aus fehlenden Berichten folgt weder störungsfreier Betrieb noch vollständige Abdeckung aller Absender.

Historische Stichprobe: 20 Domains, 38 Hostprüfungen

Die gespeicherten Rohdaten vom 5. September 2026 umfassen 20 Domains und 38 aufgezeichnete Hostprüfungen. Bei der Überarbeitung am 25. Oktober wurden die Summen aus dieser Datei erneut berechnet. Eine neue Messung der Anbieter fand nicht statt. Die 38 Prüfungen belegen außerdem keine vollständige Erfassung sämtlicher veröffentlichter MX-Server und IP-Adressen.

In dieser Auswahl waren die elf Domains mit TLS-RPT dieselben wie mit MTA-STS-TXT. Daraus folgt keine allgemeine Regel. Ebenso belegt ein AD-Kennzeichen in einer TLSA-Antwort noch keine durchgängig geprüfte DNSSEC-Kette der Empfängerdomain. Die damalige Messung erlaubt deshalb keine pauschale DANE-Freigabe.

Was aus den Ergebnissen nicht folgt

Eine MTA-STS-Kennung mit der Zeichenfolge 2018 ist kein Beweis für acht Jahre Testbetrieb. Das Feld id ist eine frei gewählte Änderungskennung, kein vorgeschriebener Zeitstempel. Der Modus muss aus der tatsächlich abgerufenen Richtlinie gelesen werden.

Bei zwei Domains war trotz TXT-Eintrag keine Richtlinie lesbar. Ohne bereits gespeicherte gültige Richtlinie ergibt sich daraus keine durchsetzbare MTA-STS-Regel. Eine noch gültige Cache-Kopie bleibt dagegen maßgeblich. Die Aussage „schlechter als kein Eintrag“ war daher zu pauschal. Auch organisatorische Gründe für die Wahl von MTA-STS oder DANE lassen sich aus dieser kleinen Auswahl nicht ableiten.

Im historischen Datensatz bestand für wp.pl eine enforce-Richtlinie mit *.wp.pl. Beim geprüften Host mx5.wp.pl meldete das Werkzeug eine fehlgeschlagene Zertifikatsvalidierung bei passendem Hostnamen. Eine vollständige Zertifikatskette fehlt im Datensatz; „selbstsigniert“ ist damit nicht belegt. Ebenso wenig beschreibt dieser Befund den heutigen Zustand. Ein unterstützender Absender müsste einen tatsächlich nicht richtlinienkonformen MX auslassen und gegebenenfalls andere MX versuchen oder die Zustellung später wiederholen.

Bei gmx.net, web.de und t-online.de endete die Prüfung schon mit einer SMTP-Ablehnung. Damit blieb STARTTLS ungetestet. Nur die gespeicherte Antwort von t-online.de nennt ausdrücklich die Reputation; ein fehlender PTR-Eintrag ist damit nicht für alle drei Fälle bewiesen. „Verbindung abgelehnt“ und „STARTTLS fehlt“ sind unterschiedliche Befunde.

DNS, Richtlinie und Zertifikat getrennt prüfen

Die folgenden Linux-Beispiele verwenden Platzhalter. Für eine konkrete Prüfung müssen Domain und MX-Hostname aus der tatsächlichen Konfiguration stammen. Die Befehle versenden keine Nachricht.

dig +short MX example.com
dig +short TXT _mta-sts.example.com
dig +short TXT _smtp._tls.example.com
dig +dnssec TLSA _25._tcp.mx.example.com
curl --fail --show-error --silent --max-time 15 --include \
  https://mta-sts.example.com/.well-known/mta-sts.txt
timeout 20s openssl s_client -starttls smtp \
  -connect mx.example.com:25 -servername mx.example.com \
  -verify_hostname mx.example.com -verify_return_error </dev/null

curl ruft hier den Inhalt per GET ab; -I würde nur Header anfordern. Für eine verwertbare Richtlinie müssen auch HTTP-Status, Inhalt und HTTPS-Zertifikat passen. openssl prüft ausdrücklich den Hostnamen und bricht bei Zertifikatsfehlern ab. -servername allein setzt lediglich SNI. Diese Verbindung prüft öffentliches Zertifikatsvertrauen gemäß der lokalen Vertrauensdatenbank, keine vollständige DANE-Validierung.

dig +dnssec fordert DNSSEC-Daten an, validiert aber nicht selbst die gesamte Kette. Ein AD-Flag ist nur mit vertrauenswürdigem Resolver und geschütztem Weg zu diesem Resolver belastbar. Ein bloßer TLSA-Hashvergleich reicht ebenfalls nicht: Verwendungsart, Selektor, Hashverfahren und DNSSEC-Status gehören zur Auswertung.

Der Mailtransport-Sicherheitsprüfer liefert eine erste Bestandsaufnahme. Die bei der Überarbeitung geprüfte Implementierung untersucht standardmäßig höchstens drei MX-Hosts und jeweils die erste ermittelte IP-Adresse. Der TLSA-Vergleich deckt nicht alle zulässigen Kombinationen vollständig ab; das AD-Flag stammt aus einer ungeschützten DNS-Abfrage. Das Ergebnis ersetzt deshalb weder einen vollständigen DANE-Test noch die Prüfung aller Zustellwege.