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 fügen Sie Ihre Domain hinzu. CaptainDNS stellt eine E-Mail-Adresse für den Berichtsempfang des Monitors sowie eine alternative HTTPS-URL bereit.
Schritt 2: Domain-Inhaberschaft verifizieren
Fügen Sie den Verifizierungs-TXT von CaptainDNS hinzu, um die Domain-Inhaberschaft nachzuweisen. Domain-Verifizierung und Aktivierung bestätigen keinen Berichtsempfang.
Schritt 3: TLS-RPT-Eintrag veröffentlichen
Öffnen Sie die Einrichtung des Monitors und veröffentlichen Sie den empfohlenen _smtp._tls-TXT mit dem mailto-Ziel. Prüfen Sie die beibehaltenen Empfänger, bevor Sie einen vorhandenen TXT ersetzen. Bei einem DNS-Lesefehler ergänzen Sie nur das Fragment in rua=, ohne andere Empfänger zu entfernen, oder versuchen Sie es erneut, um den vollständigen Wert zu erhalten.
Was ist TLS-RPT?
TLS-RPT (SMTP TLS Reporting), definiert in RFC 8460, ermöglicht teilnehmenden Absendern, Ergebnisse von TLS-Verbindungen zu melden. Der TXT gibt das Berichtsziel an, garantiert aber keinen Versand.
Beispiel für einen DNS-Eintrag:
_smtp._tls.captaindns.com. IN TXT "v=TLSRPTv1; rua=mailto:tlsrpt-TOKEN@mailsrv1.captaindns.com"
Nur ein Beispiel: Ersetzen Sie TOKEN durch den Token aus der Einrichtung Ihres Monitors. Prüfen Sie bei einem bestehenden TXT anhand der Empfehlung des Monitors, welche Empfänger beibehalten werden. Das mailto-Fragment allein ist kein vollständiger TXT-Eintrag.
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 |
Die 11 TLS-RPT-Fehlertypen (RFC 8460)
§4.3 der RFC 8460 definiert 11 Werte für result-type, und die Überwachung meldet sie alle. Manche Absender senden zusätzlich starttls-not-offered, eine Variante von starttls-not-supported außerhalb der RFC: sie wird ebenso behandelt.
| 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 |
tlsa-invalid | Der DANE-TLSA-Eintrag ist ungültig oder stimmt nicht überein |
dnssec-invalid | Die für DANE notwendige DNSSEC-Kette ist gebrochen oder fehlt |
dane-required | DANE ist erforderlich, konnte aber nicht validiert werden |
sts-policy-fetch-error | Die MTA-STS-Richtlinie konnte nicht abgerufen werden (HTTPS oder DNS) |
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 |
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?
Berichte stammen von Absendern, die TLS-RPT unterstützen und versuchen, E-Mails an Ihre Domain zuzustellen. Verfügbarkeit und Häufigkeit hängen vom Mailverkehr und der Implementierung des Absenders ab. Die Veröffentlichung des TXT garantiert keinen Bericht eines bestimmten Anbieters.
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.
CaptainDNS analysiert empfangene Berichte, ohne dass Sie einen Server betreiben oder JSON dekodieren müssen. Die Zustellung hängt von den Absendern und dem Mailverkehr zu Ihrer Domain ab.
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: Das erste Tool in Ihrem Konto ist kostenlos. Jede TLS-RPT-Domain zählt als ein Tool: danach 3 €/Monat zzgl. MwSt. Keine versteckten Gebühren, keine Testphase.
F: Wie konfiguriere ich meine Domain, um Berichte hierher zu senden?
A: Öffnen Sie die Einrichtung des Monitors und veröffentlichen Sie den empfohlenen _smtp._tls-TXT mit dem mailto-Ziel. Prüfen Sie die beibehaltenen Empfänger, bevor Sie einen vorhandenen TXT ersetzen. Bei einem DNS-Lesefehler ergänzen Sie nur das Fragment in rua=, ohne andere Empfänger zu entfernen, oder versuchen Sie es erneut, um den vollständigen Wert zu erhalten.
F: Welche Berichtsformate werden unterstützt?
A: Wir akzeptieren TLS-RPT-Berichte im JSON-Format gemäß RFC 8460, mit oder ohne gzip-Komprimierung, per E-Mail und HTTPS POST. E-Mail ist das empfohlene Ziel; HTTPS wird weiterhin unterstützt.
F: Wie funktioniert die Domain-Verifizierung?
A: Fügen Sie den Verifizierungs-TXT von CaptainDNS hinzu, um die Domain-Inhaberschaft nachzuweisen. Domain-Verifizierung und Aktivierung bestätigen keinen Berichtsempfang.
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: Absender mit TLS-RPT-Unterstützung senden üblicherweise Berichte für Zeiträume von 24 Stunden. Der Empfang hängt von diesen Absendern und dem Mailverkehr ab. Für den ersten Bericht gibt es keine garantierte Frist; empfangene Berichte werden anschließend im Dashboard analysiert.
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 in den empfangenen Berichten sichtbar.
F: Welche TLS-Fehlertypen meldet TLS-RPT?
A: TLS-RPT deckt die 11 in RFC 8460 definierten Fehlertypen ab: starttls-not-supported, certificate-expired, certificate-host-mismatch, certificate-not-trusted, validation-failure, tlsa-invalid, dnssec-invalid, dane-required, sts-policy-fetch-error, sts-policy-invalid und sts-webpki-invalid. 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 hosten (erstes Tool kostenlos, danach 3 €/Monat zzgl. MwSt.) |
| 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