TLS-RPT-Checker

Warum Ihren TLS-RPT prüfen

Der SMTP-Transport nutzt TLS opportunistisch: schlägt die Aushandlung fehl, fällt die Verbindung lautlos auf Klartext zurück. Ihre E-Mails gehen unverschlüsselt raus, und niemand warnt Sie. Schlimmer noch: ein Man-in-the-Middle kann STARTTLS aktiv unterdrücken, um genau diesen Rückfall zu erzwingen.

TLS-RPT (RFC 8460) behebt die Verschlüsselungslücke nicht (das übernimmt MTA-STS), aber endlich gibt es Ihnen Sichtbarkeit. Jeder sendende MTA, der TLS nicht aufbauen kann, schickt einen JSON-Bericht an die von Ihnen veröffentlichte rua-Adresse. Ohne diesen Mechanismus sind Sie blind.

Die Konfiguration zu prüfen, bevor Sie sie in einer DNS-Ecke vergessen, ist essenziell:

• Fehlender Eintrag → Sie wissen nichts von TLS-Fehlern, kein Audit-Trail
• Ungültige rua-URI → MTAs können die Berichte nicht zustellen, sie werden verworfen
• Keine externe Autorisierung → wenn Sie an einen Drittanbieter delegieren, weisen dessen Server die Berichte zurück

Häufige Anwendungsfälle:

• Nach der Veröffentlichung → bestätigen, dass der Eintrag korrekt propagiert ist
• E-Mail-Sicherheitsaudit → TLS-Abdeckung und Fehlersichtbarkeit validieren
• Vor MTA-STS enforce → sicherstellen, dass TLS-RPT während der Testphase Berichte sammelt

So nutzen Sie diesen Checker in 3 Schritten

Schritt 1: Domain zur Analyse eingeben

Geben Sie die Domain genau so ein, wie sie in Ihren E-Mail-Adressen erscheint:

• captaindns.com (Hauptdomain)
• marketing.captaindns.com (Subdomain, falls Sie aus einer Subdomain senden)

Das Tool fragt automatisch _smtp._tls.domain ab, holt den veröffentlichten TXT-Eintrag und prüft externe Autorisierungen, falls nötig.

Schritt 2: Ergebnisse prüfen

Der Checker zeigt an:

Schritt 3: Markierte Probleme beheben

Die Ergebnisse sind nach Schweregrad sortiert:

• Kritisch → der Eintrag ist ungültig, kein Bericht wird gesendet
• Warnung → funktioniert, birgt aber ein Risiko oder eine teilweise Abdeckung
• Info → nicht blockierende Best Practice (unbekanntes Tag, MTA-STS fehlt)

Korrigieren Sie das DNS, warten Sie auf die Propagierung, und starten Sie den Checker erneut.

Was ist TLS-RPT

TLS-RPT (SMTP TLS Reporting, RFC 8460) ist ein Mechanismus, der:

1. Eine Berichtsadresse im DNS veröffentlicht für die empfangende Domain
2. Sendende MTAs auffordert, einen JSON-Bericht zu senden, wenn TLS scheitert
3. Eine Spur der Verschlüsselungsfehler liefert (abgelaufenes Zertifikat, Downgrade, Mismatch)

Die Architektur ist bewusst minimal: ein einziger TXT-Eintrag, veröffentlicht auf _smtp._tls.domain, der die Version und eine oder mehrere rua=-URIs enthält.

Beispiel TLS-RPT-Eintrag:

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

Dieser Eintrag weist sendende MTAs (Gmail, Outlook, etc.) an, ihre TLS-Fehlerberichte an tls-reports@captaindns.com zu senden.

Unterschied zu MTA-STS: TLS-RPT ist der Begleiter von MTA-STS, keine Alternative. MTA-STS erzwingt TLS-Verschlüsselung, TLS-RPT meldet die Fehler. Beide Protokolle leben an getrennten Orten (_mta-sts.domain für STS, _smtp._tls.domain für RPT) und arbeiten zusammen.

Was der Checker prüft

Fünf Dimensionen werden parallel analysiert, um einen 0-100-Score zu erzeugen:

Veröffentlichter DNS-Eintrag

Syntax des Eintrags

Reporting-URIs

rua-Qualität

• Die rua-Domain stimmt mit der geprüften Domain überein → keine externe Autorisierung nötig
• Die Domain ist anders → Vorhandensein von [domain]._report._tls.[Drittanbieter] prüfen (Cross-Domain-Autorisierung)
• Die https-URI antwortet mit gültigem HTTPS (leichter Probe-Test serverseitig)

Gesamthygiene

• MTA-STS parallel veröffentlicht (Hygiene-Bonus +2)
• Kein unbekanntes Tag, das den Eintrag verschmutzt
• Policy konsistent mit dem Mail-Setup der Domain

Häufige Diagnosen und Lösungen

Eintrag fehlt (missing_record)

Ursache: Es existiert kein TXT auf _smtp._tls.captaindns.com.

Lösung: veröffentlichen

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

Fehlendes rua-Tag (rua_missing)

Ursache: Der Eintrag enthält v=TLSRPTv1, aber kein Ziel.

