TLS-RPT: Der vollständige Leitfaden zur Überwachung der TLS-Sicherheit deiner E-Mails

Q: Wie konfiguriere ich einen TLS-RPT-Eintrag?

Veröffentliche einen DNS-TXT-Eintrag unter _smtp._tls.captaindns.com mit dem Wert v=TLSRPTv1; rua=mailto:tlsrpt@captaindns.com . Nutze einen TLS-RPT-Generator, um den Eintrag zu erstellen, und füge ihn dann in deine DNS-Zone ein. Die ersten Berichte treffen innerhalb von 24 bis 48 Stunden ein.

Von CaptainDNS
Veröffentlicht am 10. Februar 2026

TLS-RPT: TLS-Verschlüsselungsfehler bei der E-Mail-Zustellung überwachen

TL;DR

TLS-RPT (RFC 8460) sendet dir einen täglichen Bericht über jeden TLS-Verschlüsselungsfehler, den Server beim Senden von E-Mails an dich feststellen
Ohne TLS-RPT weißt du nicht, ob deine E-Mails wegen eines abgelaufenen Zertifikats, eines falsch konfigurierten MX oder einer Downgrade-Attacke unverschlüsselt ankommen
Du musst nur einen einzigen DNS-TXT-Eintrag veröffentlichen: _smtp._tls.captaindns.com mit der Direktive v=TLSRPTv1; rua=mailto:...
TLS-RPT ist der unverzichtbare Begleiter von MTA-STS: Es gibt dir die nötige Transparenz, bevor du in den Modus enforce wechselst

Deine Domain nutzt MTA-STS oder du überlegst, es zu aktivieren? Du hast STARTTLS auf deinen Mailservern konfiguriert? In beiden Fällen bleibt eine Frage offen: Woher weißt du, ob die TLS-Verschlüsselung tatsächlich funktioniert, wenn deine E-Mails zugestellt werden?

Genau dieses Problem löst TLS-RPT. Das in RFC 8460 definierte SMTP TLS Reporting ermöglicht es sendenden Servern (Gmail, Microsoft, Yahoo und allen Anbietern, die es unterstützen), dir detaillierte Berichte über TLS-Aushandlungsfehler zu senden, die beim Versuch auftreten, E-Mails an deine Domain zuzustellen.

Dieser Leitfaden erklärt dir, was TLS-RPT ist, wie es funktioniert, wie du es in wenigen Minuten konfigurierst und wie du die erhaltenen Berichte interpretierst. Ob Systemadministrator, DevOps oder verantwortlich für die E-Mail-Infrastruktur – hier findest du alles, was du brauchst, um TLS-RPT auf deiner Domain einzusetzen.

Was ist TLS-RPT?

TLS-RPT steht für SMTP TLS Reporting und ist ein Internetstandard (RFC 8460), veröffentlicht im September 2018. Seine Aufgabe ist einfach: Dem Inhaber einer Domain ermöglichen, Berichte zu empfangen über fehlgeschlagene TLS-Verbindungsversuche, wenn Server versuchen, E-Mails an ihn zuzustellen.

Konkret: Wenn Gmail versucht, eine E-Mail an contact@captaindns.com zu senden, prüft es, ob der empfangende Server TLS unterstützt und ob die TLS-Aushandlung erfolgreich ist. Wenn etwas fehlschlägt (abgelaufenes Zertifikat, STARTTLS nicht unterstützt, MTA-STS-Richtlinie nicht eingehalten), zeichnet Gmail diesen Fehler auf. Einmal am Tag werden alle Fehler aggregiert und ein JSON-Bericht an die in deinem TLS-RPT-Eintrag angegebene Adresse gesendet.

Warum ist TLS-RPT unverzichtbar?

Ohne TLS-RPT bist du blind in Bezug auf die Verschlüsselungsqualität deiner eingehenden E-Mails:

