• Was ist TLS-Berichterstattung? Wie SMTP-TLS-Berichte Fehler bei der E-Mail-Zustellung erkennen

Was ist TLS-Berichterstattung? Wie SMTP-TLS-Berichte Fehler bei der E-Mail-Zustellung erkennen

Blog

Die TLS-Berichterstellung informiert Sie darüber, wenn die SMTP-TLS-Verschlüsselung während der E-Mail-Zustellung fehlschlägt. Erfahren Sie, wie SMTP-TLS-Berichte funktionieren, welche Informationen sie enthalten und wie Sie einen solchen Bericht einrichten.

von Ahona Rudra

Zuletzt aktualisiert:
6 Lesezeit: 2 Minuten
Was ist TLS-Berichterstattung? Wie SMTP-TLS-Berichte Fehler bei der E-Mail-Zustellung erkennen

Die meisten SMTP-TLS-Fehler treten unbemerkt auf. Ein Zertifikat läuft ab, ein Server stellt die Unterstützung für STARTTLS ein oder ein Angreifer erzwingt ein Downgrade – und die E-Mail wird entweder unverschlüsselt versendet oder kommt gar nicht erst an, ohne dass eine Meldung den Grund dafür erklärt. Die TLS-Berichterstattung soll diese Lücke schließen.

SMTP-TLS-Reporting (TLS-RPT), das in RFC 8460 definiert ist, bietet Domain-Inhabern eine standardisierte Möglichkeit, festzustellen, wann die TLS-Verschlüsselung zwischen Mailservern fehlschlägt und warum. Dieser Artikel erläutert, wie SMTP-TLS funktioniert, warum es zu Fehlern kommen kann, wie ein echter TLS-RPT-Bericht Feld für Feld aussieht und welche spezifischen Fehlerarten Ihnen begegnen werden, sobald Sie beginnen, diese Berichte zu lesen.

Was ist SMTP-TLS und warum kommt es zu Fehlern?

Um zu verstehen, warum die TLS-Protokollierung wichtig ist, ist es hilfreich zu wissen, warum SMTP sie überhaupt benötigte.

SMTP wurde nicht für die Verschlüsselung entwickelt

SMTP geht auf das Jahr 1982 zurück. Damals war das E-Mail-Netzwerk noch klein und vertrauenswürdig, und das Protokoll wurde ohne Verschlüsselungsebene entwickelt. Nachrichten wurden standardmäßig im Klartext zwischen den Servern übertragen.

Diese Lücke blieb jahrzehntelang bestehen. Die Verschlüsselung wurde erst später als Option und nicht als zwingende Voraussetzung hinzugefügt, und genau hier beginnt das nächste Problem.

STARTTLS machte die Verschlüsselung optional, nicht garantiert

Mit STARTTLS kann ein sendender Server einen empfangenden Server auffordern, eine Klartextverbindung in eine verschlüsselte Verbindung umzuwandeln. Wenn beide Seiten dies unterstützen, wird die Nachricht verschlüsselt übertragen. Wenn eine der beiden Seiten dies nicht unterstützt oder wenn der Handshake gestört wird, wechselt die Verbindung stillschweigend zurück zu Klartext, und die E-Mail wird dennoch zugestellt.

Genau dieser Fall ist das Kernproblem, das TLS-RPT aufdecken soll. Der SMTP-Standard liefert keinerlei Hinweise darauf, wann eine Nachricht unverschlüsselt versendet wurde – sei es aufgrund einer Fehlkonfiguration oder weil jemand den STARTTLS-Befehl während der Übertragung aktiv entfernt hat.

Was ist TLS-Reporting (TLS-RPT)?

TLS-RPT ist ein in RFC 8460 definierter Berichtsstandard, der es Domain-Inhabern ermöglicht, regelmäßig strukturierte Berichte über TLS-Verbindungsfehler bei E-Mails zu erhalten, die an ihre Domain gesendet werden. Er verhindert zwar nicht, dass solche Fehler auftreten, informiert Sie jedoch darüber, wann, wie oft und warum sie aufgetreten sind, sodass Sie das zugrunde liegende Problem beheben können.

Eine vollständige Übersicht über die Berichtsfelder von RFC 8460 sowie Informationen zur Veröffentlichung eines TLS-RPT-DNS-Eintrags finden Sie in unserer ausführlichen Anleitung zu TLS-RPT.

Inwiefern hängt TLS-RPT mit MTA-STS zusammen?

