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

⚡TL;DR

• TLS-RPT (RFC 8460) sendet Ihnen einen täglichen Bericht über jeden TLS-Verschlüsselungsfehler, den Server beim Senden von E-Mails an Sie feststellen
• Ohne TLS-RPT wissen Sie nicht, ob Ihre E-Mails wegen eines abgelaufenen Zertifikats, eines falsch konfigurierten MX oder einer Downgrade-Attacke unverschlüsselt ankommen
• Sie müssen 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 Ihnen die nötige Transparenz, bevor Sie in den Modus enforce wechseln

Ihre Domain nutzen MTA-STS oder Sie überlegen, es zu aktivieren? Sie haben STARTTLS auf Ihren Mailservern konfiguriert? In beiden Fällen bleibt eine Frage offen: Woher wissen Sie, ob die TLS-Verschlüsselung tatsächlich funktioniert, wenn Ihre 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), Ihnen detaillierte Berichte über TLS-Aushandlungsfehler zu senden, die beim Versuch auftreten, E-Mails an Ihre Domain zuzustellen.

Dieser Leitfaden erklärt Ihnen, was TLS-RPT ist, wie es funktioniert, wie Sie es in wenigen Minuten konfigurieren und wie Sie die erhaltenen Berichte interpretieren. Ob Systemadministrator, DevOps oder verantwortlich für die E-Mail-Infrastruktur - hier finden Sie alles, was Sie brauchen, um TLS-RPT auf Ihrer 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 Ihrem TLS-RPT-Eintrag angegebene Adresse gesendet.

Warum ist TLS-RPT unverzichtbar?

Ohne TLS-RPT sind Sie blind in Bezug auf die Verschlüsselungsqualität Ihrer eingehenden E-Mails:

• Ein TLS-Zertifikat läuft auf Ihrem MX-Server ab → E-Mails kommen weiterhin an (unverschlüsselt, wenn MTA-STS nicht im enforce-Modus ist), aber Sie merken 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. Sie erhalten jeden Tag eine präzise Übersicht: Wie viele TLS-Verbindungen erfolgreich waren, wie viele fehlgeschlagen sind und warum sie fehlgeschlagen sind.

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

Sie veröffentlichen 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 Ihre Domain senden möchte, führt es einen DNS-Lookup auf _smtp._tls.captaindns.com durch, um zu prüfen, ob Sie TLS-RPT konfiguriert haben.

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 Ihrem 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 Sie eine E-Mail von noreply-smtp-tls-reporting@google.com erhalten, 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

Sie können Ihre TLS-RPT-Berichte problemlos an eine andere Domain als Ihre eigene senden, etwa an einen externen Monitoring-Dienst. Anders als DMARC verlangt TLS-RPT keinen Autorisierungseintrag auf der empfangenden Domain: Es genügt, die rua auf die Adresse des Drittanbieters zu richten, und die Berichte werden direkt dorthin gesendet.

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

Das ist eine bewusste Entscheidung der Autoren von RFC 8460. Abschnitt 7 (Security Considerations) verzichtet absichtlich auf den von DMARC verwendeten Delegationsprüfmechanismus, der hier als überflüssig gilt: Das Amplifikationsrisiko ist geringer als bei DMARC. Um Berichte umzuleiten, müsste ein Angreifer zunächst dafür sorgen, dass überhaupt Post an die Zieldomain gesendet wird, um die Berichtserstellung auszulösen, was den Missbrauch unpraktikabel macht.

Nicht mit DMARC verwechseln. Bei DMARC erfordert das Richten einer rua/ruf auf eine Drittanbieter-Domain, dass diese einen Einwilligungseintrag der Form quell-domain._report._dmarc.drittanbieter veröffentlicht. Diesen Mechanismus gibt es bei TLS-RPT nicht: Es gibt keinen _report._tls-Eintrag, der auf der Empfängerseite zu veröffentlichen wäre. Eine Dokumentation, die einen solchen verlangt, überträgt fälschlicherweise die Funktionsweise von DMARC.

Konfigurationstipps

• Dediziertes Postfach: Verwenden Sie eine dedizierte E-Mail-Adresse (z. B. tlsrpt@captaindns.com), damit die Berichte nicht in Ihrem Hauptpostfach untergehen
• Angemessener TTL: Ein TTL von 300 bis 3.600 Sekunden ist für diesen Eintrag geeignet
• HTTPS für hohes Volumen: Wenn Sie viele E-Mails empfangen, 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

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

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