Ein TLS-Zertifikat läuft auf deinem MX-Server ab → E-Mails kommen weiterhin an (unverschlüsselt, wenn MTA-STS nicht im enforce-Modus ist), aber du merkst es nicht
Ein sekundärer MX unterstützt kein STARTTLS → E-Mails über diesen MX werden ohne Verschlüsselung übertragen
Eine Man-in-the-Middle-Attacke erzwingt einen Downgrade → ohne Berichte unmöglich zu erkennen

TLS-RPT schließt diese Lücke. Du erhältst jeden Tag eine präzise Übersicht: Wie viele TLS-Verbindungen erfolgreich waren, wie viele fehlgeschlagen sind und warum sie fehlgeschlagen sind.

Vergleichsdiagramm: ohne TLS-RPT vs. mit TLS-RPT, Sichtbarkeit bei TLS-Fehlern

Was ist der Unterschied zwischen TLS-RPT und DMARC-Reporting?

DMARC-Berichte (RUA/RUF) und TLS-RPT-Berichte decken unterschiedliche Bereiche ab:

Kriterium	DMARC-Reporting	TLS-RPT
Was wird überwacht	E-Mail-Authentifizierung (SPF, DKIM, Alignment)	Transportverschlüsselung (TLS)
RFC	RFC 7489	RFC 8460
DNS-Eintrag	`_dmarc.domain`	`_smtp._tls.domain`
Berichtsformat	XML (aggregiert) oder Text (forensisch)	JSON
Häufigkeit	Konfigurierbar (oft 24 Std.)	Immer 24 Std.
Protokoll	Absender-Authentifizierung	Sicherheit des Transportkanals

Beide ergänzen sich: DMARC prüft, wer die E-Mail sendet, TLS-RPT prüft, wie die E-Mail transportiert wird. Eine abgesicherte Domain braucht beides.

Wie funktioniert TLS-RPT?

Der TLS-RPT-Mechanismus fügt sich in den normalen E-Mail-Zustellungsablauf ein:

1. Veröffentlichung des DNS-Eintrags

Du veröffentlichst einen TXT-Eintrag unter _smtp._tls.captaindns.com, der die Adresse enthält, an die Berichte gesendet werden sollen.

2. Erkennung durch den sendenden Server

Wenn Gmail (oder ein anderer kompatibler Server) eine E-Mail an deine Domain senden möchte, führt es einen DNS-Lookup auf _smtp._tls.captaindns.com durch, um zu prüfen, ob du TLS-RPT konfiguriert hast.

3. Erfassung der TLS-Ergebnisse

Bei jedem Zustellversuch zeichnet der sendende Server das Ergebnis der TLS-Aushandlung auf: Erfolg oder Fehler, mit dem jeweiligen Fehlertyp.

4. Aggregation und Versand des Berichts

Alle 24 Stunden werden die Ergebnisse aggregiert und ein JSON-Bericht an die in deinem TLS-RPT-Eintrag angegebene rua-Adresse gesendet.

Wer sendet die Berichte?

Die wichtigsten Anbieter, die TLS-RPT-Berichte senden:

Anbieter	Absenderadresse	Unterstützt
Google / Gmail	`noreply-smtp-tls-reporting@google.com`	Ja
Microsoft / Outlook	`tlsrpt@microsoft.com`	Ja
Yahoo / AOL	Variabel	Ja
LinkedIn	Variabel	Ja
Comcast	Variabel	Ja

Wenn du eine E-Mail von noreply-smtp-tls-reporting@google.com erhältst, keine Sorge: Das ist ein legitimer TLS-RPT-Bericht von Google. Er enthält eine komprimierte JSON-Datei (gzip) mit den TLS-Ergebnissen der letzten 24 Stunden.

Die Syntax des TLS-RPT-Eintrags

Der TLS-RPT-Eintrag ist ein DNS-TXT-Record, veröffentlicht unter _smtp._tls.<domain>.

Grundformat

_smtp._tls.captaindns.com. 300 IN TXT "v=TLSRPTv1; rua=mailto:tlsrpt@captaindns.com"

