TLS-RPT-Berichte analysieren und nutzen: Probleme erkennen, bevor sie Ihre E-Mails beeinträchtigen

Von CaptainDNS
Veröffentlicht am 14. Februar 2026

Aktualisiert am 4. März 2026

TLS-RPT-Bericht analysieren: JSON-Struktur und TLS-Fehlertypen bei E-Mails

TL;DR

Ein TLS-RPT-Bericht ist eine komprimierte JSON-Datei (gzip), die täglich von den sendenden Servern verschickt wird: Sie beschreibt jeden fehlgeschlagenen TLS-Handshake auf Ihrer Domain
Die 3 häufigsten Fehler sind certificate-host-mismatch, starttls-not-supported und sts-policy-fetch-error, jeweils mit einer spezifischen Ursache und Korrektur
Analysieren Sie das Feld failure-details, um den betroffenen MX-Server, die IP des Absenders und den genauen Fehlertyp zu identifizieren
Nutzen Sie den TLS-RPT-Syntaxprüfer, um Ihre Konfiguration vor und nach der Korrektur zu überprüfen

Sie haben TLS-RPT auf Ihrer Domain konfiguriert und die Berichte beginnen einzutreffen. Komprimierte JSON-Dateien, gesendet von Google, Microsoft, Yahoo und anderen Anbietern. Sie öffnen sie und finden strukturierte Datenblöcke mit Feldern wie policy-type, result-type, failed-session-count. Was bedeuten diese Daten? Wie machen Sie daraus konkrete Maßnahmen?

Das ist der am schlechtesten dokumentierte Teil von TLS-RPT. Die RFC 8460 definiert das Format, sagt Ihnen aber nicht, wie Sie die Ergebnisse im operativen Kontext interpretieren sollen. Dieser Leitfaden schließt diese Lücke: Sie lernen, die JSON-Struktur eines Berichts zu lesen, jeden Fehlertyp zu identifizieren und einem Diagnose-Workflow zu folgen, um Probleme zu beheben, bevor sie die Zustellung Ihrer E-Mails beeinträchtigen.

Wenn Sie TLS-RPT noch nicht konfiguriert haben, beginnen Sie mit dem vollständigen TLS-RPT-Leitfaden, der die Einrichtung von A bis Z abdeckt (siehe den Abschnitt Verwandte Leitfäden am Ende des Artikels). Wenn Sie die spezifische Konfiguration für Ihren Anbieter suchen (Microsoft 365, Google Workspace, OVHcloud), finden Sie den Konfigurationsleitfaden ebenfalls am Ende des Artikels.

Aufbau eines TLS-RPT-Berichts

Ein TLS-RPT-Bericht ist eine JSON-Datei, die als komprimierter Anhang (.json.gz) verschickt wird. Jeder Anbieter, der Ihnen E-Mails sendet, erstellt seinen eigenen Bericht, einmal pro Tag. Hier ist die vollständige Struktur eines typischen Berichts:

{
  "organization-name": "Google Inc.",
  "date-range": {
    "start-datetime": "2026-02-12T00:00:00Z",
    "end-datetime": "2026-02-13T00:00:00Z"
  },
  "contact-info": "smtp-tls-reporting@google.com",
  "report-id": "2026-02-12T00: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",
        "mx-host": ["mail.captaindns.com"]
      },
      "summary": {
        "total-successful-session-count": 1842,
        "total-failure-session-count": 3
      },
      "failure-details": [
        {
          "result-type": "certificate-host-mismatch",
          "sending-mta-ip": "209.85.220.41",
          "receiving-mx-hostname": "mail.captaindns.com",
          "receiving-ip": "203.0.113.10",
          "failed-session-count": 3
        }
      ]
    }
  ]
}

Die 4 Blöcke des Berichts

Jeder Bericht enthält genau 4 Informationsebenen:

1. Bericht-Header: Wer hat ihn gesendet und wann:

organization-name: der sendende Anbieter (Google, Microsoft, Yahoo)
date-range: der abgedeckte Zeitraum (immer 24 Stunden)
report-id: eindeutige Kennung des Berichts

2. Block policy: Welche TLS-Richtlinie wurde ausgewertet:

