TLS-RPT: der Bericht über den verschlüsselten Transport

Von Thomas · virtueller CISO · 2026-08-01

Eine MTA-STS-Richtlinie zu veröffentlichen, die die Verschlüsselung des SMTP-Transports fordert, ist eine Sache; zu wissen, ob diese Richtlinie für die eingehenden Absender tatsächlich funktioniert, eine andere. Ohne Sichtbarkeit gleicht das Verschärfen von MTA-STS dem Veröffentlichen von p=reject in DMARC, ohne je einen einzigen Aggregatbericht gelesen zu haben — eine Wette auf Daten, die gar nicht vorliegen. TLS-RPT (SMTP TLS Reporting, RFC 8460) füllt genau diese Lücke: Es liefert tägliche Berichte über die Erfolge und Ausfälle der TLS-Verbindungen, beobachtet von denen, die Post an die Domain senden. Dieser Leitfaden erklärt, was diese Berichte enthalten, wie man sie konfiguriert, und wie man sie liest.

Wem MTA-STS noch nicht vertraut ist, beginnt mit was MTA-STS ist und wozu es dient — TLS-RPT ist dessen untrennbare Ergänzung, kein unabhängiges Protokoll, das man isoliert verstehen müsste.

Was TLS-RPT meldet

Jeden Tag generieren die großen Mail-Provider, die Post an die Domain senden und TLS-RPT beachten, einen JSON-Bericht, der ihre verschlüsselten Verbindungsversuche zu deren Servern zusammenfasst. Dieser Bericht unterscheidet zwei Kategorien:

Die Erfolge — Verbindungen, bei denen sich TLS normal aufgebaut hat, aggregiert nach Volumen.
Die Ausfälle, klassifiziert nach genauem Typ: abgelaufenes Zertifikat, Zertifikat, das nicht zum Domainnamen passt, gescheiterte TLS-Aushandlung, MTA-STS-Richtlinie nicht auffindbar oder ungültig, und mehrere weitere von der RFC normierte Fehlercodes.

Diese Granularität ist das, was TLS-RPT über ein einfaches „es geht / es geht nicht" hinaus nützlich macht: Sichtbar wird, warum eine Verbindung gescheitert ist, was direkt die Korrektur lenkt. Ein abgelaufenes Zertifikat behebt man nicht auf dieselbe Weise wie eine schlecht formulierte MTA-STS-Richtlinie.

TLS-RPT konfigurieren

Die Konfiguration ist ein einfacher DNS-TXT-Eintrag, veröffentlicht auf _smtp._tls.beispiel.de:

v=TLSRPTv1; rua=mailto:tlsrpt@beispiel.de

Das rua-Tag funktioniert genau wie sein DMARC-Namensvetter — es gibt an, wohin die Berichte zu senden sind, im Format mailto: (eine https:-URI ist ebenfalls möglich für Organisationen, die die Berichte lieber über eine API als per E-Mail erhalten, was eine direkte Integration in eine automatisierte Verarbeitungspipeline erleichtert). Wie bei DMARC lassen sich mehrere durch Komma getrennte Empfänger angeben.

Ein praktischer Unterschied zu DMARC: TLS-RPT hat kein Äquivalent zur externen Autorisierungsfalle (_report._dmarc). Die Berichte lassen sich an jede beliebige Adresse leiten, ohne zusätzliche Konfiguration auf Empfängerseite — eine willkommene Entlastung, wenn beide Protokolle parallel ausgerollt werden.

Ein bewusster Formatunterschied

Die Wahl von JSON statt XML ist nicht nebensächlich. Die DMARC-Berichte haben aus historischen Gründen im Zusammenhang mit der Zeit ihrer Konzeption XML geerbt; TLS-RPT, jünger, wählt ein leichteres und mit modernen Werkzeugen einfacher zu parsendes Format. Konkret bedeutet das, dass die Ingest-Skripte für TLS-RPT in der Regel kürzer zu schreiben sind als ihre DMARC-Äquivalente — ein angenehmes Detail für alle, die erwägen, eine eigene Verarbeitungspipeline zu bauen, statt von einem Drittdienst abzuhängen.

Das Format der Berichte

Die TLS-RPT-Berichte sind im JSON-Format (anders als das XML der DMARC-Berichte), in der Regel mit gzip komprimiert und per E-Mail als Anhang versandt, oder über die API abrufbar, sofern eine https:-URI gewählt wurde. Jeder Bericht deckt ein Fenster von 24 Stunden ab und gruppiert die Ergebnisse nach „Policy Domain" (der Domain, deren MTA-STS-Richtlinie ausgewertet wurde) und nach Ausfalltyp.