Tag	Pflicht	Beschreibung
`v`	Ja	Protokollversion, immer `TLSRPTv1`
`rua`	Ja	Ziel-URI(s) für die Berichte (`mailto:` oder `https:`)

Beispiele für gültige Konfigurationen

Reporting per E-Mail (am häufigsten):

_smtp._tls.captaindns.com. TXT "v=TLSRPTv1; rua=mailto:tlsrpt@captaindns.com"

Reporting per HTTPS-Endpoint:

_smtp._tls.captaindns.com. TXT "v=TLSRPTv1; rua=https://report.captaindns.com/tlsrpt"

Mehrfach-Reporting (E-Mail + HTTPS):

_smtp._tls.captaindns.com. TXT "v=TLSRPTv1; rua=mailto:tlsrpt@captaindns.com,https://report.captaindns.com/tlsrpt"

Reporting an eine externe Domain

Wenn du die Berichte an eine andere Domain als deine eigene sendest (z. B. einen externen Monitoring-Dienst), muss die Ziel-Domain einen Autorisierungseintrag veröffentlichen:

captaindns.com._report._tls.monitoring-extern.com. TXT "v=TLSRPTv1"

Dieser Mechanismus verhindert, dass ein Angreifer die Berichte an eine nicht autorisierte Domain umleitet. Stelle immer sicher, dass die externe Domain diesen Autorisierungseintrag veröffentlicht hat.

Konfigurationstipps

Dediziertes Postfach: Verwende eine dedizierte E-Mail-Adresse (z. B. tlsrpt@captaindns.com), damit die Berichte nicht in deinem Hauptpostfach untergehen
Angemessener TTL: Ein TTL von 300 bis 3.600 Sekunden ist für diesen Eintrag geeignet
HTTPS für hohes Volumen: Wenn du viele E-Mails empfängst, ist ein HTTPS-Endpoint besser geeignet als ein E-Mail-Postfach für die Verarbeitung der Berichte

Den JSON-Bericht von TLS-RPT verstehen

TLS-RPT-Berichte werden im JSON-Format gesendet, komprimiert als gzip. Hier ist die Struktur eines typischen Berichts:

{
  "organization-name": "Google Inc.",
  "date-range": {
    "start-datetime": "2026-02-08T00:00:00Z",
    "end-datetime": "2026-02-09T00:00:00Z"
  },
  "contact-info": "smtp-tls-reporting@google.com",
  "report-id": "2026-02-08T00:00:00Z_captaindns.com",
  "policies": [
    {
      "policy": {
        "policy-type": "sts",
        "policy-string": [
          "version: STSv1",
          "mode: enforce",
          "mx: mail.captaindns.com",
          "max_age: 604800"
        ],
        "policy-domain": "captaindns.com"
      },
      "summary": {
        "total-successful-session-count": 4523,
        "total-failure-session-count": 2
      },
      "failure-details": [
        {
          "result-type": "certificate-expired",
          "sending-mta-ip": "192.0.2.1",
          "receiving-mx-hostname": "mail.captaindns.com",
          "failed-session-count": 2
        }
      ]
    }
  ]
}

Entschlüsselung des Berichts

Feld	Bedeutung
`organization-name`	Wer den Bericht sendet (Google, Microsoft usw.)
`date-range`	Abgedeckter Zeitraum (immer 24 Std.)
`policy-type`	Art der angewendeten Richtlinie: `sts` (MTA-STS), `tlsa` (DANE) oder `no-policy-found`
`total-successful-session-count`	Anzahl erfolgreicher TLS-Verbindungen
`total-failure-session-count`	Anzahl fehlgeschlagener TLS-Verbindungen
`failure-details`	Details zu jedem Fehlertyp

Die Arten von TLS-Fehlern

Jeder Fehler wird durch einen result-type kategorisiert. Hier die wichtigsten:

