← Frankys Web GitHub Kontakt

TLS-RPT Generator

TLS-RPT-Record erzeugen, damit Zustellprobleme mit TLS nicht still bleiben.

Wohin sollen die Berichte gehen?

TLS-RPT sorgt dafür, dass Sie erfahren, wenn andere Mailserver Ihre Domain nicht verschlüsselt erreichen können. Ohne diese Berichte scheitert eine TLS-Verbindung still: der sendende Server stellt entweder unverschlüsselt zu oder gar nicht, und auf Ihrer Seite deutet nichts darauf hin. Ein TLS-RPT-Record ist ein einzelner TXT-Eintrag und die einzige Möglichkeit, diese Fälle überhaupt zu sehen.

Was der Generator macht

Sie geben an, wohin die Berichte gehen sollen. Möglich sind zwei Arten von Ziel, und der Generator lässt Sie die Art auswählen, statt sie in eine Adresse hineinzuschreiben: eine E-Mail-Adresse oder ein HTTPS-Endpunkt. Das nötige mailto: beziehungsweise https:// ergänzt er selbst, prüft jeden Wert und setzt daraus den fertigen Eintrag zusammen. Mehrere Ziele sind erlaubt, und jedes bekommt seine eigene Zeile.

Wichtig ist auch hier der Name des Eintrags: er gehört auf _smtp._tls. vor Ihrer Domain, nicht auf die Domain selbst. Wie bei DMARC und MTA-STS ist der falsche Name der Fehler, der nicht auffällt, denn es kommt einfach nie ein Bericht.

Das Ergebnis lesen

Die Hinweise unter dem Record sagen vor allem, was tatsächlich ankommt, denn genau darüber gibt es regelmäßig ein Missverständnis. Die Berichte sind keine lesbaren Fehlermeldungen, sondern JSON-Dateien in gzip-Archiven, die einmal täglich von jedem größeren Empfänger eintreffen. Ein persönliches Postfach ist dafür der falsche Ort; sinnvoll ist eine eigene Adresse, die automatisch ausgewertet wird, oder gleich ein HTTPS-Endpunkt.

Wird ein HTTPS-Endpunkt angegeben, schicken Empfänger die Berichte per POST dorthin, mit dem Inhaltstyp application/tlsrpt+gzip. Der Endpunkt muss das annehmen können, sonst gehen die Berichte verloren, ohne dass jemand etwas davon merkt.

Hintergrund: was der RFC verlangt

Maßgeblich ist RFC 8460. Er verlangt genau zwei Angaben: v=TLSRPTv1 als ersten Tag, exakt so geschrieben, und rua mit mindestens einem Ziel. Erlaubt sind dort ausschließlich mailto: und https:; ein einfaches http ist ungültig, was bei einem Verfahren zur Meldung fehlgeschlagener Verschlüsselung auch schwer anders zu erwarten wäre.

TLS-RPT gehört fachlich zu MTA-STS und DANE, ist aber von beiden unabhängig und lässt sich allein einrichten. Besonders lohnt es sich vor MTA-STS: im Test-Modus meldet MTA-STS Abweichungen, und TLS-RPT ist der Weg, auf dem diese Meldungen bei Ihnen ankommen. Ohne TLS-RPT ist der Test-Modus eine Beobachtung, die niemand beobachtet.

Häufige Fehlerbilder

  • Der Record steht auf der Domain statt auf _smtp._tls. Er wird dann nie gefunden.
  • Die Adresse ohne mailto: eingetragen. Der Record sieht richtig aus und ist ungültig; dieser Generator ergänzt das Präfix deshalb selbst.
  • Berichte an ein persönliches Postfach. Täglich mehrere gzip-Archive, die niemand öffnet, und nach zwei Wochen filtert sie eine Regel weg.
  • Ein HTTPS-Endpunkt, der POST nicht annimmt. Die Berichte verschwinden stillschweigend.
  • TLS-RPT eingerichtet, aber nie ausgewertet. Die Berichte sind der eigentliche Zweck; ohne Auswertung ist der Eintrag nur Dekoration.

Wenn der Eintrag im DNS steht, prüfen Sie ihn mit dem MTA-STS und TLS-RPT Check: der liest den Record, nennt die eingetragenen Ziele und zeigt zugleich, wie es um MTA-STS steht.

Häufige Fragen

Was genau bekomme ich da zugeschickt?
Aggregierte Berichte über TLS-Verbindungen zu Ihren Mailservern: wie viele Zustellversuche verschlüsselt geklappt haben, wie viele nicht und woran es lag. Das Format ist JSON in einem gzip-Archiv, ein Bericht je Empfänger und Tag. Zum Lesen von Hand ist das nicht gedacht, es gibt fertige Auswerter dafür.
Brauche ich dafür MTA-STS oder DANE?
Nein, TLS-RPT funktioniert für sich allein und ist auch allein nützlich: Sie sehen dann, wie oft Ihre Domain überhaupt verschlüsselt erreicht wird. Zusammen mit MTA-STS wird es besonders wertvoll, denn erst über TLS-RPT erfahren Sie, was der Test-Modus von MTA-STS gemeldet hat.
E-Mail-Adresse oder HTTPS-Endpunkt?
Die Adresse ist der einfachere Weg und überall verbreitet; nehmen Sie eine eigene, nicht Ihr Arbeitspostfach. Ein HTTPS-Endpunkt lohnt sich, wenn Sie die Berichte ohnehin automatisch auswerten: dann landen sie direkt im Auswerter statt den Umweg über ein Postfach zu nehmen. Beides nebeneinander ist erlaubt.
Kann ich mehrere Ziele angeben?
Ja, RFC 8460 erlaubt mehrere Ziele, und jeder Empfänger schickt seinen Bericht an alle. In der Praxis genügen ein oder zwei; jedes weitere Ziel vervielfacht nur das Aufkommen, das ohnehin täglich eintrifft.
Wo genau trage ich den Record ein?
Als TXT-Eintrag auf _smtp._tls.ihre-domain.de. Bei den meisten Anbietern geben Sie als Namen nur _smtp._tls ein, weil die Domain automatisch angehängt wird; der Generator zeigt zur Sicherheit den vollständigen Namen an.
Verrate ich mit dem Record etwas über meine Infrastruktur?
Der Record enthält nur das Berichtsziel, und er steht öffentlich im DNS. Genau deshalb gehören dort keine Zugangsdaten hinein, auch nicht in einer HTTPS-Adresse. Wer die Berichte an einen Endpunkt schicken lässt, sichert ihn anders ab, etwa über einen schwer zu erratenden Pfad und serverseitige Prüfungen.
Ändert der Generator etwas an meinem DNS?
Nein. Er erzeugt nur einen Text, den Sie kopieren und selbst bei Ihrem DNS-Anbieter eintragen. Er fragt dafür auch nichts ab, sondern rechnet ausschließlich aus Ihren Angaben.