Warum TLS-RPT-Berichte überwachen?
Die TLS-RPT-Überwachung macht die SMTP-Verschlüsselungsfehler sichtbar, die Ihr Server nie protokolliert. Sie ist der einzige standardisierte Kanal (RFC 8460), über den sendende Server Ihnen zurückmelden, was auf der Transportebene kaputtgegangen ist. Ohne sie hinterlässt eine wegen TLS abgewiesene E-Mail keine Spur beim Empfänger. Ihre Reputation rutscht ab. Ihre Nutzer warten auf nichts, weil sie nicht wissen, dass eine Nachricht je existierte.
In nahezu jedem Bericht tauchen dieselben drei Ausfälle auf.
Ein abgelaufenes Zertifikat auf dem MX bringt die verschlüsselte Aushandlung zum Scheitern, und strikte Sender weisen die Nachricht ab, statt sie unverschlüsselt zuzustellen. Eine MTA-STS-Richtlinie, die auf einen verschwundenen MX zeigt, führt zum selben Ergebnis: Verbindung verweigert, Mail nie angekommen. Am gefährlichsten bleibt der STARTTLS-Downgrade, wenn ein Netzwerkgerät die STARTTLS-Ankündigung aus dem SMTP-Dialog entfernt. Die Post läuft dann im Klartext. Niemand bemerkt es. Der TLS-RPT-Bericht aber sieht es.
TLS-RPT-Monitoring in 3 Schritten einrichten
Schritt 1: Domain hinzufügen
Melden Sie sich an und registrieren Sie die zu überwachende Domain. CaptainDNS generiert einen eindeutigen HTTPS-Report-Kollektor und den zugehörigen TLS-RPT-DNS-Eintrag.
Schritt 2: Domain-Inhaberschaft verifizieren
Fügen Sie den Verifizierungs-TXT-Eintrag Ihrem DNS hinzu. Die Validierung erfolgt automatisch, sobald der Eintrag erkannt wird.
Schritt 3: TLS-RPT-Eintrag veröffentlichen
Fügen Sie den bereitgestellten _smtp._tls-TXT-Eintrag Ihrem DNS hinzu. Sendende Server beginnen dann, TLS-Fehlerberichte an Ihren CaptainDNS-Endpunkt zu übermitteln.
Was ist TLS-RPT?
TLS-RPT (SMTP TLS Reporting) ist ein durch die RFC 8460 definierter Standard, der gescheiterte TLS-Aushandlungen an die Empfängerdomain zurückmeldet. Sendende Server melden jede verschlüsselte Verbindung, die fehlschlägt. Ein einziger DNS-Eintrag genügt, um sie auszulösen.
Beispiel für einen DNS-Eintrag:
_smtp._tls.captaindns.com. IN TXT "v=TLSRPTv1; rua=https://api.captaindns.com/tls-rpt/ingest/abc123"
Der _smtp._tls-Eintrag teilt sendenden Servern mit, wohin sie ihre JSON-Berichte senden sollen. Jeder TLS-Fehler bei der Verbindung zu Ihrer Domain löst einen Bericht an die in rua= angegebene URL aus.
Was enthält ein TLS-RPT-Bericht?
Ein TLS-RPT-Bericht ist ein JSON-Dokument, das über ein Fenster von 24 Stunden sämtliche TLS-Verbindungsversuche eines Senders zu Ihrer Domain zusammenfasst. Er zählt erfolgreiche und gescheiterte Sitzungen und schlüsselt jeden Fehler nach Typ auf. CaptainDNS dekodiert dieses JSON und zeigt es im Klartext an.
| Feld | Beschreibung |
|---|---|
| Sendende Organisation | Der E-Mail-Anbieter, der den Bericht gesendet hat |
| Zeitraum | Start- und End-Zeitstempel des Berichtszeitraums |
| Angewandte Richtlinien | Erkannte MTA-STS-, DANE- oder STARTTLS-Richtlinien |
| Erfolgreiche Sitzungen | Anzahl erfolgreich aufgebauter TLS-Verbindungen |
| Fehlgeschlagene Sitzungen | Anzahl fehlgeschlagener TLS-Aushandlungen mit Fehlerdetails |
TLS-RPT-Fehlertypen (RFC 8460)
| Fehlertyp | Beschreibung |
|---|---|
starttls-not-supported | Der empfangende Server unterstützt kein STARTTLS |
certificate-expired | Das vom MX präsentierte TLS-Zertifikat ist abgelaufen |
certificate-host-mismatch | Das Zertifikat stimmt nicht mit dem MX-Hostnamen überein |
certificate-not-trusted | Die Zertifikatskette wird vom Sender nicht als vertrauenswürdig eingestuft |
validation-failure | Allgemeiner TLS-Validierungsfehler |
sts-policy-invalid | Die MTA-STS-Richtlinie konnte nicht validiert werden |
sts-webpki-invalid | Der MTA-STS-Richtlinienhost hat ein ungültiges Web-PKI-Zertifikat |
tlsa-invalid | Der DANE-TLSA-Eintrag ist ungültig oder stimmt nicht überein |
dane-required | DANE ist erforderlich, konnte aber nicht validiert werden |
TLS-RPT vs DMARC
| TLS-RPT | DMARC | |
|---|---|---|
| Schützt | Transportverschlüsselung (SMTP TLS) | Absender-Authentifizierung (SPF/DKIM) |
| Berichtet über | TLS-Verbindungsfehler, Zertifikatsfehler | Authentifizierungs-Abgleichfehler |
| RFC | RFC 8460 | RFC 7489 |
| DNS-Eintrag | _smtp._tls TXT | _dmarc TXT |
| Erkannte Bedrohungen | Abgelaufene Zertifikate, STARTTLS-Entfernung, DANE/MTA-STS-Fehlkonfigurationen | Spoofing, Phishing, Domain-Identitätsmissbrauch |
Beide Protokolle ergänzen sich. Setzen Sie das DMARC-Monitoring parallel zu TLS-RPT ein, um volle Transparenz über Ihre E-Mail-Sicherheit zu erhalten.
Wer sendet TLS-RPT-Berichte?
Die großen E-Mail-Anbieter senden TLS-RPT-Berichte, sobald sie eine TLS-Verbindung zu Ihrer Domain versuchen. Allein Google und Microsoft transportieren den Großteil der eingehenden Mail einer typischen Geschäftsdomain. Empfangen Sie Post von einem von beiden? Dann verschafft Ihnen ein veröffentlichter TLS-RPT-Eintrag bereits eine nützliche Abdeckung.
- Google (Gmail, Workspace): Sendet tägliche aggregierte Berichte über alle Verbindungsversuche
- Microsoft (Outlook, Exchange Online): Meldet TLS-Aushandlungsfehler für Microsoft-365-Mandanten
- Yahoo: Liefert TLS-RPT-Daten für die Yahoo-Mail- und AOL-Infrastruktur
- Apple (iCloud Mail): Berichtet über TLS-Fehler bei der iCloud-Mail-Zustellung
- Comcast: Einer der ersten ISPs mit TLS-RPT-Reporting-Implementierung
Veröffentlichen Sie einen TLS-RPT-Eintrag, und diese Anbieter beginnen automatisch zu berichten. Eine Anmeldung bei jedem einzelnen Anbieter ist nicht nötig.
Praxisbeispiele
Die meisten TLS-Vorfälle lösen sich innerhalb einer Stunde, wenn man sie sieht, und ziehen sich über Wochen, wenn man sie nicht sieht. Hier sind zwei reale Ausfälle, die die TLS-RPT-Überwachung ans Licht gebracht hat.
Vorfall 1: Unerkanntes abgelaufenes Zertifikat
Symptom: Google und Microsoft melden certificate-expired-Fehler. Ihre Nutzer erhalten keine E-Mails mehr von diesen Anbietern.
Diagnose: Das CaptainDNS-Dashboard zeigt einen Fehleranstieg über 24 Stunden. Ursache: ein abgelaufenes Let's Encrypt-Zertifikat auf dem Haupt-MX.
Maßnahme: TLS-Zertifikat sofort erneuern. Die nachfolgenden TLS-RPT-Berichte bestätigen die Wiederherstellung der verschlüsselten Verbindungen.
Vorfall 2: Desynchronisierte MTA-STS-Richtlinie
Symptom: Berichte melden sts-policy-invalid-Fehler. Eine MTA-STS-Richtlinie ist veröffentlicht. Trotzdem werden E-Mails abgewiesen.
Diagnose: Die MTA-STS-Richtlinie verweist auf einen MX-Server, der bei einer Migration entfernt wurde. Sender im enforce-Modus verweigern die Verbindung.
Maßnahme: MTA-STS-Richtlinie aktualisieren und die Versions-id erhöhen. Die nachfolgenden Berichte bestätigen die Korrektur.
In beiden Fällen ist der Auslöser derselbe: ein TLS-RPT-Bericht, der zum richtigen Zeitpunkt gelesen wird. Fügen Sie Ihre Domain zu CaptainDNS hinzu, veröffentlichen Sie den _smtp._tls-Eintrag, und diese Signale landen in Ihrem Dashboard, ohne dass Sie einen Server betreiben müssen.
FAQ - Häufig gestellte Fragen
F: Was ist ein TLS-RPT-Eintrag?
A: Ein TLS-RPT-Eintrag ist ein DNS-TXT-Eintrag unter _smtp._tls.ihredomain.com. Er enthält eine rua=-Direktive, die sendenden Servern mitteilt, wohin TLS-Fehlerberichte gesendet werden sollen (RFC 8460).
F: Ist das TLS-RPT-Monitoring von CaptainDNS kostenlos?
A: Ja, das TLS-RPT-Monitoring ist vollständig kostenlos. Wir sind überzeugt, dass jede Domain ihre TLS-Sicherheit ohne technische Hürden überwachen können sollte.
F: Wie konfiguriere ich meine Domain, um Berichte hierher zu senden?
A: Fügen Sie einen TXT-Eintrag bei _smtp._tls.ihredomain.com mit dem Wert v=TLSRPTv1; rua=https://api.captaindns.com/tls-rpt/ingest/{ihr-token} hinzu. Der genaue Eintrag wird bereitgestellt, wenn Sie Ihre Domain hinzufügen.
F: Welche Berichtsformate werden unterstützt?
A: Wir akzeptieren TLS-RPT-Berichte im JSON-Format gemäß RFC 8460, komprimiert (gzip) oder unkomprimiert. Berichte werden per HTTPS POST entgegengenommen.
F: Wie funktioniert die Domain-Verifizierung?
A: Sie fügen einen von CaptainDNS bereitgestellten Verifizierungs-TXT-Eintrag in Ihrem DNS hinzu. Sobald er erkannt wird, ist die Domain-Inhaberschaft bestätigt und das Monitoring wird aktiviert.
F: Brauche ich MTA-STS, um TLS-RPT zu nutzen?
A: Nein, TLS-RPT funktioniert unabhängig. Es wird jedoch empfohlen, MTA-STS mit TLS-RPT zu kombinieren: MTA-STS erzwingt die Verschlüsselung, TLS-RPT informiert Sie, wenn Sender diese nicht einhalten können.
F: Wie oft treffen Berichte ein?
A: Berichte werden innerhalb weniger Sekunden nach Empfang analysiert und in Ihrem Dashboard angezeigt. Die meisten E-Mail-Anbieter senden Berichte täglich.
F: Welche Risiken bestehen ohne TLS-RPT?
A: Ohne TLS-RPT erfahren Sie nicht, wenn E-Mails an Ihre Domain scheitern. Ein abgelaufenes Zertifikat kann tagelang unbemerkt bleiben. Nachrichten werden still abgewiesen oder unverschlüsselt übertragen. TLS-RPT macht diese Ausfälle sichtbar, bevor sie sich auf Ihre Kommunikation auswirken.
F: Welche TLS-Fehlertypen meldet TLS-RPT?
A: TLS-RPT deckt alle in RFC 8460 definierten Fehlertypen ab: starttls-not-supported, certificate-expired, certificate-host-mismatch, certificate-not-trusted, validation-failure, sts-policy-invalid, sts-webpki-invalid, tlsa-invalid und dane-required. Jeder Fehlertyp weist auf ein spezifisches Problem in der TLS-Aushandlung oder Richtlinienvalidierung hin.
F: Was ist der Unterschied zwischen TLS-RPT und DMARC?
A: TLS-RPT und DMARC schützen unterschiedliche Ebenen. DMARC (RFC 7489) prüft die Absender-Authentifizierung über SPF- und DKIM-Abgleich und bekämpft Spoofing und Phishing. TLS-RPT (RFC 8460) überwacht die Transportverschlüsselung und meldet, wenn SMTP-TLS-Verbindungen scheitern, Zertifikate ablaufen oder STARTTLS herabgestuft wird. Beide sind unverzichtbar.
Ergänzende Tools
| Tool | Nutzen |
|---|---|
| TLS-RPT-Syntaxprüfung | Syntax eines TLS-RPT-Eintrags validieren |
| TLS-RPT-Eintragsprüfung | Den TLS-RPT-DNS-Eintrag Ihrer Domain prüfen |
| TLS-RPT-Generator | Einen TLS-RPT-DNS-Eintrag generieren |
| TLS-RPT-Berichtsleser | Einen TLS-RPT-JSON-Bericht manuell analysieren |
| MTA-STS-Hosting | Ihre MTA-STS-Richtlinie kostenlos hosten |
| DMARC-Monitoring | DMARC-Aggregatberichte überwachen und analysieren |
Nützliche Ressourcen
- RFC 8460 - SMTP TLS Reporting: Offizielle TLS-RPT-Spezifikation
- RFC 8461 - MTA-STS: Ergänzender Standard zur Durchsetzung der SMTP-Verschlüsselung
- Google: TLS-Berichte konfigurieren: Google-Workspace-Anleitung für TLS-RPT