TLS-RPT und MTA-STS arbeiten als Paar zusammen. MTA-STS ist der Durchsetzungsmechanismus: Es weist sendende Server an, dass E-Mails an Ihre Domain entweder über eine verschlüsselte, authentifizierte Verbindung gesendet werden müssen oder gar nicht. TLS-RPT ist der Transparenzmechanismus: Es meldet zurück, was passiert ist, wenn diese verschlüsselte Verbindung nicht hergestellt werden konnte. Das eine legt die Regel fest, das andere teilt Ihnen mit, wann die Regel ausgelöst wird.

Ausführliche Anweisungen zur Konfiguration von MTA-STS für Ihre Domain finden Sie in unserem Leitfaden zur MTA-STS-Implementierung.

So funktioniert die SMTP-TLS-Protokollierung – Schritt für Schritt

  1. Der Domaininhaber veröffentlicht einen TLS-RPT-DNS-Eintrag, der den sendenden Mail-Servern mitteilt, wohin Fehlerberichte gesendet werden sollen.
  2. Ein sendender Server versucht, E-Mails über TLS zu übermitteln, in der Regel über STARTTLS.
  3. Sollte dieser Versuch fehlschlagen, protokolliert der sendende Server den Grund für den Fehler.
  4. Etwa einmal alle 24 Stunden fasst der sendende Server diese Ergebnisse in einem JSON-Bericht zusammen und sendet ihn – in der Regel per E-Mail oder HTTPS-POST – an die Adresse, die im TLS-RPT-Eintrag der Domain angegeben ist.
  5. Der Domaininhaber öffnet den Bericht und sucht nach Mustern: Welche Server weisen Fehler auf, wie oft und warum?

Ein Blick in einen echten TLS-RPT-Bericht

TLS-RPT-Berichte werden im JSON-Format übermittelt, das nicht gerade für Menschen lesbar ist. Nachfolgend finden Sie ein gekürztes, realistisches Beispiel auf Basis des RFC-8460-Formats mit einer Zusammenfassung einer erfolgreichen und einer fehlgeschlagenen Sitzung, gefolgt von einer Erläuterung der einzelnen Felder in leicht verständlicher Sprache.

JSON
{
  "organization-name": "Google Inc.",
  "date-range": {
    "start-datetime": "2026-07-01T00:00:00Z",
    "end-datetime": "2026-07-01T23:59:59Z"
  },
  "contact-info": "[email protected]",
  "report-id": "[email protected]",
  "policies": [
    {
      "policy": {
        "policy-type": "sts",
        "policy-string": [
          "version: STSv1",
          "mode: enforce",
          "mx: mail.yourdomain.com",
          "max_age: 604800"
        ],
        "policy-domain": "yourdomain.com"
      },
      "summary": {
        "total-successful-session-count": 4821,
        "total-failure-session-count": 3
      },
      "failure-details": [
        {
          "result-type": "certificate-expired",
          "sending-mta-ip": "209.85.220.41",
          "receiving-mx-hostname": "mail.yourdomain.com",
          "receiving-mx-helo": "mail.yourdomain.com",
          "receiving-ip": "203.0.113.45",
          "failed-session-count": 2,
          "additional-information": "https://support.google.com/mail/answer/tls-rpt-cert-expired"
        },
        {
          "result-type": "starttls-not-supported",
          "sending-mta-ip": "209.85.220.41",
          "receiving-mx-hostname": "mail2.yourdomain.com",
          "receiving-ip": "203.0.113.46",
          "failed-session-count": 1
        }
      }
    }
  ]
}

Was die einzelnen Felder tatsächlich bedeuten

  • organization-name: Wer hat die Meldung gesendet? In der Regel ein großer E-Mail-Anbieter wie Google, Microsoft oder Yahoo.
  • Zeitraum: Der Zeitraum, den der Bericht abdeckt. Die meisten Absender erstellen ihre Berichte auf Basis eines rollierenden 24-Stunden-Zeitraums.
  • Kontaktdaten / Berichts-ID: Angaben dazu, wie der Absender zu erreichen ist, sowie eine eindeutige ID für diesen konkreten Bericht. Nützlich, wenn Sie in einem Support-Ticket auf den Bericht verweisen müssen.
  • policy-type / policy-string: Die MTA-STS- (oder DANE-)Richtlinie, die der sendende Server zu diesem Zeitpunkt für Ihre Domain gesehen hat, genau so, wie sie abgerufen wurde. So können Sie überprüfen, ob Ihre veröffentlichte Richtlinie mit dem übereinstimmt, was die Absender tatsächlich erhalten.
  • Anzahl der erfolgreichen Sitzungen / Anzahl der fehlgeschlagenen Sitzungen: Die Kernzahl. In diesem Beispiel waren 4.821 von 4.824 Zustellversuchen erfolgreich und 3 schlugen fehl.
  • failure-details: Ein Eintrag pro Fehlertyp mit einer Anzahl. Dies ist der Teil, auf den man reagieren sollte:
    – certificate-expired: Bei zwei der fehlgeschlagenen Sitzungen war das TLS-Zertifikat abgelaufen. Behebung: Das Zertifikat erneuern und neu installieren.
    – starttls-not-supported: Der empfangende Server (mail2.yourdomain.com) hat bei einer Sitzung überhaupt nicht auf STARTTLS reagiert. Behebung: Überprüfen Sie die TLS-Konfiguration des Servers, da diese möglicherweise fehlt oder falsch konfiguriert ist.

