Eingaben
Beispiel
example.com -> _smtp._tls TXT mit v=TLSRPTv1 und mailto- oder HTTPS-rua-Zielen.
TLS-RPT-Prüfer/Generator
Bewertet TLS-RPT-TXT-Records, validiert RUA-Ziele, markiert externe Provider und zeigt Konformitätsbefunde mit Korrekturhinweisen.
Nutze es, um TLS-RPT-Reporting-Records zu prüfen, bevor SMTP-TLS-Fehlerreports aus MTA-STS- oder DANE-Setups erwartet werden.
Der Rückkanal, auf dem Mail-TLS-Policies stehen
TLS-RPT ist die Reporting-Hälfte moderner SMTP-Transportsicherheit: MTA-STS und DANE legen fest, was Sender verlangen müssen — TLS-RPT ist der Weg, auf dem diese Sender melden, wenn die Anforderung scheitert. Ohne diesen Kanal scheitert eine erzwingende Policy lautlos: Mail betroffener Sender bleibt einfach aus, und der erste Report ist ein Mensch, der fragt, wo seine Nachricht geblieben ist. Ein kleiner _smtp._tls-TXT-Record verwandelt dieses Schweigen in Aggregat-Reports mit Fehlerklassen und betroffener Sendeinfrastruktur.
Dieser Checker validiert den Record durchgängig: Versionssyntax, die rua-Zielliste, mailto- gegenüber HTTPS-Endpunktform und die informative Frage, ob Reporting an einen externen Provider fließt. Fehlt ein Record, entsteht ein konservativer Starter-Entwurf — damit der Reporting-Kanal lebt, bevor die erste Policy-Verschärfung ihn unverzichtbar macht.
Records und Ziele prüfen, die wirklich funktionieren müssen
Füge beim Entwerfen einen TXT-Wert ein oder frage live DNS ab, um zu sehen, was die Welt gerade auflöst. Behandle dann die Ziele als den eigentlichen Gegenstand der Prüfung: Ein syntaktisch gültiges rua auf ein unbeobachtetes Postfach ist funktional gar kein Reporting. Verifiziere, dass das Postfach existiert, die eigene Mail-Filterung übersteht und tatsächlich gelesen wird — beziehungsweise dass der HTTPS-Endpunkt Einreichungen annimmt.
Veröffentliche genau einen _smtp._tls-Record und liste mehrere Ziele kommasepariert darin auf, statt mehrere Records zu setzen. Wenn Reports eintreffen, lies sie auf Trends statt Einzelfälle: Ein Sender, der einmal scheitert, ist Netzwetter; eine Fehlerklasse, die über Sender hinweg besteht, ist ein Konfigurationsproblem auf deiner Seite — ein abgelaufenes Zertifikat, eine Policy, die nicht mehr zum MX-Set passt, ein Host mit Legacy-TLS. Prüfe den Record nach jeder Mail-Infrastrukturänderung neu; Reporting ist nur so lange billige Versicherung, wie das Ziel funktioniert.
Syntaxprüfung, Entwürfe und ihre Grenzen
Eingefügte Records bleiben lokal; Live-DNS-Abfragen nutzen zuerst Cloudflare DNS-over-HTTPS im Browser, mit dem Same-Origin-DNS-Fallback, falls dieser Pfad scheitert, und senden nur die abgefragten Namen. Das Tool validiert Syntax und Zielform — es versendet keine Test-Reports, kann nicht bestätigen, dass ein Provider Einreichungen annimmt, und bewertet dessen Parsing nicht. Ob Reports letztlich ankommen, hängt vom Senderverhalten und vom Betrieb des Ziels ab — beides außerhalb der Sicht dieser Seite.
Häufige Fragen
Wofür wird TLS-RPT konkret genutzt?
Sendende Mailsysteme melden darüber SMTP-TLS-Policy-Fehler — am wertvollsten neben MTA-STS- oder DANE-Deployments, wo es der routinemäßige Rückkanal ist, der zeigt, dass eine Policy legitime Sender blockiert, bevor Nutzer fehlende Mail bemerken.
Darf rua auf einen externen Reporting-Provider zeigen?
Ja, das ist üblich — Aggregat-Reports zu parsen ist echte Arbeit. Das Tool markiert externe Ziele als informativen Befund: eine bewusste Vertrauensentscheidung, denn der Provider sieht deine Fehler-Telemetrie.
Sollte ich mehrere TLS-RPT-TXT-Records veröffentlichen?
Nein. Ein _smtp._tls-Record mit kommaseparierter rua-Liste darin. Mehrere Records erzeugen Mehrdeutigkeit, die manche Sender auflösen, indem sie sie ignorieren.
Beweist ein gültiger Record, dass Reports ankommen?
Nein. Der Record ist die Einladung; die Zustellung hängt an Sendern, die TLS-RPT implementieren, und an einem Ziel, das Mail oder Einreichungen annimmt. Große Betreiber senden zuverlässig — ein funktionierendes Ziel sieht meist binnen ein, zwei Tagen Traffic.
Brauche ich TLS-RPT ohne MTA-STS oder DANE?
Es funktioniert auch so — Sender können opportunistische TLS-Fehler melden —, aber sein Hauptwert ist die Observability-Schicht einer erzwungenen Policy. Es zuerst zu deployen ist die sinnvolle Reihenfolge: Reporting vor Enforcement.
Was sollte mich in einem Report alarmieren?
Beständige Fehlerklassen: Zertifikatsvalidierungsfehler nach einem Renewal, plötzlich fehlendes STARTTLS auf einem MX-Host oder Policy-Fetch-Fehler, die Sender wiederholen. Solche Muster beschreiben deine Infrastruktur, nicht die des Senders — genau dafür existiert dieser Kanal.