Was ist TLS-RPT?
TLS-RPT (SMTP TLS Reporting, RFC 8460) ist der Berichtskanal für MTA-STS und DANE. Sendende Mailserver, die beim Zustellen an deine Domain Probleme mit TLS haben, schicken einmal täglich einen zusammenfassenden Bericht an die Adresse, die du im TLS-RPT-Record angibst. Darin steht, wie viele Verbindungen erfolgreich waren, wie viele gescheitert sind und warum: abgelaufenes Zertifikat, falscher Hostname, STARTTLS nicht angeboten, Policy nicht abrufbar.
Ohne TLS-RPT ist MTA-STS ein Blindflug. Du veröffentlichst eine Policy und erfährst nie, ob sie Sender aussperrt. Mit TLS-RPT siehst du innerhalb eines Tages, ob Google, Microsoft oder andere große Anbieter Fehler melden, und kannst gefahrlos von testing auf enforce wechseln.
Aufbau des Records
Der Record ist ein TXT-Record unter _smtp._tls.beispiel.de mit genau zwei Tags: v=TLSRPTv1 und rua= mit einer oder mehreren Berichtsadressen, durch Komma getrennt. Erlaubt sind mailto:-Adressen und https:-Endpunkte, die Berichte als JSON per POST entgegennehmen.
_smtp._tls.beispiel.de. IN TXT "v=TLSRPTv1; rua=mailto:tls-reports@beispiel.de"So liest du das Ergebnis
Der Checker zeigt den Record und die erkannten Berichtsziele. Diese Befunde sind möglich:
- Kein Record: Nur ein Hinweis. Du bekommst keine Berichte, die Zustellung ist nicht betroffen.
- Kein rua: Der Record ist vorhanden, nennt aber kein Ziel. Er ist damit wirkungslos.
- Ungültiges rua: Ein Ziel ist weder eine mailto:-Adresse noch eine https-URL, etwa eine Adresse ohne @ oder eine http-URL.
- Mehrere Records: Nur ein TLS-RPT-Record ist erlaubt. Bei mehreren ignorieren Sender alle.
Berichte empfangen und auswerten
Berichte kommen als komprimierte JSON-Anhänge per Mail. Für eine einzelne Domain reicht ein Postfach, das du gelegentlich durchsiehst. Für viele Domains lohnt sich ein Dienst, der die Berichte einsammelt und aufbereitet, dieselben Anbieter, die auch DMARC-Berichte auswerten, bieten das meist an. Die Berichtsadresse darf auf einer anderen Domain liegen; anders als bei DMARC ist dafür keine Freigabe nötig.
Ein Bericht enthält je Sender die Policy, die er angewendet hat (MTA-STS, DANE oder keine), die Zahl erfolgreicher und gescheiterter Sitzungen und je Fehlerklasse Details wie den betroffenen MX und die IP des sendenden Servers. Mit diesen Angaben lässt sich ein Zertifikatsproblem meist innerhalb von Minuten einem konkreten Server zuordnen.
Wichtig: Berichte kommen nur von Sendern, die TLS-RPT unterstützen. Google und Microsoft tun das, viele kleinere Server nicht. Ein Tag ohne Bericht heißt deshalb nicht, dass alles in Ordnung ist, sondern nur, dass die unterstützenden Sender keine Fehler hatten.
TLS-RPT und MTA-STS zusammen überwachen
TLS-RPT ist die Voraussetzung dafür, MTA-STS gefahrlos zu betreiben. DomainWarn prüft für alle Kundendomains, ob der Record existiert und gültig ist, und meldet, wenn er verschwindet, zum Beispiel weil eine Zone beim Hosterwechsel unvollständig übernommen wurde.
Häufige Fragen
- Brauche ich TLS-RPT ohne MTA-STS?
- Der Nutzen ist dann klein, aber nicht null: Sender melden auch dann TLS-Fehler, etwa ein abgelaufenes Zertifikat auf dem MX. Am sinnvollsten ist TLS-RPT als erster Schritt vor der Einführung von MTA-STS.
- Kann ich dieselbe Adresse wie für DMARC-Berichte nutzen?
- Technisch ja, die Formate unterscheiden sich aber. Wenn du einen Auswertungsdienst nutzt, gibt er dir meist eine eigene Adresse für TLS-RPT vor.