Häufige Arten von TLS-Fehlern, die in Berichten auftreten

TLS-RPT-Berichte verwenden einen festen Satz von Werten für die Ergebnisarten. Im Folgenden sind die am häufigsten vorkommenden Werte aufgeführt, zusammen mit ihrer jeweiligen Bedeutung und den entsprechenden Maßnahmen.

Zertifikat abgelaufen

Das TLS-Zertifikat des empfangenden Servers war bereits abgelaufen. Erneuern Sie das Zertifikat, bevor es abläuft, und richten Sie rechtzeitig vor dem nächsten Ablauftermin eine Erinnerung ein.

Nicht übereinstimmender Zertifikatsname

Das vorgelegte Zertifikat stimmt nicht mit dem Hostnamen überein, den der sendende Server erwartet hat. Dies deutet in der Regel auf ein falsch konfiguriertes Zertifikat oder einen DNS-Eintrag hin, der auf den falschen Host verweist.

STARTTLS wird nicht unterstützt

Der empfangende Server hat überhaupt nicht auf den STARTTLS-Befehl reagiert. Überprüfen Sie, ob TLS auf diesem Mailserver ordnungsgemäß aktiviert ist, und vergewissern Sie sich, dass die Serversoftware dies tatsächlich unterstützt.

Fehler beim Abrufen der MTA-STS-Richtlinie

Der sendende Server konnte Ihre MTA-STS-Richtliniendatei nicht über HTTPS abrufen. Stellen Sie sicher, dass die Richtliniendatei erreichbar ist, das richtige Format aufweist und mit einem gültigen Zertifikat bereitgestellt wird.

TLS-Version zu alt

Bei der Verbindung wurde versucht, eine TLS-Version auszuhandeln, die der sendende Server als veraltet oder unsicher einstuft. Aktualisieren Sie die TLS-Konfiguration Ihres Mail-Servers, um veraltete Protokollversionen zu deaktivieren. Speziell zu Problemen bei der Zertifikatsvalidierung lesen Sie bitte unseren Leitfaden zu DANE.

Warum die SMTP-TLS-Berichterstattung wichtig ist

Die SMTP-TLS-Berichterstattung bietet aus einer Vielzahl von Gründen Vorteile. Im Folgenden sind einige davon aufgeführt:

Sicherheit: Downgrade-Angriffe erkennen

TLS-RPT deckt Fälle auf, in denen eine Verbindung in einen unverschlüsselten Kanal umgeleitet wurde – genau das Muster, das hinter einem MITM-Downgrade-Angriff steckt. Ohne eine entsprechende Meldung kann eine solche Abhöraktion unbegrenzt andauern, ohne dass jemand davon erfährt.

Sichtbarkeit: Blinde Flecken beseitigen

Ohne TLS-RPT gibt es keine zuverlässige Möglichkeit, festzustellen, warum E-Mails an Ihre Domain fehlgeschlagen sind oder ob sie unverschlüsselt zugestellt wurden. Die Berichte zeigen genau, wo und warum eine TLS-Verbindung unterbrochen wurde, sodass Sie nicht mehr im Unklaren bleiben.

Effizienz: Schnellere Fehlersuche

Das Durchsehen von Serverprotokollen zur Ermittlung der Ursache eines Übertragungsproblems ist zeitaufwendig. TLS-RPT-Berichte geben direkt Aufschluss über den betroffenen Server, die Art des Fehlers und die Häufigkeit des Auftretens, wodurch sich die Fehlerbehebung von Tagen auf Minuten verkürzt.

Fazit: Wie PowerDMARC die TLS-Berichterstattung vereinfacht

