Was ist TLS-RPT? — TLS-Fehler überwachen

Das Problem: Du kannst TLS-Fehler nicht sehen

Wenn ein anderer Mailserver eine E-Mail an deine Domain sendet, sollte die Verbindung mit TLS verschlüsselt sein. Aber was passiert, wenn die TLS-Aushandlung fehlschlägt? Der Sendeserver fällt möglicherweise auf Klartext zurück, oder — wenn du MTA-STS im Enforce-Modus hast — verweigert er die Zustellung komplett.

In beiden Fällen hast du keine Sichtbarkeit. Es gibt keine Bounce-Nachrichten, keine Fehlerprotokolle auf deiner Seite. Der Fehler passiert auf der Infrastruktur des Absenders, und du erfährst nie davon.

TLS-RPT behebt diesen blinden Fleck.

Was ist TLS-RPT?

TLS-RPT (TLS Reporting), definiert in RFC 8460, ermöglicht es Domain-Inhabern, tägliche Berichte über TLS-Verbindungsfehler zu erhalten, wenn andere Server E-Mails an ihre Domain senden. Ein einzelner DNS-TXT-Record bei _smtp._tls.deinedomain.de aktiviert die Berichterstattung von großen Anbietern wie Google, Microsoft und Yahoo.

TLS-RPT (SMTP TLS Reporting, definiert in RFC 8460) ist ein Standard, der es dir ermöglicht, Berichte von sendenden Mailservern über TLS-Verbindungsfehler zu erhalten, wenn sie E-Mails an deine Domain zustellen.

Stell es dir vor wie DMARC-Reporting, aber für TLS-Verschlüsselung. Genau wie DMARC-Berichte dir sagen, wer E-Mails im Namen deiner Domain sendet und ob sie die Authentifizierung bestehen, sagen dir TLS-RPT-Berichte, welche Absender TLS-Probleme beim Verbinden mit deinen Mailservern erleben.

Wie funktioniert es?

TLS-RPT ist einfach einzurichten — es erfordert nur einen einzigen DNS-Record.

Der DNS-Record

Du veröffentlichst einen TXT-Record unter _smtp._tls.deinedomain.de:

_smtp._tls.deinedomain.de  TXT  "v=TLSRPTv1; rua=mailto:[email protected]"

Der rua-Tag gibt an, wohin Berichte gesendet werden sollen. Du kannst verwenden:

• mailto: — Berichte werden als E-Mail gesendet (JSON-Format, oft gzipped)
• https: — Berichte werden per POST an einen HTTPS-Endpunkt gesendet

Du kannst mehrere Ziele angeben, indem du sie mit Kommas trennst.

Was die Berichte enthalten

TLS-RPT-Berichte sind JSON-Dokumente, die enthalten:

• Berichtsorganisation — welcher Mailserver den Bericht gesendet hat (z.B. Google, Microsoft, Yahoo)
• Zeitraum — den Zeitraum, den der Bericht abdeckt (normalerweise 24 Stunden)
• Policy-Typ — ob MTA-STS oder DANE aktiv war
• Erfolgsanzahl — Anzahl der Sessions, die TLS erfolgreich ausgehandelt haben
• Fehleranzahl — Anzahl der Sessions, bei denen TLS fehlgeschlagen ist
• Fehlerdetails — der spezifische Fehlertyp für jeden Vorfall

Häufige Fehlertypen

Fehlertyp	Bedeutung
starttls-not-supported	Dein Server bietet STARTTLS nicht an
certificate-expired	Dein TLS-Zertifikat ist abgelaufen
certificate-not-trusted	Zertifikat ist selbstsigniert oder von einer nicht vertrauenswürdigen CA
certificate-host-mismatch	Zertifikat passt nicht zum MX-Hostnamen
validation-failure	Allgemeiner TLS-Validierungsfehler
sts-policy-fetch-error	MTA-STS-Policy-Datei konnte nicht abgerufen werden
sts-webpki-invalid	MTA-STS-Policy-Datei hat ein ungültiges Zertifikat

Häufige TLS-Fehlertypen in TLS-RPT-Berichten

Fehlertyp	Bedeutung	Erforderliche Maßnahme
starttls-not-supported	Empfangsserver bietet kein STARTTLS an	TLS auf dem Mailserver aktivieren
certificate-expired	TLS-Zertifikat ist abgelaufen	Zertifikat sofort erneuern
certificate-host-mismatch	Zertifikat passt nicht zum MX-Hostnamen	Zertifikat für MX-Records ausstellen
validation-failure	Zertifikatskette kann nicht verifiziert werden	Zertifikatskette reparieren oder vertrauenswürdige CA nutzen
sts-policy-fetch-error	MTA-STS-Policy-Datei nicht abrufbar	HTTPS-Hosting von .well-known/mta-sts.txt prüfen

Einrichtung

Schritt 1: Berichtsziel wählen

Entscheide, wo du Berichte empfangen möchtest:

• E-Mail-Adresse — einfach, aber du musst JSON-Anhänge parsen
• HTTPS-Endpunkt — besser geeignet für automatisierte Verarbeitung
• Ein Monitoring-Tool — Dienste wie DMARCPulse können TLS-RPT-Berichte automatisch verarbeiten

Schritt 2: DNS-Record veröffentlichen

Füge den TXT-Record zum DNS deiner Domain hinzu:

_smtp._tls.deinedomain.de  TXT  "v=TLSRPTv1; rua=mailto:[email protected]"

Schritt 3: Auf Berichte warten

Berichte werden typischerweise täglich von großen E-Mail-Anbietern (Google, Microsoft, Yahoo) gesendet. Es kann 24-48 Stunden dauern, bis die ersten Berichte eintreffen, nachdem du den DNS-Record veröffentlicht hast.

Schritt 4: Berichte analysieren

Prüfe die Berichte auf Fehler. Worauf du achten solltest:

• Zertifikatsprobleme — abgelaufene oder nicht übereinstimmende Zertifikate sind die häufigste Ursache für TLS-Fehler
• Fehlendes STARTTLS — wenn dein Server STARTTLS nicht anbietet, werden alle Verbindungen unverschlüsselt sein
• MTA-STS-Abruffehler — wenn du MTA-STS nutzt, stelle sicher, dass die Policy-Datei erreichbar ist

TLS-RPT und MTA-STS: Das Gesamtbild

TLS-RPT und MTA-STS sind füreinander konzipiert:

• MTA-STS sagt Absendern: “Ihr müsst TLS verwenden, um E-Mails an meine Domain zuzustellen”
• TLS-RPT sagt Absendern: “Wenn TLS fehlschlägt, sendet mir einen Bericht darüber”

Ohne TLS-RPT ist das Deployment von MTA-STS im Enforce-Modus riskant — du würdest nicht wissen, ob legitime Absender E-Mails nicht zustellen können, weil TLS-Probleme auftreten. TLS-RPT gibt dir die Feedback-Schleife, die du brauchst, um MTA-STS sicher einzusetzen.

Wer sendet TLS-RPT-Berichte?

Große E-Mail-Anbieter, die TLS-RPT-Berichte senden:

• Google (Gmail)
• Microsoft (Outlook.com, Office 365)
• Yahoo Mail
• Comcast
• LinkedIn

Die Abdeckung wächst, da immer mehr Organisationen den Standard implementieren.

Häufige Fallstricke

• Falscher DNS-Ort — Der Record muss unter _smtp._tls.deinedomain.de liegen, nicht an der Domain-Root oder einer anderen Subdomain
• Ungültige E-Mail-Adresse — Stelle sicher, dass die E-Mail-Adresse in rua=mailto: existiert und E-Mails empfangen kann
• Postfach-Überlauf — Große Domains können viele Berichte erhalten. Erwäge einen HTTPS-Endpunkt oder ein dediziertes Verarbeitungstool statt eines persönlichen Postfachs
• Berichte ignorieren — Den Record zu veröffentlichen ist nur der erste Schritt. Die Berichte sind nur wertvoll, wenn du sie tatsächlich liest und darauf reagierst

Was tun, wenn Berichte Fehler zeigen?

1. Zertifikat abgelaufen — Erneuere dein TLS-Zertifikat sofort und richte automatische Erneuerung ein
2. Zertifikat passt nicht — Stelle sicher, dass dein Zertifikat alle Hostnamen abdeckt, die in deinen MX-Records aufgeführt sind
3. STARTTLS nicht unterstützt — Aktiviere STARTTLS auf deinem Mailserver (die meisten modernen Mailserver unterstützen es)
4. MTA-STS-Policy-Fehler — Prüfe, ob https://mta-sts.deinedomain.de/.well-known/mta-sts.txt erreichbar und korrekt formatiert ist

Fazit

TLS-RPT ist ein leichtgewichtiger, aber unverzichtbarer Standard für das E-Mail-Sicherheits-Monitoring. Ein einziger DNS-Record gibt dir Sichtbarkeit über TLS-Fehler, von denen du sonst nie erfahren würdest.

Wenn du MTA-STS nutzt, ist TLS-RPT praktisch Pflicht. Aber auch ohne MTA-STS hilft dir das Wissen über TLS-Fehler, die Verschlüsselungsgesundheit deiner E-Mail-Infrastruktur zu erhalten.

DMARCPulse verarbeitet deine TLS-RPT-Berichte automatisch, visualisiert Erfolgsraten und Fehlertrends und warnt dich, wenn Probleme Aufmerksamkeit erfordern. Starte noch heute mit dem Monitoring deiner E-Mail-Verschlüsselung.

Zusammenfassung

• TLS-RPT gibt dir Sichtbarkeit über TLS-Fehler, die du sonst nicht sehen kannst
• Die Einrichtung erfordert nur einen einzelnen DNS-TXT-Record
• Berichte werden täglich von großen Anbietern wie Google, Microsoft und Yahoo gesendet
• Nutze TLS-RPT zusammen mit MTA-STS für vollständige Transportsicherheit
• DMARCPulse verarbeitet TLS-RPT-Berichte automatisch und alarmiert bei Fehlern