TLS-RPT einrichten: Record setzen, Berichte lesen, Fehler beheben

Was TLS-RPT ist und wozu du es brauchst

TLS-RPT steht für SMTP TLS Reporting und ist in RFC 8460 definiert. Deine Domain veröffentlicht im DNS eine Adresse, an die sendende Mailserver Berichte über ihre TLS-Verbindungen zu deinen MX-Hosts schicken. Ein Bericht deckt einen Tag ab und nennt, wie viele Sitzungen erfolgreich verschlüsselt wurden und wie viele gescheitert sind, jeweils mit dem Grund.

TLS-RPT ist der Rückkanal für MTA-STS und DANE. Beide Verfahren erlauben deiner Domain, TLS für eingehende Mail zu erzwingen. Kann ein Absender die Policy nicht abrufen oder passt das Zertifikat nicht zum MX-Host, stellt er im enforce-Modus nicht zu. Ohne TLS-RPT erfährst du davon erst, wenn sich jemand beschwert, mit TLS-RPT steht es am nächsten Morgen im Bericht.

TLS-RPT selbst ändert nichts an der Zustellung. Der Record erzwingt nichts und blockiert nichts. Deshalb kannst du ihn gefahrlos als Erstes setzen, noch bevor MTA-STS oder DANE stehen.

Der TLS-RPT-Record

Der Record ist ein TXT-Record auf dem Hostnamen _smtp._tls unterhalb deiner Domain. Er enthält die Versionsangabe v=TLSRPTv1 und mindestens ein rua-Ziel. Als Ziel ist eine Mailadresse (mailto:) oder ein HTTPS-Endpunkt erlaubt, mehrere Ziele trennst du mit Komma.

_smtp._tls.beispiel.de.  IN TXT  "v=TLSRPTv1; rua=mailto:tlsrpt@beispiel.de"

_smtp._tls.beispiel.de.  IN TXT  "v=TLSRPTv1; rua=mailto:tlsrpt@beispiel.de,https://tlsrpt.beispiel.de/report"

Per Mail kommt der Bericht als gzip-Anhang vom Typ application/tlsrpt+gzip, an einen HTTPS-Endpunkt per POST als application/tlsrpt+json. Die Mailadresse darf in einer fremden Domain liegen, etwa bei einem Reporting-Dienst oder deiner Agentur. Anders als bei DMARC ist dafür keine Freigabe über einen zusätzlichen DNS-Record nötig. Pro Domain darf es nur einen TLS-RPT-Record geben; finden Absender zwei, ignorieren sie beide.

TLS-RPT Schritt für Schritt einrichten

Die Einrichtung dauert wenige Minuten. Der Aufwand steckt nicht im Record, sondern darin, die Berichte später auch zu lesen.

1. Ziel festlegen: Lege ein Postfach wie tlsrpt@beispiel.de an oder nutze einen Reporting-Dienst, der TLS-RPT auswertet. Viele DMARC-Dienste nehmen auch TLS-Berichte entgegen.
2. TXT-Record anlegen: Beim DNS-Hoster einen TXT-Record mit dem Namen _smtp._tls (in manchen Oberflächen _smtp._tls.beispiel.de. mit Punkt am Ende) und dem Wert v=TLSRPTv1; rua=mailto:tlsrpt@beispiel.de setzen.
3. Record prüfen: Mit dig TXT _smtp._tls.beispiel.de oder dem TLS-RPT Checker von DomainWarn kontrollieren, ob der Record aufgelöst wird und die Syntax stimmt. Der Checker prüft zusätzlich die rua-Ziele und ob für die Domain eine MTA-STS-Policy existiert.
4. Warten: Die ersten Berichte kommen frühestens am nächsten Tag, weil Absender sie einmal täglich für den Vortag erzeugen.
5. Auswerten: Berichte mit Fehlern anschauen, bevor du MTA-STS auf enforce stellst.

"TLS-RPT record not found" beheben

Meldet ein Prüfwerkzeug TLS-RPT record not found, obwohl du den Record gesetzt hast, ist fast immer der Name falsch. Die typischen Ursachen:

• Falscher Hostname: Der Record liegt auf _tls, auf _smtp oder auf der Domain selbst statt auf _smtp._tls. Beide Labels müssen in dieser Reihenfolge stehen.
• Fehlender Unterstrich: Manche DNS-Oberflächen entfernen oder verweigern den Unterstrich. Ändert der Hoster den Namen still auf smtp.tls, ist der Record wertlos.
• Record auf der falschen Zone: Wer den vollen Namen in ein Feld eingibt, das die Domain automatisch anhängt, bekommt _smtp._tls.beispiel.de.beispiel.de. Schau dir den vollständigen Namen an, den dig zurückgibt.
• TTL und Propagation: Ein frisch gesetzter Record braucht bis zu einer Stunde, bis alle Resolver ihn sehen, nach einer Änderung mit vorher hoher TTL auch länger. Frage einen autoritativen Nameserver direkt, um Caching auszuschließen.
• Tippfehler im Wert: TLSRPTv1 mit kleinem v am Anfang, das Semikolon zwischen den Feldern und rua= mit mailto: davor. Fehlt das Präfix mailto:, ist der Record ungültig.

dig +short TXT _smtp._tls.beispiel.de
"v=TLSRPTv1; rua=mailto:tlsrpt@beispiel.de"

dig +short TXT _smtp._tls.beispiel.de @ns1.dns-hoster.de

Berichte verstehen

Ein TLS-RPT-Bericht ist eine JSON-Datei. Im Kopf stehen der berichtende Anbieter (organization-name), der Zeitraum (date-range) und eine report-id. Darunter folgt das Array policies. Jeder Eintrag beschreibt eine Policy, die der Absender für deine Domain angewendet hat, mit einer Zusammenfassung und optional einer Liste der Fehler.

policy-type sagt dir, welche Regel der Absender gefunden hat: sts für eine MTA-STS-Policy, tlsa für DANE, no-policy-found, wenn weder das eine noch das andere vorhanden war. Die Zahlen in summary sind das Wichtigste: total-successful-session-count zählt die erfolgreich verschlüsselten Verbindungen, total-failure-session-count die gescheiterten.

{
  "organization-name": "Google Inc.",
  "date-range": {
    "start-datetime": "2026-09-11T00:00:00Z",
    "end-datetime": "2026-09-11T23:59:59Z"
  },
  "report-id": "2026-09-11T00:00:00Z_beispiel.de",
  "policies": [
    {
      "policy": {
        "policy-type": "sts",
        "policy-string": [
          "version: STSv1",
          "mode: testing",
          "mx: mail1.beispiel.de",
          "mx: mail2.beispiel.de",
          "max_age: 86400"
        ],
        "policy-domain": "beispiel.de"
      },
      "summary": {
        "total-successful-session-count": 1284,
        "total-failure-session-count": 3
      },
      "failure-details": [
        {
          "result-type": "certificate-expired",
          "sending-mta-ip": "209.85.220.41",
          "receiving-mx-hostname": "mail2.beispiel.de",
          "receiving-ip": "203.0.113.25",
          "failed-session-count": 3
        }
      ]
    }
  ]
}

Dieser Bericht sagt: Google hat am 11. September 2026 eine MTA-STS-Policy im Modus testing für beispiel.de gefunden, 1284 Sitzungen erfolgreich verschlüsselt und 3 Sitzungen zu mail2.beispiel.de wegen eines abgelaufenen Zertifikats als Fehler gewertet. Im testing-Modus wurden diese Mails trotzdem zugestellt, im enforce-Modus wären sie liegen geblieben.

Die wichtigsten result-type Werte

Jeder Eintrag in failure-details trägt einen result-type, dazu die IP des sendenden Servers, den betroffenen MX-Host und failed-session-count. Der result-type sagt dir, wo du suchen musst.

• starttls-not-supported: Der MX-Host hat kein STARTTLS angeboten. Häufig ein Backup-MX oder eine Firewall, die das Angebot herausfiltert.
• certificate-expired: Das Zertifikat des MX-Hosts ist abgelaufen. Erneuern und prüfen, ob die automatische Verlängerung läuft.
• certificate-host-mismatch: Das Zertifikat gilt nicht für den Hostnamen aus dem MX-Record oder der Policy. Typisch nach einem Hostnamenwechsel.
• certificate-not-trusted: Die Kette ist unvollständig oder die CA unbekannt. Meist fehlt das Zwischenzertifikat auf dem Server.
• validation-failure: Sammelkategorie für andere TLS-Fehler, etwa eine Protokollversion, die der Absender nicht mehr akzeptiert.
• sts-policy-fetch-error: Die MTA-STS-Policy war unter mta-sts.beispiel.de nicht abrufbar. Der Webhost war nicht erreichbar, hat einen Redirect geliefert oder ein falsches Zertifikat präsentiert.
• tlsa-invalid und dnssec-invalid: Fehler auf der DANE-Seite. Der TLSA-Record passt nicht zum Zertifikat oder die DNSSEC-Kette ist gebrochen.

