Was ist TLS-RPT?

Das Problem: TLS-Fehler bleiben unsichtbar

Wenn ein fremder Mailserver eine E-Mail an deine Domain zustellt, sollte die Verbindung per TLS verschlüsselt sein. Aber was passiert, wenn die TLS-Aushandlung scheitert? Der Sender fällt entweder auf Klartext zurück — oder verweigert die Zustellung komplett, wenn du MTA-STS im Enforce-Modus betreibst.

In beiden Fällen hast du keine Sicht darauf. Du bekommst keine Bounce-Mail, in deinen Logs steht nichts. Der Fehler passiert beim Absender, und du erfährst nie davon.

TLS-RPT bringt Licht in diesen blinden Fleck.

TLS-RPT (SMTP TLS Reporting, definiert in RFC 8460) ist ein Standard, mit dem du von sendenden Mailservern Berichte darüber bekommst, ob ihre TLS-Verbindungen zu deinen Mailservern Probleme hatten.

Man kann es sich gut als DMARC-Reporting für die TLS-Schicht vorstellen: So wie DMARC-Berichte zeigen, wer in deinem Namen Mails verschickt und ob sie authentifiziert sind, zeigen TLS-RPT-Berichte, wer beim Verbindungsaufbau zu deinen Servern an TLS hängenbleibt. Schon ein einzelner TXT-Record unter _smtp._tls.deinedomain.de reicht, damit Anbieter wie Google, Microsoft und Yahoo dir täglich Berichte schicken.

Wie funktioniert es?

TLS-RPT ist schnell aufgesetzt — ein einzelner DNS-Record reicht.

Der DNS-Record

Unter _smtp._tls.deinedomain.de legst du einen TXT-Record an:

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

Der rua-Tag bestimmt, wohin die Berichte gehen. Möglich sind:

mailto: — Versand als E-Mail (JSON, meist gzipped)
https: — Versand per POST an einen HTTPS-Endpunkt

Mehrere Ziele lassen sich kommagetrennt angeben.

Was die Berichte enthalten

TLS-RPT-Berichte sind JSON-Dokumente und enthalten:

Reporting-Organisation — welcher Mailserver den Bericht abgesetzt hat (z. B. Google, Microsoft, Yahoo)
Zeitraum — meist die letzten 24 Stunden
Policy-Typ — ob MTA-STS oder DANE im Spiel war
Erfolgsanzahl — wie viele Sessions TLS sauber ausgehandelt haben
Fehleranzahl — wie viele an TLS gescheitert sind
Fehlerdetails — der konkrete Fehlertyp pro 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: Empfangsziel wählen

Wo sollen die Berichte hingehen?

E-Mail-Adresse — einfach, aber du musst die JSON-Anhänge selbst auswerten
HTTPS-Endpunkt — besser für automatisierte Verarbeitung
Monitoring-Tool — Dienste wie DMARCPulse nehmen dir das Parsen ab

Schritt 2: DNS-Record veröffentlichen

Den TXT-Record im DNS deiner Domain anlegen:

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

Schritt 3: Auf Berichte warten

Große Anbieter (Google, Microsoft, Yahoo) verschicken die Berichte in der Regel täglich. Bis die ersten eintrudeln, vergehen typischerweise 24 bis 48 Stunden nach Veröffentlichung des Records.

Schritt 4: Berichte auswerten

Achte beim Durchsehen besonders auf:

Zertifikatsprobleme — abgelaufene oder nicht passende Zertifikate sind die häufigste Fehlerquelle
Fehlendes STARTTLS — bietet dein Server kein STARTTLS, läuft alles im Klartext
MTA-STS-Abruffehler — wenn du MTA-STS einsetzt: prüfen, ob die Policy-Datei erreichbar ist

TLS-RPT und MTA-STS: zwei Hälften eines Bildes

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

MTA-STS an den Absender: „Du musst TLS sprechen, um an meine Domain zuzustellen.”
TLS-RPT an den Absender: „Und falls TLS scheitert, schick mir bitte einen Bericht.”

Ohne TLS-RPT wird der Enforce-Modus von MTA-STS zum Risiko: Du erkennst nicht, wenn legitime Absender deine Mails nicht mehr zustellen können, weil bei ihnen TLS-Probleme auftreten. Mit TLS-RPT hast du die Rückkanal, um MTA-STS sicher einzusetzen.

Wer schickt TLS-RPT-Berichte?

Diese großen Anbieter berichten zuverlässig:

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

Die Abdeckung wächst, je mehr Organisationen den Standard ausrollen.

Häufige Fallstricke

Falscher Speicherort im DNS — der Record gehört unter _smtp._tls.deinedomain.de, nicht an die Domain-Root oder eine andere Subdomain.
Ungültige Mail-Adresse — die Adresse hinter rua=mailto: muss existieren und Mails entgegennehmen können.
Volles Postfach — größere Domains bekommen schnell viele Berichte. Eher einen HTTPS-Endpunkt oder ein dediziertes Tool nutzen als ein persönliches Postfach.
Berichte versanden lassen — den Record zu veröffentlichen ist nur der Anfang. Wert haben die Berichte erst, wenn jemand sie liest und reagiert.

Was tun, wenn Berichte Fehler zeigen?

Zertifikat abgelaufen — sofort erneuern und automatische Erneuerung einrichten.
Zertifikat passt nicht — sicherstellen, dass es alle Hostnamen abdeckt, die in deinen MX-Records stehen.
STARTTLS fehlt — auf dem Mailserver aktivieren (jeder moderne Server kann das).
MTA-STS-Policy-Fehler — prüfen, ob https://mta-sts.deinedomain.de/.well-known/mta-sts.txt erreichbar und korrekt formatiert ist.

Fazit

TLS-RPT ist ein schlanker, aber unverzichtbarer Baustein im E-Mail-Sicherheits-Monitoring. Ein einziger DNS-Record genügt — und schon siehst du TLS-Probleme, von denen du sonst nie erfahren hättest.

Wenn du MTA-STS einsetzt, führt an TLS-RPT ohnehin kein Weg vorbei. Aber auch ohne MTA-STS lohnt es sich: Wer TLS-Fehler kennt, kann seine E-Mail-Infrastruktur verschlüsselungstauglich halten.

DMARCPulse wertet deine TLS-RPT-Berichte automatisch aus, visualisiert Erfolgsraten und Fehlertrends und meldet sich, sobald etwas Aufmerksamkeit braucht. Heute mit dem Monitoring deiner Mail-Verschlüsselung starten.

Zusammenfassung

TLS-RPT macht TLS-Fehler sichtbar, die du sonst nie zu Gesicht bekämst
Für die Einrichtung reicht ein einzelner DNS-TXT-Record
Große Anbieter wie Google, Microsoft und Yahoo schicken die Berichte täglich
TLS-RPT zusammen mit MTA-STS einsetzen — erst dann ist Transportsicherheit rund
DMARCPulse wertet TLS-RPT-Berichte automatisch aus und meldet sich bei Fehlern