Lösung: Mindestens eine URI hinzufügen: v=TLSRPTv1; rua=mailto:tls-reports@captaindns.com. Ohne rua sendet kein MTA einen Bericht.

Ungültige rua-URI (rua_invalid_uri)

Ursache: Die URI ist fehlerhaft (fehlendes mailto:, Leerzeichen in der Adresse, unbekanntes Schema).

Korrekturbeispiele:

- rua=tls-reports@captaindns.com         # mailto: fehlt
+ rua=mailto:tls-reports@captaindns.com

- rua=mailto: tls-reports@captaindns.com # Leerzeichen nach mailto: verboten
+ rua=mailto:tls-reports@captaindns.com

Mehrere Einträge (multiple_records)

Ursache: Mehr als ein TLS-RPT-TXT existiert auf _smtp._tls.captaindns.com.

Lösung: RFC 8460 §3 schreibt einen einzigen Eintrag vor. Duplikate identifizieren, den anzuwendenden behalten, die übrigen entfernen.

CNAME auf _smtp._tls (cname_on_smtp_tls)

Ursache: _smtp._tls.domain ist ein CNAME, das anderswohin zeigt.

Lösung: Der RFC verbietet CNAME an dieser Stelle. Stattdessen direkt einen TXT veröffentlichen.

Externe Autorisierung erforderlich (rua_unauthorized_external)

Ursache: Die rua-Adresse nutzt eine andere Domain als die TLS-RPT-Domain.

Lösung: Die empfangende Domain (z.B. uriports.com) muss veröffentlichen:

captaindns.com._report._tls.uriports.com. IN TXT "v=TLSRPTv1"

Dieser Eintrag autorisiert die Berichtszustellung für captaindns.com.

MTA-STS-Begleiter fehlt (mta_sts_companion_missing)

Ursache: TLS-RPT ist veröffentlicht, aber MTA-STS nicht.

Lösung: MTA-STS einsetzen, damit die TLS-RPT-Berichte einen Sinn bekommen. Siehe den MTA-STS-Checker und den vollständigen Leitfaden.

Cross-Domain-Autorisierung und externe rua

RFC 8460 übernimmt die DMARC-Konvention (RFC 7489 §7.1): eine Domain kann eine andere Domain nicht ohne deren ausdrückliche Zustimmung dazu auffordern, ihre Berichte zu empfangen.

Der Mechanismus

Ihre Domain: captaindns.com rua-URI: mailto:tls-reports@uriports.com

Die externe Domain uriports.com muss veröffentlichen:

captaindns.com._report._tls.uriports.com. IN TXT "v=TLSRPTv1"

Ohne diesen Eintrag weigern sich konforme sendende MTAs, die Berichte an uriports.com weiterzuleiten (sie schützen Drittanbieter-Analysatoren vor Umleitungsmissbrauch).

Häufige Stolperfallen

• Verwechslung mit DMARC: DMARC nutzt _report._dmarc.[Drittanbieter], TLS-RPT nutzt _report._tls.[Drittanbieter]. Korrektes Präfix prüfen.
• Mehrere überwachte Domains: Ein mandantenfähiger Analysator (Postmark, Uriports, Dmarcian, Valimail, Sendmarc) muss einen Eintrag pro Kundendomain veröffentlichen (kunde1.de._report._tls.postmarkapp.com, kunde2.de._report._tls.postmarkapp.com, etc.).
• Kein Wildcard erlaubt: Es ist ein expliziter Eintrag pro Paar (überwachte Domain, Analysator-Domain) erforderlich.
• Der Checker meldet automatisch externe rua-Einträge ohne veröffentlichte Autorisierung.

TLS-RPT und MTA-STS: kombinierter Einsatz

Die beiden Protokolle bilden eine Defense in Depth:

Empfohlene Einsatzreihenfolge

1. TLS-RPT zuerst veröffentlichen, um Berichte zu sammeln
2. MTA-STS im Testmodus einsetzen, ohne die Zustellung zu blockieren
3. 2 bis 4 Wochen beobachten der TLS-RPT-Berichte, um problematische MX-Hosts zu identifizieren
4. MTA-STS in den Enforce-Modus schalten, wenn die Berichte sauber sind
5. TLS-RPT beibehalten für die kontinuierliche Überwachung

Ohne MTA-STS: TLS-RPT meldet Fehler, aber keine Policy zwingt sendende MTAs, TLS zu nutzen. Sie sehen die Probleme, ohne sie verhindern zu können.

Ohne TLS-RPT: MTA-STS erzwingt TLS, aber Sie werden nie erfahren, dass ein legitimer MTA durch Ihre Policy blockiert wird. Risiko einer stillen Nicht-Zustellung.

Ergänzende Tools und Ressourcen

Ressourcen:

• TLS-RPT: der vollständige Leitfaden
• TLS-RPT auf Microsoft 365, Google Workspace und OVHcloud konfigurieren
• TLS-RPT-Berichte im Alltag analysieren
• RFC 8460 - SMTP TLS Reporting
• RFC 8461 - MTA-STS
• RFC 7489 §7.1 - Cross-Domain Reporting