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

Von CaptainDNS
Veröffentlicht am 14. Februar 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 deiner 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
Analysiere das Feld failure-details, um den betroffenen MX-Server, die IP des Absenders und den genauen Fehlertyp zu identifizieren
Nutze den TLS-RPT-Syntaxprüfer, um deine Konfiguration vor und nach der Korrektur zu überprüfen

Du hast TLS-RPT auf deiner Domain konfiguriert und die Berichte beginnen einzutreffen. Komprimierte JSON-Dateien, gesendet von Google, Microsoft, Yahoo und anderen Anbietern. Du öffnest sie und findest strukturierte Datenblöcke mit Feldern wie policy-type, result-type, failed-session-count. Was bedeuten diese Daten? Wie machst du daraus konkrete Maßnahmen?

Das ist der am schlechtesten dokumentierte Teil von TLS-RPT. Die RFC 8460 definiert das Format, sagt dir aber nicht, wie du die Ergebnisse im operativen Kontext interpretieren sollst. Dieser Leitfaden schließt diese Lücke: Du lernst, 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 deiner E-Mails beeinträchtigen.

Wenn du TLS-RPT noch nicht konfiguriert hast, beginne 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 du die spezifische Konfiguration für deinen Anbieter suchst (Microsoft 365, Google Workspace, OVHcloud), findest du 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 dir 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: deine 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, dir die E-Mail zu senden
receiving-mx-hostname: dein betroffener MX-Server
receiving-ip: die IP deines 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 empfängst und entpackst du 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 du die Berichte per HTTPS empfängst (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	Erneuere das Zertifikat mit dem korrekten CN/SAN für deinen MX
`certificate-expired`	Das TLS-Zertifikat ist abgelaufen	Erneuere das Zertifikat sofort
`certificate-not-trusted`	Das Zertifikat ist nicht von einer anerkannten CA signiert	Verwende 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	Aktiviere STARTTLS in der Konfiguration deines Mailservers
`validation-failure`	Allgemeiner TLS-Validierungsfehler	Überprüfe 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	Stelle sicher, dass `https://mta-sts.captaindns.com/.well-known/mta-sts.txt` erreichbar ist
`sts-policy-invalid`	Die MTA-STS-Richtlinie ist fehlerhaft formatiert	Korrigiere die Syntax der Datei `mta-sts.txt`
`sts-webpki-invalid`	Das HTTPS-Zertifikat des MTA-STS-Servers ist ungültig	Erneuere das Zertifikat der Subdomain `mta-sts.captaindns.com`
`tlsa-invalid`	Der DANE-TLSA-Eintrag ist ungültig	Korrigiere den TLSA-Eintrag in deiner DNS-Zone
`dnssec-invalid`	Die DNSSEC-Validierung ist fehlgeschlagen	Korrigiere deine DNSSEC-Kette
`dane-required`	DANE ist erforderlich, aber der Server unterstützt es nicht	Setze DANE um oder entferne 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 deines MX-Servers den erwarteten Hostnamen nicht in seinem CN-Feld (Common Name) oder SAN-Feld (Subject Alternative Name) enthält.

Typisches Szenario: Dein 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 deines 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: Besorge dir ein Zertifikat, das den exakten FQDN deines 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: Aktiviere STARTTLS in deinem 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 deine 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 deiner MTA-STS-Probleme lies unseren MTA-STS-Troubleshooting-Leitfaden.

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

Wenn du einen Bericht mit Fehlern erhältst, folge diesem 5-Schritte-Workflow:

Schritt 1: Schweregrad einschätzen

Sieh dir 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 dir genau, was fehlgeschlagen ist. Nutze die Tabelle der 11 Fehlertypen weiter oben als Referenz.

Schritt 3: Betroffenen MX-Server identifizieren

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

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

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

Schritt 5: Korrigieren und überwachen

Wende die zum result-type passende Korrektur an und überwache 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. Deine Konfiguration funktioniert einwandfrei. Dieser Bericht bestätigt, dass:

Dein TLS-Zertifikat gültig ist und zum MX-Hostnamen passt
STARTTLS auf deinem Server aktiv ist
Deine 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: Erneuere das Zertifikat von mail2.captaindns.com und füge 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 deinen 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: Stelle 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"

Erstelle einen Filter in deinem Mail-Client, um die Berichte automatisch zu sortieren. Prüfe sie einmal pro Woche und achte auf total-failure-session-count-Werte größer als null.

Hohes Volumen: HTTPS-Endpoint

Für Domains mit hohem Mailaufkommen konfiguriere 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. Du kannst die Berichte automatisch parsen und Alerts auslösen, wenn total-failure-session-count einen Schwellenwert überschreitet.

Konfiguration mit CaptainDNS überprüfen

Bevor du deine TLS- oder MTA-STS-Konfiguration änderst, nutze den TLS-RPT-Generator, um einen korrekten Eintrag zu erstellen. Nach der Korrektur überprüfe mit dem TLS-RPT-Checker, dass alles stimmt.

Empfohlener Aktionsplan

Entpacke und lies deinen ersten Bericht: Öffne eine .json.gz-Datei von Google oder Microsoft und identifiziere die 4 Blöcke (Header, policy, summary, failure-details)
Prüfe das Verhältnis Fehler/Erfolge: Eine Fehlerquote über 5 % erfordert eine Untersuchung
Identifiziere den result-type: Nutze die Tabelle der 11 Fehlertypen, um die genaue Ursache zu verstehen
Behebe das Problem auf dem betroffenen Server: Zertifikat, STARTTLS oder MTA-STS-Richtlinie je nach Fehlertyp
Überwache die folgenden Berichte: Bestätige 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 dir 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). Entpacke die .json.gz-Datei mit gunzip oder zcat und formatiere 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 deines MX-Servers nicht zum erwarteten Hostnamen passt. Zum Beispiel, wenn dein MX mail.captaindns.com ist, das Zertifikat aber für eine andere Domain ausgestellt wurde. Korrigiere dies, indem du ein Zertifikat besorgst, dessen SAN (Subject Alternative Name) den exakten FQDN deines MX enthält.

Wie behebt man den Fehler starttls-not-supported?

Der Fehler starttls-not-supported bedeutet, dass dein MX-Server den STARTTLS-Befehl nicht anbietet und E-Mails deshalb im Klartext übertragen werden. Aktiviere STARTTLS in der Konfiguration deines Servers: Für Postfix füge smtpd_tls_security_level = may mit den Pfaden zu deinem Zertifikat und privaten Schlüssel in main.cf hinzu. Überprüfe 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 dir E-Mails schickt (Google, Microsoft, Yahoo usw.), erstellt seinen eigenen Bericht unabhängig. Du erhältst also potenziell mehrere Berichte pro Tag, einen pro sendendem Anbieter. Die ersten Berichte treffen 24 bis 48 Stunden nach der Veröffentlichung deines 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 deiner 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üfe deine Konfiguration jetzt: Nutze unseren TLS-RPT-Checker, um zu kontrollieren, dass dein _smtp._tls-Eintrag korrekt ist und die zugehörigen Richtlinien erkannt werden.

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

Aufbau eines TLS-RPT-Berichts

Die 4 Blöcke des Berichts

Wie empfängst und entpackst du 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

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

MTA-STS funktioniert nicht? Der komplette Fehlerbehebungs-Guide

MTA-STS: Die Komplettanleitung zur Absicherung deines E-Mail-Transports