TLS-RPT einrichten: der eine DNS-Eintrag und wann er sich lohnt
TLS-RPT ist ein einziger, providerunabhängiger TXT-Eintrag, der dir Berichte über TLS-Fehler schickt. Wann er sich lohnt, was er meldet und wie du ihn einträgst.
Stand: Juli 2026
Zusammenfassung: TLS-RPT (SMTP TLS Reporting, RFC 8460) sorgt dafür, dass dir andere Mailserver Berichte schicken, wenn die verschlüsselte Zustellung an deine Domain scheitert. Es ist ein einziger TXT-Eintrag unter
_smtp._tls— der einzige variable Teil ist deine eigene Report-Adresse. Deshalb ist die Einrichtung bei jedem Anbieter gleich. Und: TLS-RPT ist nur sinnvoll, wenn du bereits MTA-STS oder DANE einsetzt — es berichtet über deren Fehler.
Anders als bei SPF oder DKIM gibt es bei TLS-RPT keinen providerspezifischen Wert (kein include:, keinen Selektor). Du veröffentlichst überall denselben Eintrag, egal ob deine DNS-Zone bei IONOS, Cloudflare oder Strato liegt. Wo genau du einen TXT-Eintrag anlegst, zeigen dir die SPF- und DKIM-Anleitungen deines Anbieters.
Was TLS-RPT meldet
MTA-STS und DANE erzwingen verschlüsselte Verbindungen zu deiner Domain — aber wenn dabei etwas schiefgeht, bekommst du es ohne TLS-RPT nicht mit. TLS-RPT schließt diese Lücke: Es lässt Absender, die
compatible with MTA-STS or DANE to share success and failure
statistiken teilen. Gemeldet werden unter anderem
failures in routing, DNS resolution, and STARTTLS negotiation
— also genau die Probleme, die deine verschlüsselte Zustellung stören.
Die Voraussetzung: MTA-STS oder DANE
Das ist der entscheidende Punkt: Ohne MTA-STS oder DANE hat TLS-RPT nichts zu berichten. TLS-RPT ist kein eigenständiger Schutz, sondern die Berichtsschicht für die beiden Verfahren. Richte zuerst MTA-STS oder DANE ein — TLS-RPT kommt danach als kleine, risikolose Ergänzung obendrauf.
Der Eintrag
TLS-RPT ist ein TXT-Eintrag under the name "_smtp._tls" deiner Domain — also _smtp._tls.deine-domain.de. Der Versionswert ist vorgeschrieben:
This document defines version 1 of TLSRPT, for which this value MUST be equal to "TLSRPTv1".
Über rua= legst du fest, wohin die Berichte gehen:
A URI specifying the endpoint to which aggregate information about policy validation results should be sent
Das kann eine E-Mail-Adresse (mailto:) oder ein HTTPS-Endpunkt (rua=https://reporting.example.com/v1/tlsrpt) sein. Für die meisten reicht mailto::
v=TLSRPTv1;rua=mailto:reports@example.com
Ersetze reports@example.com durch deine eigene Report-Adresse. Achte darauf, dass der Eintrag mit v=TLSRPTv1; beginnt — records that do not begin with "v=TLSRPTv1;" are discarded.
Lohnt sich TLS-RPT für dich?
- Ja, wenn du bereits MTA-STS oder DANE aktiv hast und wissen willst, ob (und wo) verschlüsselte Zustellung an dich fehlschlägt — der Aufwand ist ein einziger DNS-Eintrag.
- Nein (noch nicht), wenn du weder MTA-STS noch DANE einsetzt. Dann gibt es keine TLS-Richtlinie, über die berichtet werden könnte — der Eintrag läuft ins Leere.
Wenn du eine echte Empfängeradresse für die täglichen XML/JSON-Berichte einträgst, plane ein, sie auszuwerten (oder ein Monitoring-Tool zu nutzen) — sonst sammelst du Berichte, die niemand liest.
Konfiguration prüfen
Ob dein TLS-RPT-Eintrag syntaktisch gültig ist und ob MTA-STS/DANE als Grundlage stehen, prüfst du in Sekunden mit dem kostenlosen Kuveris-Scanner.
Weiterführende Links
- RFC 8460 — SMTP TLS Reporting (abgerufen: 18. Juli 2026)