Code	Beschreibung	Schweregrad	Maßnahme
`starttls-not-supported`	Der MX-Server unterstützt kein STARTTLS	Kritisch	STARTTLS auf dem Server aktivieren
`certificate-expired`	Das TLS-Zertifikat des Servers ist abgelaufen	Kritisch	Zertifikat sofort erneuern
`certificate-host-mismatch`	Das Zertifikat passt nicht zum Hostnamen des MX	Kritisch	Zertifikat oder Hostnamen korrigieren
`certificate-not-trusted`	Zertifikat nicht von einer vertrauenswürdigen CA signiert	Hoch	Zertifikat einer anerkannten CA verwenden
`validation-failure`	Generischer TLS-Validierungsfehler	Hoch	Vollständige TLS-Konfiguration prüfen
`sts-policy-fetch-error`	MTA-STS-Richtlinie konnte nicht abgerufen werden	Mittel	Datei `mta-sts.txt` überprüfen
`sts-policy-invalid`	Die MTA-STS-Richtlinie ist ungültig	Mittel	Syntax der Richtlinie korrigieren
`sts-webpki-invalid`	Das HTTPS-Zertifikat des Richtlinienservers ist ungültig	Mittel	Zertifikat der Subdomain `mta-sts` erneuern
`tlsa-invalid`	Ungültiger TLSA-Record (DANE)	Mittel	TLSA-Records korrigieren
`dnssec-invalid`	DNSSEC-Validierung fehlgeschlagen	Hoch	DNSSEC-Konfiguration überprüfen

Übersichtstabelle der TLS-RPT-Fehlertypen mit Schweregrad und empfohlener Maßnahme

TLS-RPT und MTA-STS: Das unverzichtbare Duo

TLS-RPT entfaltet sein volles Potenzial in Kombination mit MTA-STS. Hier ist der Grund:

Der empfohlene Workflow

TLS-RPT konfigurieren: Veröffentliche deinen _smtp._tls-Eintrag, um Berichte zu empfangen
MTA-STS im Testing-Modus aktivieren: Veröffentliche deine MTA-STS-Richtlinie mit mode: testing
Berichte analysieren: Über 1 bis 2 Wochen zeigen dir die TLS-RPT-Berichte, ob TLS-Verbindungen fehlschlagen
Probleme beheben: Abgelaufene Zertifikate, nicht abgedeckte MX-Server, fehlerhafte TLS-Konfigurationen
In den Enforce-Modus wechseln: Sobald die Berichte null Fehler bestätigen, stelle MTA-STS auf mode: enforce um

Ohne TLS-RPT ist der Wechsel in den Enforce-Modus ein Blindflug: Du riskierst, legitime E-Mails abzulehnen, ohne es zu wissen.

TLS-RPT funktioniert auch mit DANE

TLS-RPT beschränkt sich nicht auf MTA-STS. Es meldet auch Fehler im Zusammenhang mit DANE-TLSA-Records (RFC 7672). Wenn deine Domain DNSSEC nutzt und TLSA-Records veröffentlicht, enthalten die TLS-RPT-Berichte auch die DANE-Validierungsergebnisse mit dem policy-type: tlsa.

TLS-RPT in 5 Minuten konfigurieren

Schritt 1: Reporting-Adresse wählen

Erstelle eine dedizierte E-Mail-Adresse für den Empfang der Berichte:

tlsrpt@captaindns.com (empfohlen)
Oder verwende einen HTTPS-Endpoint, wenn du ein automatisiertes Verarbeitungssystem hast

Schritt 2: DNS-Eintrag generieren

Nutze unseren TLS-RPT-Generator, um den passenden Eintrag für deine Domain zu erstellen. Du erhältst einen kopierfertigen Record.

Schritt 3: DNS-Eintrag veröffentlichen

Füge den TXT-Eintrag in deine DNS-Zone ein:

Feld	Wert
Host	`_smtp._tls`
Typ	`TXT`
Wert	`v=TLSRPTv1; rua=mailto:tlsrpt@captaindns.com`
TTL	`3600`