TLS-RPT-Berichte liegen als JSON-Rohdateien vor, und das manuelle Durchsehen dieser Dateien aus verschiedenen Absenderquellen wird schnell lästig. PowerDMARC wandelt diese Berichte automatisch in übersichtliche Dashboards um, die nach Ergebnistyp und Absenderquelle zusammengefasst sind, sodass Sie erkennen können, was wo schiefläuft, ohne auch nur eine einzige JSON-Datei öffnen zu müssen.

Wir unterstützen Domaininhaber:

  • Wandelt Roh-JSON automatisch in lesbare Dashboards um, ohne dass eine manuelle Dekodierung der TLS-RPT-Berichtsdateien erforderlich ist.
  • Filtern Sie nach zwei Berichtsansichten: nach Absender (Richtlinienmodus, Anzahl der Sitzungen, Gesamtzahl der Zustellungen) und nach Ergebnis (erfolgreiche Sitzungen oben, Fehlschläge unten).
  • Es ist nicht möglich, eine fehlgeschlagene Sitzung im Detail anzuzeigen und den Hostnamen, die IP-Adresse, die Anzahl der Fehler sowie den Grund des empfangenden Servers einzusehen, sodass die Ursache des Problems auf einen Blick erkennbar ist.
  • Laden Sie JSON-, ZIP- oder GZ-Dateien hoch – dank des Upload-Verlaufs können Sie frühere Berichte jederzeit erneut aufrufen.
  • Erstellen Sie automatisch die für den Berichtsfluss erforderlichen CNAME-Einträge und überprüfen Sie deren Gültigkeit – dank der DNS-Einrichtung mit nur einem Klick – sowie eine konfigurierbare Adresse, an die die zusammengefassten Berichte gesendet werden sollen.
  • Exportieren Sie JSON-Rohdateien, wenn Sie die Originaldatei für ein Ticket oder zur eingehenderen Analyse benötigen – mit detaillierten Berechtigungen, die festlegen, wer innerhalb des Kontos Berichte hochladen darf.

Starten Sie eine kostenlose Testversion oder vereinbaren Sie eine Demo, um die Funktion anhand der Daten Ihrer eigenen Domain zu testen.

Häufig gestellte Fragen

1. Wozu dient die TLS-Berichterstattung?

TLS-Berichte dienen dazu, Fehler bei der Zustellung verschlüsselter E-Mails zu erkennen und zu diagnostizieren, darunter abgelaufene Zertifikate, falsch konfigurierte Server und Downgrade-Angriffe. Dazu werden regelmäßig Berichte erstellt, aus denen hervorgeht, was schiefgelaufen ist und warum.

2. Ist SMTP-TLS-Reporting dasselbe wie TLS-RPT?

Ja. „SMTP-TLS-Reporting“ und „TLS-RPT“ beziehen sich auf denselben Standard (RFC 8460). TLS-RPT ist die Kurzbezeichnung für das Protokoll.

3. Wie richte ich die TLS-Berichterstellung für meine Domain ein?

Um dies für Ihre Domain einzurichten, veröffentlichen Sie einfach einen TLS-RPT-DNS-Eintrag, in dem angegeben ist, wohin die Berichte gesendet werden sollen. Sie können einen solchen Eintrag mit unserem TLS-RPT-Eintragsgenerator erstellen und mit unserem TLS-RPT-Checker überprüfen, ob er bereits aktiv ist.

4. Was passiert, wenn ich TLS-RPT nicht aktiviere?

Wenn Sie TLS-RPT nicht aktivieren, versuchen die Mailserver zwar weiterhin, eine TLS-Verschlüsselung herzustellen, Sie erhalten jedoch keinen Einblick in eventuelle Fehler. Downgrade-Angriffe, abgelaufene Zertifikate und falsch konfigurierte Server können so auf unbestimmte Zeit unbemerkt bleiben.

5. Funktioniert TLS-RPT auch ohne MTA-STS?

Ja, TLS-RPT kann TLS-Fehler eigenständig melden. Am nützlichsten ist es jedoch in Kombination mit MTA-STS, da MTA-STS die verschlüsselte Übermittlung erzwingt und TLS-RPT darüber berichtet, was passiert ist, als diese Erzwingung in Kraft trat.

6. Wie oft werden SMTP-TLS-Berichte versendet?

Die meisten Absender erstellen und versenden Berichte etwa einmal alle 24 Stunden, wobei das genaue Intervall je nach Anbieter variieren kann.

Neueste Beiträge von Ahona Rudra (alle anzeigen)
Zuletzt aktualisiert:
Die besten DMARC-MCP-Server im Jahr 2026: Verbinden Sie KI mit Ihren E-Mail-Authentifizierungsdaten...