policy-type: der Typ der Richtlinie (sts für MTA-STS, tlsa für DANE, no-policy-found wenn keine vorhanden)
policy-string: der Inhalt der angewandten MTA-STS- oder DANE-Richtlinie
policy-domain: Ihre Domain
mx-host: die betroffenen MX-Server

3. Block summary: die Zusammenfassung in Zahlen:

total-successful-session-count: erfolgreiche TLS-Verbindungen
total-failure-session-count: fehlgeschlagene TLS-Verbindungen

4. Block failure-details: die Details jedes Fehlers (der wichtigste Teil):

result-type: der genaue Fehlertyp
sending-mta-ip: die IP des Servers, der versucht hat, Ihnen die E-Mail zu senden
receiving-mx-hostname: Ihr betroffener MX-Server
receiving-ip: die IP Ihres MX-Servers
failed-session-count: Anzahl der Fehler dieses Typs

Aufbau eines TLS-RPT-Berichts: die 4 JSON-Datenblöcke (Header, Richtlinie, Zusammenfassung, Fehlerdetails)

Wie empfangen und entpacken Sie die Berichte?

Die Berichte treffen per E-Mail ein, von Adressen wie noreply-smtp-tls-reporting@google.com. Die angehängte Datei hat folgendes Namensformat:

google.com!captaindns.com!2026-02-12T00:00:00Z!2026-02-13T00:00:00Z.json.gz

Zum Entpacken:

# Linux / macOS
gunzip google.com\!captaindns.com\!2026-02-12T00:00:00Z\!2026-02-13T00:00:00Z.json.gz

# Oder direkt anzeigen, ohne zu extrahieren
zcat rapport.json.gz | python3 -m json.tool