Ein einzelner Fehler unter tausenden Sitzungen ist meist ein vorübergehendes Netzwerkproblem. Auffällig wird es, wenn ein result-type jeden Tag auf demselben MX-Host auftaucht.

Microsoft 365 und Google Workspace

Microsoft 365 und Exchange Online: Exchange Online verschickt TLS-RPT-Berichte für Mail, die es an fremde Domains ausliefert. Für deine eigene Domain gibt es im Microsoft 365 Admin Center keinen Schalter dafür. Den Record setzt du beim DNS-Hoster der Domain; nur wenn die DNS-Zone bei Microsoft liegt, trägst du ihn dort ein. Als Ziel kann ein Exchange-Online-Postfach dienen, achte aber darauf, dass Anhänge vom Typ application/tlsrpt+gzip nicht von einer Anhangsregel blockiert werden.

Google Workspace: Google sendet seit Jahren TLS-Berichte an alle Domains mit TLS-RPT-Record und ist meist der erste Absender, von dem du Berichte siehst. Die MX-Hosts von Google tragen gültige Zertifikate, sodass Fehlerberichte für eine Workspace-Domain fast immer auf die eigene MTA-STS-Policy zurückgehen, etwa auf eine mx-Zeile, die nach dem Wechsel von aspmx.l.google.com auf smtp.google.com nicht mehr passt. Eine Auswertung der empfangenen Berichte bietet Google nicht an.

Wer die Berichte braucht und was im Betrieb schiefgeht

TLS-RPT lohnt sich vor allem, wenn deine Domain MTA-STS oder DANE einsetzt oder das plant. Dann sind die Berichte deine einzige Quelle dafür, ob Absender die Policy lesen und ob Zustellungen an der Verschlüsselung scheitern. Ohne MTA-STS und DANE erfährst du nur, ob opportunistisches STARTTLS zu deinen MX-Hosts funktioniert: nützlich, etwa für ein abgelaufenes Zertifikat, aber nicht dringend.

Die typischen Fehler im laufenden Betrieb:

• Der Record steht, aber das Postfach liest niemand. Ein Reporting-Dienst mit Benachrichtigung bei Fehlern ist die bessere Wahl.
• Die rua-Adresse liegt auf dem MX-Host, der selbst gerade kaputt ist. Eine Adresse in einer anderen Domain oder ein HTTPS-Endpunkt umgeht das.
• Der Record wurde bei einem DNS-Umzug vergessen. Records mit Unterstrich fallen beim manuellen Übertragen einer Zone gern heraus.

Häufige Fragen

Brauche ich TLS-RPT auch ohne MTA-STS?

Nötig ist es nicht. Ohne MTA-STS oder DANE melden die Berichte nur, ob opportunistisches STARTTLS zu deinen MX-Hosts funktioniert. Sobald du MTA-STS planst, setze den TLS-RPT-Record als Erstes, damit du im testing-Modus schon Daten hast.

Warum bekomme ich keine Berichte, obwohl der Record steht?

Berichte kommen nur von Absendern, die TLS-RPT unterstützen, und nur, wenn sie am Vortag Mail an deine Domain geschickt haben. Bei wenig eingehender Mail können Tage vergehen. Ist die Syntax korrekt und die Domain empfängt Mail von Google oder Microsoft, kommen die Berichte innerhalb von ein bis zwei Tagen.

Kann ich die Berichte an eine Adresse in einer anderen Domain schicken lassen?

Ja. Anders als bei DMARC verlangt TLS-RPT keine Freigabe der Zieldomain. Du kannst also rua=mailto:tlsrpt@agentur.de für alle Kundendomains eintragen und die Berichte zentral sammeln.