TLS-RPT (SMTP TLS Reporting) Record-Prüfer

Ruft den _smtp._tls TXT-Eintrag einer Domain ab, um zu prüfen, ob das Berichtsziel (rua) für fehlgeschlagene TLS-Verbindungen gemäß RFC 8460 korrekt konfiguriert ist. Nützlich in Kombination mit MTA-STS/DANE.

Zuletzt aktualisiert: 2026-09-20

Berichte über gescheiterte TLS-Verbindungen prüfen (TLS-RPT)

Die Einführung von MTA-STS oder DANE lässt eines im Dunkeln: **ob die Zustellung tatsächlich scheitert, weiß allein die sendende Seite.** TLS-RPT ist die Vereinbarung, die diese Lücke schließt. Tragen Sie eine Berichtsadresse in den TXT-Eintrag `_smtp._tls` ein, und **sendende Server schicken Ihnen täglich einen Bericht.** Dieses Werkzeug holt jenen Eintrag und meldet, ob seine Form RFC 8460 entspricht.

**TLS-RPT ist selbst keine Abwehr, sondern ein Mittel der Beobachtung.** Es tut nichts, um einen Angriff aufzuhalten; es sagt Ihnen lediglich, wie oft der Aufbau von TLS fehlschlug. **Ohne diese Beobachtung lässt sich jedoch nicht beurteilen, wann MTA-STS auf `enforce` zu stellen ist.** Bliebe die Zustellung in dem Augenblick stehen, in dem die Erzwingung beginnt, so erführen Sie es erst, wenn jemand sich beschwert. **In der Praxis lautet die eingespielte Reihenfolge daher: zuerst TLS-RPT einrichten, MTA-STS bei `testing` betreiben und die Berichte lesen, und erst auf `enforce` wechseln, wenn nichts mehr scheitert.**

So gehen Sie vor

Geben Sie die Domäne ein Nennen Sie allein die Domäne, in der Form `example.com`.
Prüfen Sie den TXT-Eintrag **Suchen Sie nach `v=TLSRPTv1` und einem `rua=`.**
Bestätigen Sie die Form der Berichtsadresse Sie wird mit `mailto:` oder `https:` geschrieben. **Bestätigen Sie auch, dass diese Adresse wirklich empfangen kann.**
Legen Sie fest, wer die Berichte liest **Sie einzurichten und nie zu lesen führt zu nichts.** Bestimmen Sie, wer hinsieht und wann.

Tipps für die Nutzung

TLS-RPT wird von der empfangenden Domain deklariert, aber von den sendenden Mailservern ausgewertet, die dadurch erfahren, wohin sie Statistiken schicken sollen, wenn eine TLS-Verbindung zu Ihrer Domain fehlschlägt.
Im rua-Feld können eine mailto:-Adresse, ein https:-Endpunkt oder beides, durch Kommas getrennt, angegeben werden, sodass Berichte gleichzeitig an ein Postfach und einen automatisierten Sammler gesendet werden können.
Berichte kommen im JSON-Format (application/tlsrpt+json, häufig gzip-komprimiert) an, daher lohnt es sich, einen eigenen Parser oder ein eigenes Postfach einzurichten, statt sie manuell lesen zu wollen.
Direkt nach der Einführung von MTA-STS oder DANE sollten Sie die TLS-RPT-Berichte eine Zeit lang im Auge behalten, um übersehene Fehlkonfigurationen zu erkennen.
Große Mailanbieter wie Google, Microsoft und Yahoo senden alle TLS-RPT-Berichte, sodass Domains mit viel Mailverkehr zu diesen Anbietern am meisten von der Einführung profitieren.

Wofür Sie es nutzen können

Ehe MTA-STS auf Erzwingung geht

**Sie können messen, ob etwas scheitert, solange Sie noch bei `testing` sind**, was Ihnen die Grundlage für die Entscheidung gibt.

Um Zustellprobleme früh zu bemerken

Sie erfahren vom Auftreten der Fehler, ohne auf eine Meldung zu warten.

Um nach der Einführung von DANE zu überwachen

**Eine Unstimmigkeit zwischen Zertifikat und TLSA-Eintrag zeigt sich in den Berichten als Fehlschlag.**

Um die Form des eigenen Eintrags zu prüfen

Ein Fehler in der Schreibweise von `rua` zeigt sich darin, dass überhaupt kein Bericht eintrifft.

Begriffe zu TLS-RPT