Ein typischer Bericht meldet zum Beispiel: „4.892 erfolgreiche Sessions zu mail.beispiel.de, 3 Sessions mit Ausfall vom Typ certificate-expired, von Gmail, im Zeitraum des 29. Juli." Diese Granularität erlaubt es, ein genaues Problem zu isolieren — hier ein dringend zu erneuerndes Zertifikat — statt aus einer vagen Beschwerde eines Empfängers zu raten.

Warum es vor `enforce` unverzichtbar ist

Der testing-Modus von MTA-STS protokolliert die Ausfälle, ohne die Zustellung zu blockieren — aber diese Protokollierung nützt nur, wenn sie gelesen wird. Ohne TLS-RPT bleibt keinerlei Sichtbarkeit auf das, was dieser Testmodus tatsächlich beobachtet: Eine Richtlinie wird veröffentlicht, dann wird gewartet und gehofft, dass alles gut läuft. Mit TLS-RPT wird konkret sichtbar, Tag für Tag, ob Verbindungen scheitern und warum — genau dieselbe Logik des Beweises vor Verschärfung, die für die DMARC-Sequenz none → quarantine → reject gilt, detailliert in p=reject erreichen, ohne die Mails zu zerstören.

MTA-STS auf enforce zu setzen, ohne mindestens ein paar Wochen saubere TLS-RPT-Berichte gelesen zu haben, heißt blind zu verschärfen: Hat ein legitimer empfangender Server ein temporäres Zertifikatsproblem, verweigert der enforce-Modus die Zustellung der Post an ihn — erkennbar allein an einem stillen Rückgang der Zustellbarkeit, möglicherweise wochenlang, bevor es überhaupt jemand bemerkt.

Einen Bericht lesen: was alarmieren muss

Sobald die Berichte da sind, verdienen einige Signale besondere Aufmerksamkeit:

Eine plötzlich steigende Ausfallrate zu einem bestimmten Empfänger — oft das Zeichen eines Zertifikats- oder Konfigurationsproblems jener Seite, zu beobachten, aber nicht notwendigerweise in der eigenen Verantwortung.
Wiederholte mta-sts-policy-invalid-Ausfälle — diese fallen in die eigene Verantwortung: Die Richtlinie selbst ist schlecht formuliert oder nicht auffindbar und verdient eine sofortige Korrektur.
certificate-expired-Ausfälle auf den eigenen Servern — das dringendste Signal, da es anzeigt, dass die Infrastruktur selbst ein abgelaufenes TLS-Zertifikat hat, was möglicherweise den Empfang legitimer Post blockiert, sobald MTA-STS im enforce ist.
Ein vollständiges Fehlen von Berichten — zuerst gehört die DNS-Syntax geprüft, bevor der Schluss fällt, alles sei in Ordnung; wie bei rua in DMARC kann ein schlecht formulierter Eintrag schlicht das Senden der Berichte verhindern, statt ein Fehlen von Verkehr zu signalisieren. Derselbe Geduldsreflex gilt auch: 48 Stunden vergehen lassen, bevor eine Stille Sorgen bereitet.

Der Zusammenhang mit DANE und den anderen Mechanismen zur Transportsicherung

TLS-RPT ist nicht ausschließlich an MTA-STS gebunden, auch wenn das bei weitem die häufigste Nutzung ist. Die RFC 8460 konzipiert das Protokoll als generischen Reporting-Mechanismus für die Ausfälle der SMTP-Transportsicherung, was auch DANE (DNS-based Authentication of Named Entities) einschließt, einen alternativen Ansatz, der die TLS-Validierung in DNSSEC-Einträgen verankert statt in einer HTTPS-Richtliniendatei. Hat eine Organisation DANE statt (oder zusätzlich zu) MTA-STS ausgerollt, liefert TLS-RPT weiterhin dieselbe Sichtbarkeit auf die Verbindungsausfälle, mit an diesen Mechanismus angepassten Fehlercodes.

In der Praxis bevorzugt die große Mehrheit der Deployments 2026 MTA-STS wegen seiner einfachen Umsetzung — DANE erfordert eine bereits vorhandene und korrekt gewartete DNSSEC-Infrastruktur, eine höhere technische Barriere für viele Organisationen. Aber dass TLS-RPT beide Mechanismen abdeckt, bedeutet, dass die Investition in die Konfiguration der Berichte nicht verloren ist, wenn später migriert oder kombiniert wird.

Die häufigsten Fehlercodes und was sie bedeuten

Um die Berichte in konkrete Handlungen zu verwandeln, hilft es, die wiederkehrenden Fehlercodes der RFC 8460 und ihre jeweilige Bedeutung zu kennen. Vier tauchen im Alltag am häufigsten auf:

