Warum sollten Sie Ihre TLS-RPT-Berichte analysieren?
Google, Microsoft und Yahoo senden täglich TLS-RPT-Berichte an jede Domain mit einem TLS-RPT-Eintrag. Diese Berichte dokumentieren jede TLS-Verbindung zu Ihren MX-Servern - Erfolge wie Fehlschläge.
Das Problem: TLS-RPT-Berichte sind JSON-Dateien, oft gzip-komprimiert. Ohne spezialisiertes Tool bleiben TLS-Fehler unentdeckt.
Drei Gründe für die regelmäßige Analyse:
- Abgelaufene Zertifikate erkennen - ein abgelaufenes Zertifikat auf einem MX-Server deaktiviert die TLS-Verschlüsselung und legt E-Mails offen
- MTA-STS-Richtlinie validieren - Absender melden Fetch-Fehler und ungültige Richtlinien direkt im Bericht
- TLS-Gesamtzustand überwachen - eine steigende Fehlerrate signalisiert Konfigurationsprobleme, bevor Zustellfehler auftreten
Laden Sie jetzt einen Bericht hoch und erhalten Sie in 10 Sekunden eine vollständige Diagnose.
Wie Sie einen TLS-RPT-Bericht in 3 Schritten analysieren
Schritt 1: Bericht abrufen
Öffnen Sie die TLS-RPT-E-Mail von Google (noreply-smtp-tls-reporting@google.com), Microsoft oder Yahoo. Laden Sie den .json.gz- oder .json-Anhang herunter.
Schritt 2: Datei hochladen
Ziehen Sie die Datei per Drag-and-Drop in den Upload-Bereich oben oder klicken Sie auf "Durchsuchen". Akzeptierte Formate: .json und .json.gz, maximal 10 MB.
Schritt 3: Diagnose lesen
CaptainDNS dekomprimiert die Datei automatisch, parst das JSON und liefert:
- Gesundheitsscore von 100 mit 4 Stufen: ausgezeichnet, gut, Achtung, kritisch
- Aufschlüsselung nach Richtlinie (MTA-STS, DANE) mit Erfolgsrate pro Policy
- Erklärte Fehler mit Schweregrad, Ursache und konkreter Empfehlung
- Direktlink zum passenden CaptainDNS-Tool zur sofortigen Behebung
Starten Sie jetzt die Analyse mit Ihrem letzten TLS-RPT-Bericht.
Aufbau eines TLS-RPT-Berichts (RFC 8460)
RFC 8460 definiert das JSON-Schema für TLS-RPT-Berichte. Jeder Bericht enthält drei Hauptelemente:
- organization-name - der Absender des Berichts (z. B. "Google Inc.")
- date-range - der abgedeckte Zeitraum, standardmäßig 24 Stunden
- policies - eine oder mehrere ausgewertete Richtlinien (MTA-STS und/oder DANE)
Jede Richtlinie enthält folgende Felder:
| Feld | Beschreibung |
|---|---|
policy-type | Richtlinientyp: sts, tlsa oder no-policy-found |
policy-domain | Die betroffene Domain |
total-successful-session-count | Anzahl erfolgreicher TLS-Verbindungen |
total-failure-session-count | Anzahl fehlgeschlagener TLS-Verbindungen |
failure-details | Fehlertyp, Anzahl und betroffene MX-Server |
Prüfen Sie mit dem TLS-RPT-Prüfer, ob Ihre Domain korrekt konfiguriert ist.
Die 12 analysierten TLS-Fehlertypen gemäß RFC 8460
CaptainDNS erkennt und erklärt alle Fehlercodes, die RFC 8460 definiert. Jeder Fehler erhält einen Schweregrad und eine konkrete Handlungsempfehlung.
STARTTLS-Fehler
| Code | Schweregrad | Ursache | Maßnahme |
|---|---|---|---|
starttls-not-supported | Kritisch | Der MX-Server bietet kein STARTTLS an | STARTTLS in der MX-Serverkonfiguration aktivieren |
Ohne STARTTLS erfolgt die E-Mail-Übertragung unverschlüsselt. Dieser Fehler erfordert sofortiges Handeln.
Zertifikatsfehler
| Code | Schweregrad | Ursache | Maßnahme |
|---|---|---|---|
certificate-expired | Hoch | TLS-Zertifikat abgelaufen | Mit Let's Encrypt oder Ihrer CA erneuern |
certificate-host-mismatch | Hoch | CN/SAN stimmt nicht mit dem MX-Hostnamen überein | Zertifikat mit dem korrekten Hostnamen ausstellen |
certificate-not-trusted | Hoch | Selbstsigniert oder unbekannte CA | Zertifikat einer öffentlich anerkannten CA verwenden |
Erneuern oder ersetzen Sie betroffene MX-Zertifikate umgehend.
MTA-STS-Fehler
| Code | Schweregrad | Ursache | Maßnahme |
|---|---|---|---|
sts-policy-fetch-error | Hoch | MTA-STS-Richtlinie nicht erreichbar | https://mta-sts.domain/.well-known/mta-sts.txt prüfen |
sts-policy-invalid | Hoch | Richtlinieninhalt ungültig | Mit dem MTA-STS Syntax Checker validieren |
sts-webpki-invalid | Hoch | HTTPS-Zertifikat von mta-sts.domain ungültig | Zertifikat erneuern oder MTA-STS-Hosting nutzen |
MTA-STS-Fehler treten häufig bei selbst gehostetem MTA-STS auf. Das MTA-STS-Hosting von CaptainDNS eliminiert diese Fehlerquelle.
DANE-Fehler
| Code | Schweregrad | Ursache | Maßnahme |
|---|---|---|---|
tlsa-invalid | Hoch | TLSA-Eintrag veraltet oder fehlerhaft | Mit dem DANE/TLSA Checker aktualisieren |
dnssec-invalid | Kritisch | Fehlerhafte DNSSEC-Signaturkette | Mit dem DNSSEC Checker prüfen |
dane-required | Hoch | DANE erforderlich, aber nicht verfügbar | Gültige TLSA-Einträge mit dem DANE/TLSA-Generator veröffentlichen |
DANE-Fehler mit dnssec-invalid sind kritisch: Sie unterbrechen die gesamte DANE-Validierung der Domain.
Konkrete Anwendungsfälle
Fall 1: Abgelaufenes Zertifikat auf einem sekundären MX
Symptom: Der Google-Bericht zeigt 200 Fehler certificate-expired für mail2.beispiel.com.
Diagnose: Das Let's-Encrypt-Zertifikat des sekundären MX wurde nicht erneuert. Ursache: defekter Certbot-Cronjob.
Maßnahme: Zertifikat sofort erneuern und automatische Erneuerung prüfen.
Fall 2: MTA-STS-Richtlinie nicht erreichbar
Symptom: Microsoft meldet sts-policy-fetch-error mit HTTP 503.
Diagnose: Der Server für https://mta-sts.beispiel.com/.well-known/mta-sts.txt ist ausgefallen.
Maßnahme: Server wiederherstellen oder auf MTA-STS-Hosting von CaptainDNS umstellen. Das gehostete MTA-STS bietet automatische Hochverfügbarkeit.
Fall 3: Keine TLS-Richtlinie konfiguriert
Symptom: Der Bericht zeigt no-policy-found für eine Subdomain.
Diagnose: Weder MTA-STS noch DANE sind für diese Subdomain konfiguriert.
Maßnahme: Konfigurieren Sie MTA-STS mit dem MTA-STS-Generator oder DANE mit dem DANE/TLSA-Generator.
Laden Sie den betroffenen Bericht in den Analysator hoch, um alle Fehler im Detail einzusehen.
FAQ
F: Was ist ein TLS-RPT-Bericht und wie liest man ihn?
A: Ein TLS-RPT-Bericht ist eine JSON-Datei gemäß RFC 8460. Mailserver senden sie täglich an Domains mit TLS-RPT-Eintrag. Der Bericht enthält die TLS-Verbindungsstatistiken: Erfolge, Fehler und deren Ursachen. Die Dateien liegen als .json.gz vor - der CaptainDNS-Analysator dekodiert sie automatisch.
F: Warum erhalte ich E-Mails von noreply-smtp-tls-reporting@google.com?
A: Ihr DNS-TLS-RPT-Eintrag enthält eine mailto:-Adresse. Google sendet deshalb täglich einen Bericht über TLS-Verbindungen seiner Server zu Ihrer Domain. Das ist gewollt und wichtig für die TLS-Überwachung. Laden Sie diese Berichte regelmäßig in den Analysator hoch.
F: Was ist der Unterschied zwischen einem TLS-RPT Checker und einem TLS-RPT Report Analyzer?
A: Der TLS-RPT Checker prüft Ihren DNS-Eintrag _smtp._tls.domain - also die Konfiguration. Der Report Analyzer interpretiert die empfangenen JSON-Berichte - also die Ergebnisse. Nutzen Sie beide Tools zusammen für eine vollständige TLS-RPT-Kontrolle.
Ergänzende Tools
| Tool | Zweck |
|---|---|
| TLS-RPT-Generator | DNS-TLS-RPT-Eintrag erstellen |
| TLS-RPT-Prüfer | DNS-TLS-RPT-Konfiguration prüfen |
| TLS-RPT Syntax Checker | Syntax eines Eintrags validieren |
| MTA-STS-Prüfer | MTA-STS-Bereitstellung prüfen |
| DANE/TLSA Checker | DANE-Einträge prüfen |
| E-Mail-Domain-Audit | Vollständiges Audit: SPF, DKIM, DMARC, MTA-STS, TLS-RPT |
Nützliche Ressourcen
- RFC 8460 - SMTP TLS Reporting - offizielle TLS-RPT-Spezifikation, definiert das JSON-Schema
- RFC 8461 - MTA Strict Transport Security - MTA-STS-Protokoll, schützt SMTP-Verbindungen per Richtlinie
- RFC 7672 - SMTP Security via DANE - DANE-Authentifizierung für SMTP via TLSA-Einträge
- Google - TLS Reporting konfigurieren - offizieller Google Workspace-Leitfaden
Starten Sie mit einem vollständigen E-Mail-Domain-Audit, um SPF, DKIM, DMARC, MTA-STS und TLS-RPT in einem Durchgang zu prüfen.