Schritt 4: Konfiguration überprüfen

Nutze unseren TLS-RPT-Syntaxprüfer, um zu überprüfen, ob dein Eintrag korrekt formatiert ist.

Schritt 5: Auf die ersten Berichte warten

Die Berichte treffen in der Regel 24 bis 48 Stunden nach Veröffentlichung des Eintrags ein. Google ist oft der Erste, der Berichte sendet.

Häufige Fehler und Fehlerbehebung

Keine Berichte nach 48 Stunden erhalten

Stelle sicher, dass der Eintrag unter _smtp._tls.captaindns.com veröffentlicht ist (nicht unter _smtp-tls oder smtp._tls)
Prüfe die Syntax: v=TLSRPTv1 (nicht v=TLSRPTv2 oder v=TLSRPT1)
Stelle sicher, dass das empfangende E-Mail-Postfach existiert und gzip-Anhänge akzeptiert
Prüfe, ob deine Domain genügend E-Mails empfängt, um Berichte auszulösen

Berichte kommen an, sind aber leer

Wenn total-failure-session-count immer 0 ist, ist das eine gute Nachricht: Deine TLS-Konfiguration funktioniert korrekt. Die Berichte bestätigen, dass alle TLS-Verbindungen erfolgreich sind.

E-Mails von `noreply-smtp-tls-reporting@google.com`

Diese E-Mails sind legitim. Google sendet einen täglichen TLS-RPT-Bericht für jede Domain, die einen _smtp._tls-Eintrag veröffentlicht hat. Die angehängte Datei (.json.gz) enthält den Bericht. Markiere diese E-Mails nicht als Spam.

Empfohlener Aktionsplan

TLS-RPT-Eintrag veröffentlichen: 5 Minuten mit dem TLS-RPT-Generator (siehe Schritt 2 oben)
MTA-STS im Testing-Modus konfigurieren: Aktiviere die MTA-STS-Richtlinie, damit die TLS-RPT-Berichte Validierungsergebnisse enthalten
Berichte 2 Wochen lang analysieren: Identifiziere TLS-Fehler und behebe sie
MTA-STS in den Enforce-Modus schalten: Sobald die Berichte sauber sind, aktiviere die Ablehnung fehlgeschlagener TLS-Verbindungen
Fortlaufend überwachen: Die täglichen Berichte warnen dich bei jedem neuen Problem (abgelaufenes Zertifikat, MX-Änderung usw.)

FAQ

Was ist TLS-RPT und wofür wird es verwendet?

TLS-RPT (SMTP TLS Reporting, RFC 8460) ist ein Mechanismus, der es dem Inhaber einer Domain ermöglicht, tägliche Berichte über fehlgeschlagene TLS-Aushandlungen bei der E-Mail-Zustellung zu empfangen. Es gibt dir vollständige Transparenz über die Verschlüsselungsqualität deiner eingehenden E-Mails.

Wie konfiguriere ich einen TLS-RPT-Eintrag?

Veröffentliche einen DNS-TXT-Eintrag unter _smtp._tls.captaindns.com mit dem Wert v=TLSRPTv1; rua=mailto:tlsrpt@captaindns.com. Nutze einen TLS-RPT-Generator, um den Eintrag zu erstellen, und füge ihn dann in deine DNS-Zone ein. Die ersten Berichte treffen innerhalb von 24 bis 48 Stunden ein.

Warum erhalte ich E-Mails von noreply-smtp-tls-reporting@google.com?

Diese E-Mails sind legitime TLS-RPT-Berichte von Google. Deine Domain hat einen _smtp._tls-Eintrag konfiguriert, und Google sendet dir täglich einen komprimierten JSON-Bericht mit den TLS-Aushandlungsergebnissen für die E-Mails, die dir zugestellt wurden.

Was ist der Unterschied zwischen TLS-RPT und DMARC-Reporting?