_smtp._tls TXT: **Der DNS-Eintrag, der die Berichtsadresse führt.** Er wird in der Form `v=TLSRPTv1; rua=mailto:...` geschrieben.
Rua: Wohin die Berichte gehen sollen. **Geben Sie eine E-Post-Adresse oder eine zum Empfang eingerichtete HTTPS-Adresse an.**
RFC 8460: Die Norm, die das Format von TLS-RPT und den Inhalt eines Berichts festlegt.
Täglicher Bericht: Der Bericht, den ein sendender Server über einen Tag schickt. Er führt die Zahl der Erfolge und Fehlschläge sowie deren Gründe.
MTA-STS: Die Vereinbarung, die TLS erzwingt. **TLS-RPT wird mit ihr verbunden, um zu sehen, wie diese Erzwingung tatsächlich ausfällt.**
DANE: Die Vereinbarung, die Zertifikate auf der Voraussetzung von DNSSEC prüft. **Auch Schwierigkeiten hier treten in den TLS-RPT-Berichten zutage.**

Häufige Fragen

MTA-STS ist der Durchsetzungsmechanismus, der TLS für eingehende Mail erzwingt. TLS-RPT ist der Beobachtungsmechanismus, der zurückmeldet, ob TLS-Verbindungen tatsächlich fehlschlagen. Beide werden unabhängig voneinander konfiguriert, und man kann auch nur eines von beiden einführen.

Nicht unbedingt – die meisten Domains verwenden noch kein TLS-RPT. Wenn Sie jedoch MTA-STS oder DANE eingeführt haben, lohnt es sich, TLS-RPT ebenfalls einzurichten, um Fehlkonfigurationen erkennen zu können.

An die mailto:-Adresse oder den https:-Endpunkt, der im rua-Feld des TXT-Eintrags angegeben ist. Mehrere Ziele können durch Kommas getrennt angegeben werden.

Die Berichte sind strukturierte JSON-Daten, daher verlassen sich die meisten Betreiber auf ein Monitoring-Tool oder Skript zur automatisierten Auswertung, statt sie manuell zu lesen. Mehrere Anbieter bieten spezielle Dienste zur Berichtsanalyse an.

Dieses Tool prüft nur die Syntax und die Pflichtfelder (v, rua) des TXT-Eintrags. Es überprüft nicht, ob tatsächlich Berichte ankommen. Warten Sie nach der Einrichtung daher einige Tage und bestätigen Sie, dass tatsächlich eine Berichts-E-Mail eintrifft.

Übrigens – Die Lücke der „stillen Störung“, die TLS-RPT geschlossen hat

TLS-RPT (TLS Reporting, RFC 8460) wurde 2018 veröffentlicht, fast zeitgleich mit MTA-STS (RFC 8461). Beide wurden in derselben Arbeitsgruppe entwickelt und haben viele Gemeinsamkeiten – beide bauen auf einem DNS-TXT-Eintrag auf, und beide wurden gemeinsam von Google, Microsoft, Yahoo und anderen vorangetrieben –, spielen aber sehr unterschiedliche Rollen. MTA-STS ist die Durchsetzungsebene, die TLS erzwingt; TLS-RPT ist die Beobachtungsebene, die zeigt, was danach tatsächlich passiert ist.

Bevor es TLS-RPT gab, wurde ein fehlgeschlagener TLS-Handshake bei der SMTP-Zustellung in den meisten Fällen nur auf dem sendenden Server protokolliert und dem Administrator der empfangenden Domain überhaupt nicht mitgeteilt. Ein abgelaufenes Zertifikat oder eine falsch konfigurierte MTA-STS-Richtlinie konnte die Mailzustellung lautlos stören, und niemand bemerkte es, bis tatsächlich keine Mails mehr ankamen – ein echter blinder Fleck im Betrieb.

Mit TLS-RPT wird täglich ein zusammengefasster Bericht an das in rua angegebene Ziel gesendet. Der Bericht ist strukturiertes JSON (application/tlsrpt+json, häufig gzip-komprimiert) mit Erfolgs- und Fehlerzahlen sowie, im Fehlerfall, der zugrunde liegenden Ursache (Zertifikatsabweichung, fehlgeschlagene STARTTLS-Aushandlung usw.) – gedacht zur Verarbeitung durch Monitoring-Tools, nicht zum Lesen durch Menschen.

In der Praxis wird TLS-RPT meist zusammen mit MTA-STS oder DANE eingerichtet. Wird nur die Durchsetzung eingeführt, gibt es keine Möglichkeit zu erkennen, ob eine Fehlkonfiguration lautlos legitime Mails blockiert; die Beobachtung der TLS-RPT-Berichte erlaubt es, die Durchsetzung sicher auszurollen.

Alle Wissenstexte ansehen