Was sagt mir ein TLS-RPT-Report?

Ein täglicher Bericht eines Empfänger-Servers über alle TLS-Versuche zu Ihrem Mailserver: Anzahl erfolgreicher und fehlgeschlagener Sessions, plus pro Failure die Ursache (Cert-Expiry, Cipher-Mismatch, Policy-Fetch-Error etc.).

Welche Failure-Codes sollte ich kennen?

Die häufigsten: starttls-not-supported, certificate-expired, certificate-not-trusted, certificate-host-mismatch, sts-policy-fetch-error, sts-policy-invalid. Jeder zeigt direkt auf eine konkrete Konfigurations-Lücke.

Brauche ich MTA-STS für TLS-RPT?

TLS-RPT funktioniert sinnvoll nur mit aktivem MTA-STS — sonst haben Empfänger keinen Soll-Zustand, mit dem sie Failures vergleichen können. Beide gehören als Paar.

Wie ist der Datenschutz bei TLS-RPT-Reports?

Reports enthalten keine Mail-Inhalte, keine Empfänger-Adressen, sondern nur statistische TLS-Aggregat-Daten und IPs. DSGVO-relevant ist im Wesentlichen die Sender-Server-IP.

Wie lange dauert die Analyse pro Tag?

Bei aktivem MTA-STS in mode=enforce mit sauberer Konfiguration: 5 Minuten zum Überfliegen. Bei Problemen oder testing-Phase: 20–30 Minuten zum gezielten Untersuchen. Mailantis aggregiert die Reports und reduziert das auf 1 Klick.

TLS-RPT verstehen — Failure-Reports richtig lesen

Das Problem: TLS-Fehler bleiben sonst unsichtbar

SMTP versucht standardmäßig, eine TLS-Verbindung zwischen sendendem und empfangendem Mailserver aufzubauen. Wenn das fehlschlägt — abgelaufenes Zertifikat, schwache Cipher, Downgrade-Angriff — fällt der Server üblicherweise auf eine unverschlüsselte Verbindung zurück. Die Mail kommt an, aber im Klartext. Sie würden es nie erfahren.

TLS-RPT (TLS Reporting, RFC 8460) löst das. Sie bitten Empfänger-Server in einem DNS-Record explizit, Ihnen über solche Vorfälle zu berichten. Die Reports kommen täglich als JSON-Dateien per E-Mail — direkt umsetzbar oder via Mailantis aggregiert.

Der DNS-Record

TLS-RPT wird über einen TXT-Record am Subdomain _smtp._tls aktiviert. Beispiel:

_smtp._tls.example.com · TXTv=TLSRPTv1; rua=mailto:[email protected]

Die wichtigsten Felder:

v=TLSRPTv1 — Versionskennung, immer so.
rua=mailto: — die E-Mail-Adresse, an die Reports gesendet werden. Mehrere Adressen kommagetrennt möglich.
rua=https:// — alternativ ein HTTPS-Endpunkt, der die Reports per POST entgegennimmt (selten genutzt).

Wenn Sie Mailantis nutzen, erhalten Sie eine eigene rua-Adresse, an die Sie die Reports einfach durchschleifen — wir aggregieren die JSON-Dateien zu lesbaren Übersichten.

Die JSON-Struktur

Ein TLS-RPT-Report ist eine JSON-Datei, gepackt als application/tlsrpt+gzip. Auspackt sieht ein typischer Report so aus:

Beispiel-Report{
  "organization-name": "Google Inc.",
  "date-range": {
    "start-datetime": "2026-05-07T00:00:00Z",
    "end-datetime":   "2026-05-07T23:59:59Z"
  },
  "contact-info": "[email protected]",
  "report-id": "2026-05-07T00:00:00Z_example.com",
  "policies": [
    {
      "policy": {
        "policy-type":   "sts",
        "policy-string": ["version: STSv1", "mode: enforce", "mx: mail.example.com", "max_age: 86400"],
        "policy-domain": "example.com",
        "mx-host":       ["mail.example.com"]
      },
      "summary": {
        "total-successful-session-count": 1842,
        "total-failure-session-count":      3
      },
      "failure-details": [
        {
          "result-type":            "certificate-expired",
          "sending-mta-ip":         "74.125.24.27",
          "receiving-mx-hostname":  "mail.example.com",
          "failed-session-count":   3
        }
      ]
    }
  ]
}

Die Schlüsselinformationen:

organization-name — wer den Report sendet (z. B. Google, Microsoft, Yahoo).
summary — Anzahl erfolgreicher und fehlgeschlagener TLS-Sessions im Zeitraum.
failure-details — wenn Failures auftraten, hier die Ursache pro Vorfall.

Die wichtigsten Failure-Codes

RFC 8460 definiert eine feste Liste von result-type-Werten. Die häufigsten:

starttls-not-supported — Empfänger-Server bietet kein STARTTLS an. Ihre Mail wird im Klartext zugestellt.
certificate-expired — TLS-Zertifikat des Empfängers ist abgelaufen.
certificate-not-trusted — Zertifikat ist nicht von einer vertrauten CA signiert (Self-Signed o. ä.).
certificate-host-mismatch — Zertifikat passt nicht zum erwarteten Hostname.
validation-failure — generische Validierungsfehler (z. B. Cipher zu schwach).
sts-policy-fetch-error — die MTA-STS-Policy konnte nicht geladen werden.
sts-policy-invalid — die geladene Policy ist syntaktisch defekt.
sts-webpki-invalid — die Policy-URL hat ein ungültiges TLS-Zertifikat.

Wichtig: TLS-RPT funktioniert nur sinnvoll mit aktivem MTA-STS. Ohne MTA-STS-Policy haben Empfänger keinen Soll-Zustand, mit dem sie Failures vergleichen könnten.

Wie Sie Reports auswerten

Drei Auswertungsmuster, die in der Praxis fast immer relevant sind:

Trend pro Tag — bleiben Failures konstant niedrig, oder gibt es plötzliche Spitzen? Spitzen deuten auf neu auftretende Probleme (Cert-Expiry, falsche MX-Konfiguration).
Verteilung nach Empfänger — kommen Failures nur von einem bestimmten Empfänger oder querbeet? Einzelner Empfänger = Konfigurationsproblem dort, breit verteilt = eigenes Problem (Policy oder MX).
result-type-Häufung — wenn 80 % der Failures certificate-expired sind, wissen Sie sofort, wo Sie suchen müssen.

Empfehlungen für die Praxis

TLS-RPT immer parallel zu MTA-STS aktivieren — die beiden ergänzen sich.
Während der MTA-STS-Phase testing ist TLS-RPT besonders wertvoll: Sie sehen Probleme, ohne dass Mails verloren gehen.
Reports nicht in einer normalen Mailbox sammeln — die JSON-Dateien sind nicht für menschliche Augen gedacht. Aggregations-Tool (Mailantis) oder eigenes Parsing-Script ist Pflicht.
Nach drei Wochen Reports ohne Failures: MTA-STS guten Gewissens auf enforce schalten.

TLS-RPT verstehen: Failure-Reports richtig lesen