DMARC überwacht die E-Mail-Authentifizierung (SPF, DKIM, Alignment), während TLS-RPT die Transportverschlüsselung (TLS) überwacht. DMARC prüft, wer die E-Mail sendet, TLS-RPT prüft, wie sie transportiert wird. Beide sind komplementär und gemeinsam empfohlen.

Ist TLS-RPT Pflicht, wenn ich MTA-STS verwende?

Nein, TLS-RPT ist technisch nicht verpflichtend für MTA-STS. Es wird jedoch dringend empfohlen: Ohne TLS-RPT weißt du nicht, ob TLS-Verbindungen fehlschlagen. Das ist besonders kritisch, bevor du MTA-STS in den Enforce-Modus schaltest, da die Berichte es dir ermöglichen, Probleme vorab zu erkennen und zu beheben.

Wie oft werden TLS-RPT-Berichte gesendet?

TLS-RPT-Berichte werden einmal täglich gesendet (Zeitraum von 24 Stunden). Jeder kompatible Anbieter (Google, Microsoft, Yahoo usw.) sendet seinen eigenen Bericht unabhängig. Du erhältst also potenziell mehrere Berichte pro Tag, einen pro Anbieter.

Wie lese ich einen TLS-RPT-JSON-Bericht?

Ein TLS-RPT-Bericht ist eine gzip-komprimierte JSON-Datei. Er enthält die sendende Organisation, den abgedeckten Zeitraum und für jede TLS-Richtlinie (MTA-STS oder DANE): die Anzahl erfolgreicher Sitzungen, die Anzahl der Fehler und die Details zu jedem Fehlertyp (abgelaufenes Zertifikat, STARTTLS nicht unterstützt usw.).

Kann man sowohl mailto: als auch https: in TLS-RPT verwenden?

Ja, du kannst mehrere Reporting-URIs durch Komma getrennt angeben. Zum Beispiel: rua=mailto:tlsrpt@captaindns.com,https://report.captaindns.com/tlsrpt. Der HTTPS-Endpoint wird für Domains mit hohem E-Mail-Volumen empfohlen.

Glossar

TLS-RPT: SMTP TLS Reporting, Mechanismus zur Berichterstattung über TLS-Fehler, definiert in RFC 8460.
MTA-STS: Mail Transfer Agent Strict Transport Security (RFC 8461), Richtlinie, die TLS-Verschlüsselung für den E-Mail-Empfang erzwingt.
DANE: DNS-Based Authentication of Named Entities (RFC 7672), alternativer Mechanismus zu MTA-STS, der DNSSEC und TLSA-Records zur Validierung von TLS-Zertifikaten nutzt.
STARTTLS: SMTP-Erweiterung, die es ermöglicht, eine zunächst unverschlüsselte Verbindung zu verschlüsseln. Standardmäßig opportunistisch (keine Ablehnung bei fehlgeschlagener Verschlüsselung).
Downgrade-Attacke: Angriff, bei dem ein Vermittler die Verbindung unverschlüsselt lässt, indem er den STARTTLS-Befehl aus der Serverantwort entfernt.
RUA: Reporting URI for Aggregated reports, die Adresse, an die TLS-RPT-Berichte gesendet werden.

Überprüfe jetzt deine Konfiguration: Nutze unseren TLS-RPT-Prüfer, um den _smtp._tls-Eintrag deiner Domain in wenigen Sekunden zu analysieren.

FAQ

Was ist TLS-RPT und wofür wird es verwendet?

Wie konfiguriere ich einen TLS-RPT-Eintrag?

Warum erhalte ich E-Mails von noreply-smtp-tls-reporting@google.com?

Was ist der Unterschied zwischen TLS-RPT und DMARC-Reporting?

Ist TLS-RPT Pflicht, wenn ich MTA-STS verwende?

Wie oft werden TLS-RPT-Berichte gesendet?

Wie lese ich einen TLS-RPT-JSON-Bericht?

Kann man sowohl mailto: als auch https: in TLS-RPT verwenden?

Ähnliche Artikel