TLS-Report-Decoder — TLSRPT-Aggregate-Reports in klarem Deutsch lesen
Fügen Sie einen TLSRPT-JSON-Aggregate-Report ein — die tägliche Datei, die Gmail, Outlook und andere große Versender an Ihre rua-Adresse senden, wenn MTA-STS oder DANE auf Ihrer Inbound-Domain konfiguriert ist. Der Decoder parst den Policy-Bereich, zählt erfolgreiche versus fehlgeschlagene Sessions, schlüsselt Fehler nach Result-Type auf (Zertifikat abgelaufen, STARTTLS nicht unterstützt, STS-Policy-Fetch-Fehler und der Rest des RFC-8460-Katalogs), identifiziert die sendenden MTAs, die die Fehler hatten, und rendert das Ganze als lesbare Tabelle statt als Bildschirm voll roher JSON. Kein Upload; das Parsing geschieht vollständig in Ihrem Browser.
Einen TLSRPT-JSON-Report einfügen
Kopieren Sie das JSON aus einem beliebigen erhaltenen Report — Gmail, Microsoft, Yahoo oder jeder RFC-8460-Versender. Der Parser läuft in Ihrem Browser; nichts verlässt Ihren Rechner.
100% clientseitig · Nichts wird hochgeladen · Kompatibel mit RFC-8460-Reports von Gmail, Outlook, Yahoo und selbst gehosteten MTAs
TLSRPT ist der tägliche Aggregate-Reporting-Mechanismus für SMTP TLS — die Rückkopplungsschleife, die Ihnen sagt, wann Versender Ihre Domain nicht über verschlüsselte Kanäle erreichen können
RFC 8460 — SMTP TLS Reporting, veröffentlicht im September 2018 — definiert ein JSON-Aggregate-Report-Format, mit dem sendende Mailserver Empfänger-Domains über TLS-Verhandlungsfehler informieren. Der Ablauf ist unkompliziert: Sie veröffentlichen einen TXT-Record unter _smtp._tls.ihredomain.de mit v=TLSRPTv1; rua=mailto:tlsrpt@ihredomain.de (oder einem https-Endpoint). Große Versender — Gmail, Microsoft, Yahoo und die meisten modernen MTAs — lesen diesen Record beim Versuch, Mail an Ihre Domain zuzustellen, protokollieren jedes TLS-Ereignis des Tages und senden Ihnen einen Aggregate-JSON-Report, der 00:00-23:59 UTC abdeckt, typisch einige Stunden später. Funktioniert alles, kommen die Reports entweder gar nicht an (der Versender hat keine Fehler gesehen) oder zeigen 100% erfolgreiche Sessions.
Der Report selbst ist strukturiert. Die Top-Level-Felder sind organization-name (der Versender, z.B. „Google Inc."), date-range (start-datetime und end-datetime, beide ISO 8601), contact-info (eine E-Mail beim Versender für Rückfragen), report-id (eine eindeutige Kennung) und policies (ein Array von Policy-Objekten, eines pro Policy, die der Versender gegen Ihre Domain ausgewertet hat). Jedes Policy-Objekt trägt die Policy selbst (Type sts/tlsa/no-policy-found, die policy-string-Zeilen, die policy-domain, die abgedeckten MX-Hosts), eine summary (total-successful-session-count, total-failure-session-count) und ein failure-details-Array mit einem Eintrag pro eindeutigem Fehlertyp — result-type (der RFC-8460-Aufzählungscode), sending-mta-ip (welche MTA des Versenders den Fehler hatte), receiving-mx-hostname (an welchem Ihrer MX-Hosts der Fehler auftrat), failed-session-count (wie viele Sessions diesen spezifischen Fehler hatten), additional-information (frei formulierte URL mit mehr Kontext, oft leer) und failure-reason-code (versenderdefiniertes Detail).
Warum das 2026 zählt: Ein TLS-Fehler bei eingehender Mail bricht die Zustellung standardmäßig nicht — STARTTLS ist opportunistisch, ein Versender, der keine Verschlüsselung aushandeln kann, fällt typischerweise auf Klartext zurück, statt die Sendung zu verweigern. Der Fehler ist von Ihrer Seite unsichtbar; Mail kommt weiter an, und Sie wissen nicht, dass Ihr Zertifikat abgelaufen oder Ihre MTA-STS-Policy unerreichbar ist. TLSRPT ist die einzige Rückkopplungsschleife, die diese Unsichtbarkeit sichtbar macht. Wenn Sie MTA-STS im Enforce-Modus betreiben und Ihr Zertifikat sonntagnachmittags abläuft, ist der TLSRPT-Report montagmorgens das Einzige, was es Ihnen sagt. Wenn der Report kommt, haben Sie schon einen Tag Mail verloren; ohne den Report verlören Sie jeden Tag, bis jemand zufällig die SMTP-Fehler in seiner Ausgangsqueue bemerkt.
Die Reports zählen auch für die Compliance-Haltung 2026. NIS2 und DSGVO betonen beide Transportverschlüsselung als Teil angemessener technischer Maßnahmen; HIPAA verlangt sie ausdrücklich für PHI. Im DACH-Kontext haben BfDI und Datenschutzkonferenz (DSK) in ihren Hinweisen 2024-2025 Transportverschlüsselung als angemessene technische Maßnahme nach Art. 32 DSGVO und §22 BDSG-neu eingeordnet. Eine dokumentierte, TLSRPT-überwachte Konfiguration ist Teil des Nachweises, den ein Sicherheitsauditor bei der Prüfung von E-Mail-Infrastruktur sehen will — besonders bei deutschen Mittelständlern unter B2B-Audit, Schweizer Banken unter dem revidierten DSG und FINMA-Aufsicht oder österreichischen Anbietern unter der DSB. Hinzu kommt die BSI-C5-Registrierungsfrist vom 6. März 2026 — C5 bewertet Transportverschlüsselung als Teil des Sicherheitsprofils, und fehlende TLSRPT-Überwachung ist ein offensichtlicher Mangel im Audit. Der Decoder oben verwandelt das tägliche JSON in etwas, das Sie tatsächlich lesen können — und an den Auditor oder den Bereitschaftsingenieur weiterleiten, der es verstehen muss, ohne den RFC selbst zu parsen.
Jeder RFC-8460-Fehlercode, den der Decoder anzeigen kann, was er bedeutet und was zu tun ist
starttls-not-supported Der Versender versuchte STARTTLS auf der SMTP-Verbindung; Ihre MTA hat keine STARTTLS-Unterstützung im EHLO angekündigt. Entweder ist Ihre MTA fehlkonfiguriert (kein TLS-Zertifikat, TLS-Modul deaktiviert) oder der Versender verband sich zum falschen Host. Behebung: bestätigen, dass STARTTLS auf jedem im MX-Record gelisteten MX aktiviert ist.
certificate-host-mismatch Das TLS-Zertifikat, das Ihre MTA präsentiert hat, enthält nicht den Hostnamen, zu dem sich der Versender verbunden hat (typisch Ihren MX-Hostnamen). Entweder fehlen die Subject Alternative Names des Zertifikats den MX-Hostnamen, oder das falsche Zertifikat ist an den Listener gebunden. Behebung: Zertifikat mit allen MX-Hostnamen neu ausstellen; mit openssl s_client -connect mx.beispiel.de:25 -starttls smtp verifizieren.
certificate-expired Das TLS-Zertifikat ist über sein notAfter-Datum hinaus. Versender mit MTA-STS Enforce werden die Zustellung verweigern; Versender im opportunistischen Modus fallen je nach Policy auf Klartext zurück oder verweigern komplett. Behebung: Zertifikat sofort erneuern, Erneuerung automatisieren (Let's Encrypt + certbot, ACM usw.) und Ablauf-Monitoring einrichten, das 30 Tage vorher warnt.
certificate-not-trusted Das Zertifikat ist für den Hostnamen gültig und nicht abgelaufen, aber von einer Autorität signiert, der der Versender nicht vertraut — typisch ein selbstsigniertes Zertifikat oder eines, das von einer internen CA ausgestellt wurde. Behebung: durch ein Zertifikat einer öffentlich vertrauenswürdigen CA ersetzen (Let's Encrypt ist kostenlos und funktioniert für SMTP).
validation-failure Allgemeiner TLS-Validierungsfehler, nicht durch die spezifischeren Codes oben abgedeckt — Protokollverhandlungsfehler, Cipher-Mismatches, Handshake-Abbrüche. Weniger handlungsleitend aus dem Report allein; bei einer Spitze davon Paketmitschnitte der fehlschlagenden Verbindung erfassen, um zu diagnostizieren.
tlsa-invalid Der DANE-TLSA-Record existiert für Ihren MX-Host, passt aber nicht zum Zertifikat, das Ihre MTA präsentiert hat. DANE-spezifisch; nicht relevant, wenn Sie nur MTA-STS nutzen. Behebung: TLSA-Record nach jeder Zertifikatserneuerung regenerieren (oder ACME-TLSA-Automatisierung nutzen).
dnssec-invalid DNSSEC-Validierung schlug beim DANE-TLSA-Lookup fehl. Entweder sind die DNSSEC-Signaturen Ihrer Zone abgelaufen/ungültig oder der Pfad zwischen Ihnen und Ihrem DNS-Anbieter ist fehlkonfiguriert. Behebung: über dnsviz.net oder ein ähnliches Tool bestätigen, dass DNSSEC-Validierung passt; Zone bei Bedarf neu signieren.
sts-policy-fetch-error Der Versender versuchte, Ihre MTA-STS-Policy unter https://mta-sts.ihredomain.de/.well-known/mta-sts.txt abzurufen, und der Request schlug fehl — HTTP-Fehler, Zertifikatsproblem, DNS-Auflösungsfehler oder Timeout. Behebung: bestätigen, dass die Policy-URL 200 mit korrektem Content-Type liefert; prüfen, dass die mta-sts-Subdomain auflöst; HTTPS-Zertifikat dieses Endpoints validieren.
sts-policy-invalid Die MTA-STS-Policy wurde abgerufen, ist aber fehlerhaft — fehlende Pflichtfelder, ungültiger Mode-Wert oder Syntax, die RFC 8461 verletzt. Behebung: Policy mit einem MTA-STS-Checker validieren; die Policy muss mit version: STSv1 beginnen und gültige mode-Werte (enforce/testing/none), mx-Einträge und max_age enthalten.
sts-webpki-invalid Das HTTPS-Zertifikat für mta-sts.ihredomain.de schlug bei der Validierung fehl (abgelaufen, falscher Hostname, selbstsigniert, untrusted CA). Behebung: regulär ein Web-Zertifikat — von einer öffentlich vertrauenswürdigen CA erneuern oder neu ausstellen. Das Zertifikat der mta-sts-Subdomain ist unabhängig vom Zertifikat Ihres MX-Hostnamens; beide müssen gültig sein.
Einzelne Fehler zählen selten. Muster über Reports hinweg zählen. Hier worauf zu achten ist
Plötzliche Spitze von certificate-expired oder certificate-not-trusted
Weist fast immer auf eine Erneuerung hin, die nicht richtig propagiert wurde — das neue Zertifikat wurde ausgestellt, aber die MTA nicht neu geladen, oder das Zertifikat wurde auf einem Cluster-Knoten ausgerollt, aber nicht auf den anderen. Plötzliches Auftreten, klare Ursache; betroffenen Dienst neu starten und am Folgetag im Report sehen, wie die Zählung auf null fällt.
Anhaltender sts-policy-fetch-error
Die mta-sts-Subdomain hat ein Problem — entweder löst sie nicht auf, der HTTPS-Endpoint ist down oder die Policy-Datei fehlt. Anhaltend, weil jeder Versender die Policy bei seinem eigenen Cache-Ablauf neu abruft, sodass ein Problem an einem Tag in den Reports des Folgetages über mehrere Versender hinweg auftaucht. Endpoint beheben; die Fehler klären sich über mehrere Tage, während die Caches der Versender frisch werden.
Einzelne MTA-IP zeigt Fehler, während andere sauber sind
Einer Ihrer MX-Hosts hat eine andere Konfiguration als die anderen. Meist ein veralteter Knoten in einem Cluster — ein Server, der das Zertifikatsupdate nicht erhielt, eine Replika mit älterer Postfix-Version, ein Backup-MX mit anderer Policy-Datei. Das Feld receiving-mx-hostname in den Failure-Details anschauen, um den spezifischen Host zu identifizieren.
starttls-not-supported von einem großen Versender nach Monaten sauberer Reports
Fast immer ein Zeichen für eine kürzliche operative Änderung — Postfix-Upgrade, OS-Patch, Cipher-Policy-Änderung, die TLS-Verhandlung gebrochen hat, Firewall-Regel, die den verschlüsselten Handshake zu droppen begann. Die großen Versender haben sich nicht geändert; Sie schon. Die Deployments der 24 Stunden vor Beginn der Fehler ansehen.
Leere Reports — durchgängig null Fehler
Der gewünschte Zustand. Der TLSRPT-Record funktioniert (Sie erhalten Reports), TLS verhandelt erfolgreich (keine Failure-Details) und Sie haben Sichtbarkeit auf den Kanal. Reports weiter laufen lassen; der Tag, an dem nicht-leere Reports kommen, ist der Tag, an dem ein handlungsleitendes Signal vorliegt.
Einen Report lesen tut dieses Tool. Jeden Report jeden Tag lesen, bei Regressionen alarmieren und Fehler zur Ursache triagieren tut der gemanagte Workflow
Ein TLSRPT-Report pro Woche sehen die meisten Inbound-Domains, wenn die Konfiguration gesund ist. Multipliziert mit jedem Versender, multipliziert mit jeder Domain, die Sie betreiben, skaliert die Parsing-Arbeit über das hinaus, was eine Person manuell aufrechterhalten kann. Unser gemanagter Deliverability-Workflow umfasst automatisierten TLSRPT-Ingest, täglichen Diff gegen den vorherigen Report zum Erkennen von Regressionen, Alarme bei spezifischen Result-Types (certificate-expired und sts-policy-fetch-error pagen immer; andere hängen vom Volumen ab) und die Remediation-Arbeit — Koordination von Zertifikatserneuerungen, Reparatur des MTA-STS-Policy-Hostings, Debugging des fehlschlagenden receiving-mx-hostname — die einen Report in eine Behebung verwandelt.
Der Decoder oben gibt Ihnen die One-Shot-Sicht auf einen Report. Wenn Sie Fehler sehen und verstehen wollen, ob es Rauschen oder eine echte Regression ist, ist das nächste Gespräch, den Report im Kontext der vorherigen Woche zu lesen — und dieses Gespräch läuft schneller mit jemandem, der den Diff schon gemacht und die Änderung identifiziert hat.
Was Teams beim ersten Lesen eines TLSRPT-Reports fragen
Mein Report kommt gzip-komprimiert — wie dekomprimiere ich ihn?
+
RFC 8460 spezifiziert application/tlsrpt+gzip für das typische komprimierte Format. Auf der Kommandozeile: gunzip report.json.gz. Unter macOS oder Windows entpackt ein Doppelklick auf den Anhang die Datei. Nach dem Entpacken fügen Sie das resultierende JSON in den Decoder oben ein. Der Dateiname folgt meist dem Muster versender.beispiel!ihredomain.de!1234567890!1234567891.json.gz — die beiden Zahlen sind Unix-Timestamps von Anfang und Ende des Report-Fensters.
Ich erhalte keine TLSRPT-Reports. Ist das gut oder schlecht?
+
Hängt davon ab, ob Sie den TXT-Record veröffentlichen. Wenn _smtp._tls.ihredomain.de auflöst und einen gültigen TLSRPTv1-Record zurückgibt, bedeutet null Reports null Fehler — der gewünschte Zustand. Fehlt oder ist der TXT-Record fehlerhaft, erhalten Sie null Reports, weil kein Versender weiß, wohin er sie schicken soll — der schlimmste Zustand, weil Sie weder Sichtbarkeit noch Bestätigung haben. Lassen Sie einen MTA-STS-/TLSRPT-Checker gegen Ihre Domain laufen, um zu bestätigen, dass der Record auflöst; tut er das und kommen nach 48 Stunden trotzdem keine Reports, senden Sie sich Testmail von einem Gmail-Account und prüfen den Inbound-Spool — kommt Mail an, aber kein TLSRPT, ist Ihr rua-Endpoint das Problem.
Sollte ich MTA-STS im Enforce- oder Testing-Modus betreiben?
+
Im Testing-Modus starten, 2-4 Wochen TLSRPT-Reports beobachten, um null Fehler von großen Versendern zu bestätigen, dann auf Enforce wechseln. Das Risiko, direkt auf Enforce zu gehen: jede Fehlkonfiguration — falscher MX in der Policy-Datei, Zertifikatsproblem, unerreichbare mta-sts-Subdomain — führt dazu, dass legitime Versender Mail an Ihre Domain ablehnen. Der Testing-Modus gibt Sichtbarkeit ohne Ablehnungsfolge. Sind die Reports konstant sauber, auf Enforce umstellen; der zusätzliche Schutz gegen Downgrade-Angriffe und Zertifikatsvalidierungs-Bypässe ist die operative Disziplin wert, TLSRPT danach zu überwachen.
Warum erhalte ich keine failure-details für jede fehlgeschlagene Session?
+
TLSRPT ist per Design aggregiert — jeder failure-details-Eintrag fasst mehrere Sessions zusammen, die denselben result-type, sending-mta-ip und receiving-mx-hostname teilen, mit der Anzahl in failed-session-count. Versender sind nicht verpflichtet, Session-Details einzeln zu melden, um Report-Größe zu begrenzen und Privatsphäre zu schützen. Brauchen Sie Session-Detail, korrelieren Sie den Report mit Ihren eigenen MTA-Logs: das date-range-Feld nennt das Fenster, das receiving-mx-hostname-Feld nennt den zu prüfenden MX-Server.
Können Versender gefälschte TLSRPT-Reports an meinen rua-Endpoint schicken?
+
Ja — TLSRPT hat keine eingebaute Delegationsverifikation wie die Reporting-Domain-Autorisierung von DMARC. RFC 8460 spezifiziert, dass per SMTP gesendete Reports von der Reporting-Domain DKIM-signiert sein müssen, sodass Sie die Signatur validieren können, um zu bestätigen, dass der Report vom angegebenen Versender stammt. Per HTTPS POST gesendete Reports werden nur durch das Endpoint-Zertifikat authentifiziert. Behandeln Sie Report-Inhalte als untrusted Input — kein JSON evaluieren, keine Werte ungesäubert an Shell oder SQL weitergeben, Endpoint rate-limiten, um DoS zu verhindern. Der Decoder oben läuft vollständig im Browser; selbst böswillig gestaltetes JSON kann nichts außerhalb des Tabs beeinflussen.
Ist TLSRPT dasselbe wie DMARC-RUA-Reports?
+
Nein — verschiedene Protokolle, verschiedene Schichten. DMARC-RUA-Reports decken Authentifizierungsergebnisse ab (SPF- und DKIM-Resultate, Alignment mit der From-Domain) und werden als XML versendet. TLSRPT-Reports decken Transportverschlüsselungsergebnisse ab (TLS-Verhandlung erfolgreich oder fehlgeschlagen) und werden als JSON versendet. Typisch wollen Sie beide: DMARC sagt, wer als Ihre Domain signiert und ob das Alignment passt; TLSRPT sagt, ob die Versender Sie über einen verschlüsselten Kanal erreichen. Die beiden Reports ergänzen sich, und die meisten Versender, die einen ausstellen, stellen auch den anderen aus.