TLS-RPT (SMTP TLS Reporting, RFC 8460) ist das Berichtswesen für den verschlüsselten Transport von E-Mails. Wer eine Domain betreibt, erfährt damit, ob eingehende Verbindungen tatsächlich per TLS zustande kommen — oder ob sie scheitern, weil eine Gegenstelle falsch konfiguriert ist oder ein Angreifer den Transport manipuliert.
Die Lücke, die gemeldet wird
Zwischen Mailservern beginnt die Verbindung im Klartext und wird erst per STARTTLS aufgewertet. Ist das Angebot nicht vorhanden, abgeschaltet oder entfernt, läuft die Übertragung unverschlüsselt weiter. Für den Betreiber der Empfängerdomain ist von außen nicht erkennbar, ob gerade schlicht keine Post eintrifft oder ob der Transport durch ein technisches Problem beeinträchtigt ist. Genau diese Informationslücke schließt TLS-RPT.
Das Verfahren läuft parallel zu MTA-STS, das die Verschlüsselung verpflichtend macht, und zu DANE, das sie über signierte DNS-Einträge absichert. TLS-RPT beobachtet und meldet — es erzwingt selbst nichts.
Der DNS-Eintrag
Die Konfiguration erfolgt wie beim Berichtswesen von DMARC über einen TXT-Record, hier unter dem Namen _smtp._tls:
_smtp._tls.example.com. IN TXT "v=TLSRPTv1; rua=mailto:Diese E-Mail-Adresse ist vor Spambots geschützt! Zur Anzeige muss JavaScript eingeschaltet sein. "Der Parameter rua (reporting URI authority) gibt an, wohin die Berichte gehen sollen. Neben der Zustellung per E-Mail ist auch HTTPS als Übertragungsweg spezifiziert.
Was in einem Bericht steht
Die Berichte sind JSON-Dokumente und werden in der Regel einmal täglich ausgeliefert. Sie enthalten eine Statistik über erfolgreiche und fehlgeschlagene TLS-Verbindungen, den angewandten Fehlertyp und die Information, welche Richtlinie — DANE oder MTA-STS — zur Anwendung kam. Ein Bericht hat etwa diese Gestalt:
{
"organization-name": "Example Mail Provider",
"date-range": { "start-datetime": "2026-09-09T00:00:00Z",
"end-datetime": "2026-09-09T23:59:59Z" },
"policies": [
{ "policy": { "policy-type": "sts", "policy-string": ["version: STSv1"] },
"summary": { "total-successful-session-count": 842,
"total-failure-session-count": 3 } }
]
}Typische Fehlerarten
- starttls-not-supported: Die Gegenstelle bietet keine Verschlüsselung an.
- certificate-expired: Das Zertifikat ist abgelaufen — der häufigste und einfachste Fall.
- certificate-host-mismatch: Das Zertifikat ist nicht auf den Hostnamen aus dem MX-Record ausgestellt.
- validation-failure: Die Kette lässt sich nicht bis zu einer vertrauenswürdigen Wurzel prüfen.
- sts-policy-invalid: Die hinterlegte MTA-STS-Richtlinie ist fehlerhaft aufgebaut.
Ein Zustellfehler ist damit kein Rätsel mehr, sondern eine Zahl mit Ursache. Die Berichte sind die Voraussetzung dafür, eine Richtlinie von testing auf enforce umzustellen, ohne den Mailverkehr zu riskieren.
Verwandte Grundlagen: SMTP, TLS-Handshake, TLS 1.3, Zertifikat, DNS, E-Mail, SPF, DKIM, ARC.