Wenn Sie die Berichte per HTTPS empfangen (Endpoint https://), erhält der Server das komprimierte JSON direkt per POST mit dem Content-Type application/tlsrpt+gzip.

Die TLS-RPT-Fehlertypen (result-type)

Das Feld result-type in failure-details identifiziert genau, was fehlgeschlagen ist. Die RFC 8460 definiert 11 Fehlertypen in 3 Kategorien:

Fehler beim TLS-Zertifikat

result-type	Ursache	Korrekturmaßnahme
`certificate-host-mismatch`	Das TLS-Zertifikat des MX-Servers stimmt nicht mit dem Hostnamen überein	Erneuern Sie das Zertifikat mit dem korrekten CN/SAN für Ihren MX
`certificate-expired`	Das TLS-Zertifikat ist abgelaufen	Erneuern Sie das Zertifikat sofort
`certificate-not-trusted`	Das Zertifikat ist nicht von einer anerkannten CA signiert	Verwenden Sie ein von einer öffentlichen CA signiertes Zertifikat (Let's Encrypt, DigiCert)

Fehler bei STARTTLS

result-type	Ursache	Korrekturmaßnahme
`starttls-not-supported`	Der MX-Server bietet kein STARTTLS an	Aktivieren Sie STARTTLS in der Konfiguration Ihres Mailservers
`validation-failure`	Allgemeiner TLS-Validierungsfehler	Überprüfen Sie die vollständige Zertifikatskette und die TLS-Konfiguration

Fehler bei MTA-STS- und DANE-Richtlinien

result-type	Ursache	Korrekturmaßnahme
`sts-policy-fetch-error`	Die MTA-STS-Richtlinie konnte nicht abgerufen werden	Stellen Sie sicher, dass `https://mta-sts.captaindns.com/.well-known/mta-sts.txt` erreichbar ist
`sts-policy-invalid`	Die MTA-STS-Richtlinie ist fehlerhaft formatiert	Korrigieren Sie die Syntax der Datei `mta-sts.txt`
`sts-webpki-invalid`	Das HTTPS-Zertifikat des MTA-STS-Servers ist ungültig	Erneuern Sie das Zertifikat der Subdomain `mta-sts.captaindns.com`
`tlsa-invalid`	Der DANE-TLSA-Eintrag ist ungültig	Korrigieren Sie den TLSA-Eintrag in Ihrer DNS-Zone
`dnssec-invalid`	Die DNSSEC-Validierung ist fehlgeschlagen	Korrigieren Sie Ihre DNSSEC-Kette
`dane-required`	DANE ist erforderlich, aber der Server unterstützt es nicht	Setzen Sie DANE um oder entfernen Sie die TLSA-Einträge

Die 3 häufigsten Fehler im Detail

certificate-host-mismatch

Das ist der häufigste Fehler. Er tritt auf, wenn das TLS-Zertifikat Ihres MX-Servers den erwarteten Hostnamen nicht in seinem CN-Feld (Common Name) oder SAN-Feld (Subject Alternative Name) enthält.

Typisches Szenario: Ihr MX ist mail.captaindns.com, aber das Zertifikat ist für *.anderedomain.com ausgestellt (Shared Hosting) oder für captaindns.com ohne die Subdomain mail.

Diagnose:

# Zertifikat Ihres MX überprüfen
openssl s_client -connect mail.captaindns.com:25 -starttls smtp \
  -servername mail.captaindns.com 2>/dev/null | \
  openssl x509 -noout -subject -ext subjectAltName

Korrektur: Besorgen Sie sich ein Zertifikat, das den exakten FQDN Ihres MX im SAN enthält. Mit Let's Encrypt:

certbot certonly --standalone -d mail.captaindns.com

starttls-not-supported

Der MX-Server bietet den STARTTLS-Befehl nicht in seinem SMTP-Banner an. E-Mails werden im Klartext übertragen.

Diagnose:

# Prüfen, ob STARTTLS angekündigt wird
openssl s_client -connect mail.captaindns.com:25 -starttls smtp 2>&1 | head -5
# Wenn "CONNECTED" erscheint, funktioniert STARTTLS
# Bei einem Fehler wird STARTTLS nicht unterstützt

Korrektur: Aktivieren Sie STARTTLS in Ihrem Mailserver. Für Postfix:

# /etc/postfix/main.cf
smtpd_tls_cert_file = /etc/letsencrypt/live/mail.captaindns.com/fullchain.pem
smtpd_tls_key_file = /etc/letsencrypt/live/mail.captaindns.com/privkey.pem
smtpd_tls_security_level = may

sts-policy-fetch-error

Der sendende Server konnte Ihre MTA-STS-Richtlinie unter der URL https://mta-sts.captaindns.com/.well-known/mta-sts.txt nicht abrufen.

Häufige Ursachen:

Die Subdomain mta-sts.captaindns.com hat keinen DNS-A/AAAA-Eintrag
Der HTTPS-Server antwortet nicht oder gibt einen 404/500-Fehler zurück
Das HTTPS-Zertifikat der Subdomain mta-sts ist abgelaufen

Diagnose:

# Zugriff auf die Richtlinie testen
curl -v https://mta-sts.captaindns.com/.well-known/mta-sts.txt

Für eine vollständige Diagnose Ihrer MTA-STS-Probleme lesen Sie unseren MTA-STS-Troubleshooting-Leitfaden.

Schritt-für-Schritt-Diagnose: vom Fehler zur Korrektur

Wenn Sie einen Bericht mit Fehlern erhalten, folgen Sie diesem 5-Schritte-Workflow:

Schritt 1: Schweregrad einschätzen

Sehen Sie sich das Verhältnis von Fehlern zu Erfolgen im Block summary an:

total-successful-session-count: 1842
total-failure-session-count: 3

Ein Verhältnis unter 1 % Fehlern ist normal: Es kann sich um Versuche von schlecht konfigurierten Servern auf Absenderseite handeln. Ab 5 % besteht ein Problem, das untersucht werden sollte.

Schritt 2: result-type identifizieren

Das Feld result-type in failure-details sagt Ihnen genau, was fehlgeschlagen ist. Nutzen Sie die Tabelle der 11 Fehlertypen weiter oben als Referenz.

Schritt 3: Betroffenen MX-Server identifizieren

Das Feld receiving-mx-hostname zeigt Ihnen, welcher Server betroffen ist. Wenn Sie mehrere MX-Server haben (primär + Backup), kann nur einer falsch konfiguriert sein.

Schritt 4: Mit den CaptainDNS-Tools überprüfen

Nutzen Sie den TLS-RPT-Checker von CaptainDNS, um zu bestätigen, dass Ihr DNS-Eintrag korrekt ist und die zugehörigen Richtlinien (MTA-STS, DANE) erkannt werden.

Schritt 5: Korrigieren und überwachen

Wenden Sie die zum result-type passende Korrektur an und überwachen Sie die Berichte der nächsten 48 bis 72 Stunden, um zu bestätigen, dass der Fehler verschwindet.

TLS-RPT-Diagnose-Workflow: vom Empfang des Berichts bis zur Fehlerbehebung

Praxisbeispiele: einen echten Bericht analysieren

Fall 1: Sauberer Bericht (keine Fehler)

{
  "organization-name": "Google Inc.",
  "date-range": {
    "start-datetime": "2026-02-12T00:00:00Z",
    "end-datetime": "2026-02-13T00:00:00Z"
  },
  "report-id": "2026-02-12_captaindns.com",
  "policies": [
    {
      "policy": {
        "policy-type": "sts",
        "policy-domain": "captaindns.com"
      },
      "summary": {
        "total-successful-session-count": 2156,
        "total-failure-session-count": 0
      },
      "failure-details": []
    }
  ]
}

Interpretation: 2.156 erfolgreiche TLS-Verbindungen, null Fehler. Ihre Konfiguration funktioniert einwandfrei. Dieser Bericht bestätigt, dass:

Ihr TLS-Zertifikat gültig ist und zum MX-Hostnamen passt
STARTTLS auf Ihrem Server aktiv ist
Ihre MTA-STS-Richtlinie erreichbar ist und eingehalten wird

Fall 2: Zertifikatsfehler auf einem sekundären MX

{
  "organization-name": "Microsoft Corporation",
  "date-range": {
    "start-datetime": "2026-02-12T00:00:00Z",
    "end-datetime": "2026-02-13T00:00:00Z"
  },
  "policies": [
    {
      "policy": {
        "policy-type": "sts",
        "policy-domain": "captaindns.com",
        "mx-host": ["mail.captaindns.com", "mail2.captaindns.com"]
      },
      "summary": {
        "total-successful-session-count": 890,
        "total-failure-session-count": 47
      },
      "failure-details": [
        {
          "result-type": "certificate-host-mismatch",
          "sending-mta-ip": "40.107.22.89",
          "receiving-mx-hostname": "mail2.captaindns.com",
          "receiving-ip": "198.51.100.20",
          "failed-session-count": 47
        }
      ]
    }
  ]
}

Interpretation: 47 Fehler auf mail2.captaindns.com (sekundärer MX) mit dem Fehler certificate-host-mismatch. Der primäre MX (mail.captaindns.com) funktioniert korrekt. Das Zertifikat des sekundären MX enthält mail2.captaindns.com nicht in seinem SAN.

Maßnahme: Erneuern Sie das Zertifikat von mail2.captaindns.com und fügen Sie diesen Hostnamen im SAN hinzu.

Fall 3: MTA-STS-Richtlinie nicht erreichbar

{
  "policies": [
    {
      "policy": {
        "policy-type": "sts",
        "policy-domain": "captaindns.com"
      },
      "summary": {
        "total-successful-session-count": 0,
        "total-failure-session-count": 156
      },
      "failure-details": [
        {
          "result-type": "sts-policy-fetch-error",
          "failed-session-count": 156
        }
      ]
    }
  ]
}

Interpretation: 156 Fehler, alle vom Typ sts-policy-fetch-error. Der sendende Server hat Ihren MTA-STS-Eintrag (_mta-sts.captaindns.com) erkannt, konnte die Richtlinie aber nicht unter https://mta-sts.captaindns.com/.well-known/mta-sts.txt herunterladen.

Maßnahme: Stellen Sie sicher, dass die Subdomain mta-sts.captaindns.com auf einen funktionierenden HTTPS-Server mit gültigem Zertifikat verweist.

Berichtsanalyse automatisieren

Geringes Volumen: dediziertes Postfach

Für eine Domain mit weniger als 1.000 E-Mails pro Tag reicht eine dedizierte Adresse:

_smtp._tls.captaindns.com. TXT "v=TLSRPTv1; rua=mailto:tls-reports@captaindns.com"

Erstellen Sie einen Filter in Ihrem Mail-Client, um die Berichte automatisch zu sortieren. Prüfen Sie sie einmal pro Woche und achten Sie auf total-failure-session-count-Werte größer als null.

Hohes Volumen: HTTPS-Endpoint

Für Domains mit hohem Mailaufkommen konfigurieren Sie einen HTTPS-Endpoint, der die Berichte per POST empfängt:

_smtp._tls.captaindns.com. TXT "v=TLSRPTv1; rua=https://reports.captaindns.com/tls-rpt"

Der Endpoint empfängt das gzip-komprimierte JSON mit dem Content-Type application/tlsrpt+gzip. Sie können die Berichte automatisch parsen und Alerts auslösen, wenn total-failure-session-count einen Schwellenwert überschreitet.

Konfiguration mit CaptainDNS überprüfen

Bevor Sie Ihre TLS- oder MTA-STS-Konfiguration ändern, nutzen Sie den TLS-RPT-Generator, um einen korrekten Eintrag zu erstellen. Nach der Korrektur überprüfen Sie mit dem TLS-RPT-Checker, dass alles stimmt.

Empfohlener Aktionsplan

Entpacken Sie und lesen Sie Ihren ersten Bericht: Öffnen Sie eine .json.gz-Datei von Google oder Microsoft und identifizieren Sie die 4 Blöcke (Header, policy, summary, failure-details)
Prüfen Sie das Verhältnis Fehler/Erfolge: Eine Fehlerquote über 5 % erfordert eine Untersuchung
Identifizieren Sie den result-type: Nutzen Sie die Tabelle der 11 Fehlertypen, um die genaue Ursache zu verstehen
Beheben Sie das Problem auf dem betroffenen Server: Zertifikat, STARTTLS oder MTA-STS-Richtlinie je nach Fehlertyp
Überwachen Sie die folgenden Berichte: Bestätigen Sie das Verschwinden des Fehlers innerhalb von 48 bis 72 Stunden nach der Korrektur

FAQ

Was ist ein TLS-RPT-Bericht und was enthält er?

Ein TLS-RPT-Bericht ist eine komprimierte JSON-Datei (gzip), die täglich von den Mailservern gesendet wird, die Ihnen E-Mails schicken. Er enthält den Namen der sendenden Organisation, den abgedeckten Zeitraum (24 Stunden), die ausgewertete TLS-Richtlinie (MTA-STS oder DANE), die Anzahl erfolgreicher und fehlgeschlagener TLS-Verbindungen und die Details jedes Fehlertyps mit den betroffenen IPs und Hostnamen.

Wie liest man die JSON-Struktur eines TLS-RPT-Berichts?

Der JSON-Bericht besteht aus 4 Ebenen: dem Header (organization-name, date-range), dem Block policy (policy-type, policy-string), dem Block summary (Erfolgs-/Fehlerzähler) und dem Block failure-details (result-type, sending-mta-ip, receiving-mx-hostname). Entpacken Sie die .json.gz-Datei mit gunzip oder zcat und formatieren Sie sie mit python3 -m json.tool für eine lesbare Ausgabe.

Welche Fehlertypen (result-type) gibt es in einem TLS-RPT-Bericht?

Die RFC 8460 definiert 11 Fehlertypen in 3 Kategorien: Zertifikatsfehler (certificate-host-mismatch, certificate-expired, certificate-not-trusted), STARTTLS-Fehler (starttls-not-supported, validation-failure) und Richtlinienfehler (sts-policy-fetch-error, sts-policy-invalid, sts-webpki-invalid, tlsa-invalid, dnssec-invalid, dane-required). Jeder Typ gibt genau an, was beim TLS-Handshake fehlgeschlagen ist.

Was bedeutet certificate-host-mismatch in einem TLS-RPT-Bericht?

Der Fehler certificate-host-mismatch bedeutet, dass das TLS-Zertifikat Ihres MX-Servers nicht zum erwarteten Hostnamen passt. Zum Beispiel, wenn Ihr MX mail.captaindns.com ist, das Zertifikat aber für eine andere Domain ausgestellt wurde. Korrigieren Sie dies, indem Sie ein Zertifikat besorgen, dessen SAN (Subject Alternative Name) den exakten FQDN Ihres MX enthält.

Wie behebt man den Fehler starttls-not-supported?

Der Fehler starttls-not-supported bedeutet, dass Ihr MX-Server den STARTTLS-Befehl nicht anbietet und E-Mails deshalb im Klartext übertragen werden. Aktivieren Sie STARTTLS in der Konfiguration Ihres Servers: Für Postfix fügen Sie smtpd_tls_security_level = may mit den Pfaden zu Ihrem Zertifikat und privaten Schlüssel in main.cf hinzu. Überprüfen Sie anschließend mit openssl s_client -connect mail.captaindns.com:25 -starttls smtp.

Wie oft werden TLS-RPT-Berichte gesendet?

TLS-RPT-Berichte werden einmal pro Tag gesendet (Zeitraum von 24 Stunden). Jeder Anbieter, der Ihnen E-Mails schickt (Google, Microsoft, Yahoo usw.), erstellt seinen eigenen Bericht unabhängig. Sie erhalten also potenziell mehrere Berichte pro Tag, einen pro sendendem Anbieter. Die ersten Berichte treffen 24 bis 48 Stunden nach der Veröffentlichung Ihres TLS-RPT-Eintrags ein.

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

DMARC-Berichte überwachen die E-Mail-Authentifizierung (SPF, DKIM, Domain-Alignment), während TLS-RPT-Berichte die Transportverschlüsselung überwachen (TLS-Handshake zwischen Servern). DMARC prüft, wer die E-Mail sendet, TLS-RPT prüft, wie sie transportiert wird. DMARC-Berichte sind im XML-Format, TLS-RPT-Berichte im JSON-Format. Beide ergänzen sich für die Absicherung Ihrer Domain.

Glossar

TLS-RPT: SMTP TLS Reporting (RFC 8460), Mechanismus für tägliche Berichte über fehlgeschlagene TLS-Handshakes bei der E-Mail-Zustellung.
result-type: JSON-Feld in failure-details, das den genauen TLS-Fehlertyp identifiziert (certificate-host-mismatch, starttls-not-supported usw.).
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), Alternative zu MTA-STS, die DNSSEC und TLSA-Einträge nutzt.
STARTTLS: SMTP-Erweiterung, die das Verschlüsseln einer zunächst unverschlüsselten Verbindung ermöglicht. Standardmäßig opportunistisch.
SAN: Subject Alternative Name, Feld im TLS-Zertifikat, das die gültigen Hostnamen auflistet.
policy-type: JSON-Feld, das den Typ der ausgewerteten Richtlinie angibt (sts, tlsa oder no-policy-found).

Überprüfen Sie Ihre Konfiguration jetzt: Nutzen Sie unseren TLS-RPT-Checker, um zu kontrollieren, dass Ihr _smtp._tls-Eintrag korrekt ist und die zugehörigen Richtlinien erkannt werden.

TLS-RPT-Berichte analysieren und nutzen: Probleme erkennen, bevor sie Ihre E-Mails beeinträchtigen

Aufbau eines TLS-RPT-Berichts

Die 4 Blöcke des Berichts

Wie empfangen und entpacken Sie die Berichte?

Die TLS-RPT-Fehlertypen (result-type)

Fehler beim TLS-Zertifikat

Fehler bei STARTTLS

Fehler bei MTA-STS- und DANE-Richtlinien

Die 3 häufigsten Fehler im Detail

certificate-host-mismatch

starttls-not-supported

sts-policy-fetch-error

Schritt-für-Schritt-Diagnose: vom Fehler zur Korrektur

Praxisbeispiele: einen echten Bericht analysieren

Fall 1: Sauberer Bericht (keine Fehler)

Fall 2: Zertifikatsfehler auf einem sekundären MX

Fall 3: MTA-STS-Richtlinie nicht erreichbar

Berichtsanalyse automatisieren

Geringes Volumen: dediziertes Postfach

Hohes Volumen: HTTPS-Endpoint

Konfiguration mit CaptainDNS überprüfen

Empfohlener Aktionsplan

FAQ

Was ist ein TLS-RPT-Bericht und was enthält er?

Wie liest man die JSON-Struktur eines TLS-RPT-Berichts?

Welche Fehlertypen (result-type) gibt es in einem TLS-RPT-Bericht?

Was bedeutet certificate-host-mismatch in einem TLS-RPT-Bericht?

Wie behebt man den Fehler starttls-not-supported?

Wie oft werden TLS-RPT-Berichte gesendet?

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

Glossar

Verwandte TLS-RPT-Leitfäden

Quellen

Ähnliche Artikel

Von testing zu enforce: schrittweise MTA-STS-Bereitstellungsstrategie

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

MTA-STS vs DANE: Welches Protokoll zur Absicherung des E-Mail-Transports wählen?