Ohne TLS-RPT ist der Wechsel in den Enforce-Modus ein Blindflug: Sie riskieren, 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 Ihre 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

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

• tlsrpt@captaindns.com (empfohlen)
• Oder verwenden Sie einen HTTPS-Endpoint, wenn Sie ein automatisiertes Verarbeitungssystem haben

Schritt 2: DNS-Eintrag generieren

Nutzen Sie unseren TLS-RPT-Generator, um den passenden Eintrag für Ihre Domain zu erstellen. Sie erhalten einen kopierfertigen Record.

Schritt 3: DNS-Eintrag veröffentlichen

Fügen Sie den TXT-Eintrag in Ihre 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

Nutzen Sie unseren TLS-RPT-Syntaxprüfer, um zu überprüfen, ob Ihr 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

• Stellen Sie sicher, dass der Eintrag unter _smtp._tls.captaindns.com veröffentlicht ist (nicht unter _smtp-tls oder smtp._tls)
• Prüfen Sie die Syntax: v=TLSRPTv1 (nicht v=TLSRPTv2 oder v=TLSRPT1)
• Stellen Sie sicher, dass das empfangende E-Mail-Postfach existiert und gzip-Anhänge akzeptiert
• Prüfen Sie, ob Ihre 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: Ihre 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. Markieren Sie diese E-Mails nicht als Spam.

Empfohlener Aktionsplan

1. TLS-RPT-Eintrag veröffentlichen: 5 Minuten mit dem TLS-RPT-Generator (siehe Schritt 2 oben)
2. MTA-STS im Testing-Modus konfigurieren: Aktivieren Sie die MTA-STS-Richtlinie, damit die TLS-RPT-Berichte Validierungsergebnisse enthalten
3. Berichte 2 Wochen lang analysieren: Identifizieren Sie TLS-Fehler und beheben Sie sie
4. MTA-STS in den Enforce-Modus schalten: Sobald die Berichte sauber sind, aktivieren Sie die Ablehnung fehlgeschlagener TLS-Verbindungen
5. Fortlaufend überwachen: Die täglichen Berichte warnen Sie 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 Ihnen vollständige Transparenz über die Verschlüsselungsqualität Ihrer eingehenden E-Mails.

Wie konfiguriere ich einen TLS-RPT-Eintrag?

Veröffentlichen Sie einen DNS-TXT-Eintrag unter _smtp._tls.captaindns.com mit dem Wert v=TLSRPTv1; rua=mailto:tlsrpt@captaindns.com. Nutzen Sie einen TLS-RPT-Generator, um den Eintrag zu erstellen, und fügen Sie ihn dann in Ihre 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. Ihre Domain hat einen _smtp._tls-Eintrag konfiguriert, und Google sendet Ihnen täglich einen komprimierten JSON-Bericht mit den TLS-Aushandlungsergebnissen für die E-Mails, die Ihnen 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 wissen Sie nicht, ob TLS-Verbindungen fehlschlagen. Das ist besonders kritisch, bevor Sie MTA-STS in den Enforce-Modus schalten, da die Berichte es Ihnen 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. Sie erhalten 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, Sie können 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.

Brauche ich einen eigenen TLS-RPT-Eintrag pro Subdomain?

Ja. Der TLS-RPT-Eintrag wird nicht von der übergeordneten Domain geerbt. Der sendende Server führt einen DNS-Lookup auf _smtp._tls.<Empfänger-Domain> durch (RFC 8460, Abschnitt 3). Wenn Sie E-Mails sowohl unter @captaindns.com als auch unter @extern.captaindns.com empfangen, müssen Sie zwei separate Einträge veröffentlichen: _smtp._tls.captaindns.com und _smtp._tls.extern.captaindns.com. Das ist dasselbe Verhalten wie bei MTA-STS und DMARC.

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üfen Sie jetzt Ihre Konfiguration: Nutzen Sie unseren TLS-RPT-Prüfer, um den _smtp._tls-Eintrag Ihrer Domain in wenigen Sekunden zu analysieren.

---

Verwandte TLS-RPT-Leitfäden

• TLS-RPT für Microsoft 365, Google Workspace und OVHcloud konfigurieren
• TLS-RPT-Berichte analysieren und auswerten

Quellen

• RFC 8460 - SMTP TLS Reporting
• RFC 8461 - SMTP MTA Strict Transport Security (MTA-STS)
• Google SMTP TLS Reporting documentation