certificate-expired — das TLS-Zertifikat des Zielservers ist abgelaufen. Beim eigenen Server ist das ein Notfall; beim Server eines Empfängers bleibt allenfalls eine Information, aber die Korrektur liegt bei ihm.
certificate-host-mismatch — das präsentierte Zertifikat passt nicht zum erwarteten Domainnamen. Oft ein Konfigurationsfehler nach einer Migration oder einem Zertifikatswechsel, bei dem der neue Name nicht aktualisiert wurde.
mta-sts-policy-invalid — die MTA-STS-Richtlinie selbst ist schlecht formuliert oder nicht konform mit der Spezifikation. Das ist ein Signal, das direkt die eigene Verantwortung betrifft und eine sofortige Prüfung der veröffentlichten Richtlinie verlangt.
starttls-not-supported — der Zielserver kündigt STARTTLS nicht an, was jede verschlüsselte Verbindung unmöglich macht. Bei einem legitimen Empfänger deutet das auf einen ernsten Konfigurationsmangel jener Seite hin.

Diese Codes den richtigen Verantwortlichen zuzuordnen — der eigenen Seite oder der Gegenseite — ist der Kern der Arbeit mit TLS-RPT. Ein certificate-expired auf der eigenen Infrastruktur ist in Minuten behandelt; dasselbe auf einem Drittserver lässt sich nur eskalieren. Das Werkzeug liefert das Was und das Warum; das Wer korrigiert ergibt sich aus dem betroffenen Server.

Das Fenster von 24 Stunden und die einzuplanende Verzögerung

Wie bei den DMARC-Aggregatberichten muss man mit einer Verzögerung zwischen dem beobachteten Ereignis und seinem Eintreffen im Postfach rechnen. Ein TLS-RPT-Bericht, der den Tag des 29. Juli abdeckt, trifft in der Regel am 30. oder 31. ein, sobald der sendende Provider das Aggregieren seiner eigenen Beobachtungen über das Fenster abgeschlossen hat. Diese Verzögerung hat eine direkte praktische Konsequenz für den Überwachungstakt während der testing-Phase von MTA-STS: Kein sofortiges Signal nach einer Konfigurationsänderung serverseitig erwarten — eher eine Frist von 48 bis 72 Stunden einplanen, bevor sich die tatsächliche Wirkung einer Korrektur auf die beobachtete Ausfallrate beurteilen lässt.

Werkzeuge: JSON von Hand zu lesen ist nicht tragfähig

Wie bei den DMARC-Berichten ist das manuelle Lesen dutzender täglicher komprimierter JSON-Dateien nur für eine ganz kleine Domain realistisch. Sobald das Volumen wächst, wird ein Aggregationswerkzeug, das diese Berichte in ein lesbares Dashboard verwandelt, notwendig — dieselbe Art Plattform, die bereits die DMARC-Aggregatberichte verarbeitet, bietet oft eine TLS-RPT-Unterstützung parallel an, da beide Ströme dieselbe Logik der Sammlung und Visualisierung teilen. Beide in einem einzigen Werkzeug zu bündeln, vermeidet, die separat zu überwachenden Dashboards zu vervielfachen, und erleichtert die Korrelation zwischen einem Authentifizierungsvorfall und einem Transportvorfall, die im selben Zeitraum auftreten.

Zusammengefasst

TLS-RPT ist für MTA-STS, was die Aggregatberichte für DMARC sind: die Beweisschleife, die eine blind veröffentlichte Richtlinie in eine auf realen Daten fundierte Verschärfung verwandelt. Es zu konfigurieren ist ein DNS-Eintrag mehr, ohne externe Autorisierungsfalle zu verwalten, und das regelmäßige Lesen seiner Berichte ist es, was ein umsichtiges MTA-STS-Deployment von einer riskanten Wette auf die Zustellbarkeit unterscheidet.

Um den Zustand der grundlegenden E-Mail-Authentifizierung zu prüfen — das Fundament, auf das MTA-STS und TLS-RPT aufsetzen — läuft die Domain durch den kostenlosen DMARC-Analyzer. Das ist der Schritt, der vorrangig zu behandeln ist; der verschlüsselte Transport kommt danach, um eine bereits solide Identität zu ergänzen, nicht sie zu ersetzen, und in dieser Reihenfolge bringen die beiden Protokolle den meisten Wert.

DMARC anwenden — konkret

Thomas, der virtuelle CISO von DMARC.com, identifiziert jede legitime Versandquelle, schreibt die exakten DNS-Einträge und bringt eine Domain sicher von p=none zu p=reject — ohne den Mailverkehr zu stören.

Zu p=reject — kostenlos