TLS-RPT-Bericht auswerten: JSON-Report lesen und TLS-Fehler beheben
TLS-RPT ist eingerichtet, der DNS-Eintrag steht und seit ein paar Tagen treffen morgens JSON-Dateien in Ihrem Postfach ein. Die Berichte sind da, doch was steht eigentlich drin und welche Konsequenz hat ein Eintrag wie starttls-not-supported? Genau an dieser Stelle endet die reine Einrichtung und die eigentliche Arbeit beginnt: das Lesen und Auswerten der Berichte.
Diese Anleitung erklärt Schritt für Schritt, wie ein TLS-RPT-Bericht aufgebaut ist, was die wichtigsten result-types bedeuten und wie Sie jeden TLS-Fehler gezielt beheben. Wer die Einrichtung selbst noch vor sich hat, findet die Grundlagen auf der Seite zu TLS-RPT. Dieser Artikel setzt dort an, wo die Berichte bereits fließen.
Was ist TLS-RPT und warum die Auswertung zählt?
TL;DR: TLS-RPT, das SMTP TLS Reporting nach RFC 8460, liefert Ihnen täglich einen JSON-Bericht darüber, wie die Transportverschlüsselung Ihrer eingehenden E-Mails verlaufen ist. Der Bericht nennt pro sendendem Anbieter die Zahl erfolgreicher und fehlgeschlagener TLS-Verbindungen und macht über den result-type sichtbar, woran ein Fehlschlag lag. Wer diese Berichte liest, erkennt Zustellprobleme, bevor sie zu verlorenen E-Mails werden, und kann MTA-STS und DANE sicher auf den Modus enforce umstellen.
TLS-RPT ist die Rückmeldeschicht für erzwungene Transportverschlüsselung. MTA-STS und DANE schreiben vor, dass an Ihre Domäne nur verschlüsselt zugestellt werden darf. Sie sagen aber nichts darüber, ob das auch jedem Partner gelingt. TLS-RPT füllt diese Lücke: Sendende Anbieter wie Microsoft, Google oder andere Mailbetreiber fassen einmal pro Tag zusammen, wie viele Verbindungen zu Ihren Mailservern erfolgreich verschlüsselt wurden und welche scheiterten. Erst diese Sichtbarkeit verwandelt eine theoretische Richtlinie in einen beherrschbaren Betrieb.
Der Aufbau eines TLS-RPT-Berichts
Ein TLS-RPT-Bericht ist eine JSON-Datei, oft komprimiert als .json.gz an eine E-Mail angehängt. Unabhängig vom Absender folgt jeder Bericht demselben Grundgerüst aus drei Ebenen.
Kopfdaten und Berichtszeitraum
Am Anfang steht, wer den Bericht erstellt hat und für welchen Zeitraum. Felder wie organization-name, date-range mit Start- und Endzeit sowie contact-info und eine eindeutige report-id ordnen den Bericht ein. Der Zeitraum umfasst in der Regel 24 Stunden.
Die Richtlinie: policy
Unter policies steht für jede ausgewertete Richtlinie ein Block. Das Feld policy-type zeigt, ob es sich um eine sts-Richtlinie (MTA-STS), eine tlsa-Richtlinie (DANE) oder no-policy-found handelt. Dazu kommen der betroffene policy-domain, also Ihre Domäne, und der geprüfte MX-Hostname.
Die Zusammenfassung und die Fehlerdetails
Der eigentliche Kern ist das Feld summary. Es enthält total-successful-session-count und total-failure-session-count, also die Zahl der gelungenen und der gescheiterten TLS-Sitzungen im Berichtszeitraum. Stehen dort nur Erfolge, ist alles in Ordnung. Sobald total-failure-session-count größer als null ist, lohnt der Blick in failure-details. Dieser Abschnitt listet pro Fehlertyp den result-type, die sending-mta-ip, die receiving-ip, den receiving-mx-hostname und einen failed-session-count. Genau hier liegt die diagnostische Information, die Sie zum Handeln brauchen.
Die häufigsten result-types und ihre Behebung
Der result-type ist das wichtigste Feld bei der Fehlersuche. Er benennt präzise, an welcher Stelle die verschlüsselte Zustellung gescheitert ist. Die folgende Tabelle ordnet die in der Praxis häufigsten Werte ihrer Ursache und der passenden Maßnahme zu.
| result-type | Was passiert ist | Maßnahme |
|---|
| starttls-not-supported | Der Zielserver hat kein STARTTLS angeboten, die Verbindung blieb unverschlüsselt | MX-Eintrag, vorgeschaltetes Gateway und STARTTLS-Konfiguration des Empfängers prüfen |
| certificate-expired | Das TLS-Zertifikat des Zielservers ist abgelaufen | Empfänger informieren, Zertifikat erneuern lassen, danach Berichte erneut prüfen |
| certificate-host-mismatch | Das Zertifikat ist gültig, der Name passt aber nicht zum erwarteten MX-Hostnamen | Korrektes Zertifikat mit passendem MX-Namen oder korrigierte MX-Konfiguration |
| tlsa-invalid | Der DANE-Fingerabdruck im DNS passt nicht zum vorgelegten Zertifikat | TLSA-Eintrag nach jedem Zertifikatswechsel aktualisieren, Rollover-Eintrag pflegen |
| dnssec-invalid | Die DNSSEC-Signatur der DANE-Records ließ sich nicht validieren | DNSSEC-Kette der Domäne und der Zone prüfen, abgelaufene Signaturen erneuern |
| validation-failure | Allgemeiner Fehler bei der TLS-Aushandlung, etwa Protokoll oder Cipher | TLS-Version und Cipher-Suiten des Zielservers gegen den aktuellen Stand prüfen |
starttls-not-supported richtig deuten
starttls-not-supported ist der Klassiker und gleichzeitig der Eintrag, bei dem Vorsicht geboten ist. Er kann harmlos sein, etwa weil ein einzelner Backup-MX falsch eingerichtet ist. Er kann aber auch das Symptom einer aktiven Manipulation sein, bei der jemand das STARTTLS-Signal aus der Verbindung entfernt. Tritt der Fehler nur an einer von mehreren empfangenden IPs auf, deutet das auf eine Fehlkonfiguration hin. Tritt er flächendeckend und plötzlich auf, ist eine genauere Untersuchung angebracht.
Zertifikatsfehler liegen meist beim Empfänger
certificate-expired und certificate-host-mismatch betreffen das Zertifikat des Zielservers, also fast immer eine Seite, die Sie nicht selbst kontrollieren. Hier ist die richtige Maßnahme die gezielte Information des betroffenen Partners. Der Bericht liefert Ihnen mit receiving-mx-hostname und failed-session-count genau die Belege, die Sie für eine konkrete Rückmeldung brauchen.
DANE-spezifische Fehler
tlsa-invalid und dnssec-invalid tauchen nur bei aktivem DANE auf. tlsa-invalid ist häufig die Folge eines Zertifikatswechsels, bei dem der TLSA-Eintrag im DNS nicht mitgezogen wurde. Ein gepflegter Rollover-Eintrag verhindert das. dnssec-invalid weist auf ein Problem in der DNSSEC-Kette hin, etwa eine abgelaufene Signatur.
Praxishinweis zu Microsoft 365: nur ein Empfänger
Ein Detail führt in der Praxis regelmäßig zu Verwirrung. Microsoft 365 stellt einen TLS-RPT-Bericht ausschließlich an die erste im rua-Eintrag genannte Adresse zu. Hinterlegen Sie mehrere Reporting-Empfänger durch Komma getrennt, kann es passieren, dass Berichte unvollständig oder gar nicht eintreffen. Die Konsequenz ist klar: Konsolidieren Sie den rua-Eintrag auf genau eine Empfangsadresse, an der alle Berichte zentral zusammenlaufen. So gehen keine Meldungen verloren und die Auswertung bleibt vollständig.
TLS-RPT-Berichte mit Conbool MailGuard auswerten
Berichte von Hand zu lesen, funktioniert für eine Domäne und einen ruhigen Tag. Sobald mehrere Domänen, Dutzende sendender Anbieter und tägliche JSON-Anhänge zusammenkommen, wird die manuelle Auswertung mühsam und fehleranfällig. Conbool MailGuard nimmt Ihnen diese Arbeit ab: Die Berichte laufen an einer Empfangsadresse zusammen, werden entpackt, über alle Anbieter und Tage hinweg aggregiert und nach result-type ausgewertet. Statt einzelne JSON-Dateien zu öffnen, sehen Sie auf einen Blick, welche Partner sauber verschlüsseln und wo ein Fehler wiederholt auftritt.
Diese zusammengeführte Sicht ist die Voraussetzung dafür, MTA-STS und DANE risikoarm vom Modus testing auf enforce umzustellen. Erst wenn die Berichte über mehrere Tage stabil sind, ist die Scharfschaltung sicher. Wer den aktuellen Stand einer Domäne zunächst einordnen möchte, prüft sie mit dem kostenlosen Transportsicherheits-Check.
TLS-RPT, MTA-STS und DANE im Zusammenspiel
TLS-RPT ist kein eigenständiger Schutz, sondern die Beobachtungsschicht über der erzwungenen Verschlüsselung. MTA-STS und DANE setzen die Regel, dass nur verschlüsselt zugestellt werden darf. TLS-RPT meldet zurück, ob diese Regel in der Realität eingehalten wird. Das BSI nennt in der Technischen Richtlinie TR-03108 alle drei Bausteine gemeinsam als Grundlage für sicheren E-Mail-Transport, und die Berichte sind der Teil, der die Wirksamkeit überhaupt nachweisbar macht. Ohne TLS-RPT bleibt enforce ein Sprung ins Ungewisse. Mit TLS-RPT wird daraus ein kontrollierter, belegbarer Schritt.
Häufig gestellte Fragen
Was steht in einem TLS-RPT-Bericht?
Ein TLS-RPT-Bericht ist eine JSON-Datei, die ein sendender Mailbetreiber einmal täglich an Ihre Reporting-Adresse schickt. Sie nennt den Berichtszeitraum, den meldenden Anbieter und für jede Empfänger-Richtlinie eine Zusammenfassung mit der Zahl erfolgreicher und fehlgeschlagener TLS-Verbindungen. Zu jedem Fehlschlag stehen unter failure-details der result-type, die beteiligte Sende- und Empfänger-IP sowie der betroffene MX-Hostname.
Was bedeutet der result-type starttls-not-supported?
starttls-not-supported bedeutet, dass der sendende Server STARTTLS anbieten wollte, der angesprochene Zielserver aber keine TLS-Verschlüsselung angeboten hat. Bei einer MTA-STS- oder DANE-Richtlinie im Modus enforce wird die Zustellung dann abgebrochen statt unverschlüsselt fortgesetzt. Typische Ursachen sind ein falsch konfigurierter MX-Eintrag, ein vorgeschaltetes Gateway ohne TLS oder eine aktive Manipulation, die das STARTTLS-Signal entfernt.
Was bedeuten certificate-expired und certificate-host-mismatch?
certificate-expired heißt, dass das vom Zielserver vorgelegte TLS-Zertifikat abgelaufen ist und die Prüfung deshalb scheitert. certificate-host-mismatch bedeutet, dass das Zertifikat zwar gültig, der darin genannte Name aber nicht der erwartete MX-Hostname ist. Beide Fälle führen unter einer enforce-Richtlinie zum Abbruch. Die Behebung liegt fast immer beim Empfänger: ein erneuertes Zertifikat oder ein Zertifikat mit korrektem MX-Namen.
Warum fehlen bei Microsoft 365 manchmal TLS-RPT-Berichte?
Microsoft 365 stellt einen TLS-RPT-Bericht nur an die erste im rua-Eintrag genannte Reporting-Adresse zu. Sind dort mehrere Empfänger hinterlegt, kann es passieren, dass Berichte ausbleiben oder verteilt eintreffen. Deshalb sollte der rua-Eintrag auf genau eine Empfangsadresse zeigen, an der alle Berichte zusammenlaufen.
Was hat TLS-RPT mit MTA-STS und DANE zu tun?
MTA-STS und DANE erzwingen die verschlüsselte Zustellung, sagen aber von sich aus nichts darüber, ob sie gelingt. TLS-RPT liefert genau diese Rückmeldung. Die Berichte zeigen, welche Partner sauber verschlüsseln und woran Fehlschläge liegen. Erst diese Sichtbarkeit macht den Schritt vom Modus testing auf enforce sicher beherrschbar.
Fazit
Ein TLS-RPT-Bericht ist kein kryptisches Datenformat, sondern eine klar gegliederte Rückmeldung über die Transportverschlüsselung Ihrer E-Mails. Wer Kopfdaten, Richtlinie, Zusammenfassung und vor allem den result-type in den failure-details zu lesen versteht, erkennt Zustellprobleme früh und kann sie gezielt beheben, oft bevor überhaupt eine E-Mail verloren geht. Die größte Hürde ist nicht das einzelne JSON, sondern die laufende, zusammengeführte Auswertung über alle Anbieter und Tage hinweg.
Der nächste Schritt liegt bei Ihnen: Prüfen Sie Ihre Domäne mit dem Transportsicherheits-Check und sehen Sie, wie Conbool MailGuard die TLS-RPT-Berichte empfängt, aggregiert und auswertet.
Weiterführende Artikel:
