Was TLS-RPT leistet
SMTP TLS Reporting (RFC 8460) bittet sendende Mailserver, Ihnen mitzuteilen, wenn sie nicht über eine ordnungsgemäß verschlüsselte Verbindung an Ihre Domain zustellen konnten: ein abgelaufenes Zertifikat auf einem MX-Host, ein Host, der kein STARTTLS mehr anbietet, eine MTA-STS-Richtlinie, die nicht passt. Absender, die das unterstützen, sammeln diese Ereignisse und senden einen JSON-Bericht pro Tag an die Adressen, die Sie veröffentlichen.
Der Record ist ein TXT-Record unter _smtp._tls.<domain>, zum Beispiel v=TLSRPTv1; rua=mailto:tls-reports@example.com. Das Tag rua nimmt eine oder mehrere durch Kommas getrennte Adressen auf, jede entweder eine mailto:-Adresse oder ein https:-Endpunkt, der den Bericht per POST annimmt.
Was dieses Tool prüft
Es fragt den TXT-Record ab und stellt sicher, dass es genau einen TLS-RPT-Record gibt, dass er mit v=TLSRPTv1 beginnt, dass rua vorhanden ist und dass jede Adresse eine syntaktisch gültige mailto:- oder https:-URI ist. Einfache http:-Endpunkte und Adressen ohne Schema werden markiert, weil Absender sie ignorieren.
Es sendet keinen Testbericht und kann nicht wissen, ob jemand das Postfach liest. Die Berichte sind maschinenlesbares JSON, oft gzip-komprimiert; die meisten lassen rua auf ein Postfach oder einen Dienst zeigen, der sie auswertet.
Warum es neben MTA-STS gehört
MTA-STS im Modus enforce bringt Absender dazu, die Zustellung zu verweigern, wenn TLS fehlschlägt. Ohne TLS-RPT würden Sie davon nur von den Menschen erfahren, deren E-Mail nicht angekommen ist. Veröffentlichen Sie zuerst TLS-RPT, betreiben Sie MTA-STS im Modus testing und stellen Sie auf enforce um, wenn die Berichte sauber sind. TLS-RPT ist auch für sich allein nützlich und ebenso für Domains, die DANE verwenden.