Warum einen Offline-Validator nutzen
Ein TLS-RPT-Syntaxvalidator analysiert Ihren Eintrag ohne DNS-Veröffentlichung oder DNS-Abfrage. Dieser Offline-Ansatz deckt drei zentrale Anwendungsfälle ab, die ein Live-Audit nicht behandeln kann.
Typische Anwendungsfälle:
- Vor der Bereitstellung → Entwurf vor der DNS-Veröffentlichung validieren, um zu vermeiden, dass ein Eintrag von MTAs stillschweigend ignoriert wird.
- Entwurfsvalidierung → Syntax eines aus einem Generator, internen Wiki oder geteilten Template kopierten Eintrags prüfen.
- Offline-Debugging → Fehler ohne Zugriff auf das öffentliche DNS reproduzieren und beheben, z. B. in isolierten oder Pre-Production-Umgebungen.
- Konfigurationsprüfung → Einen von einem Partner erhaltenen oder aus einem Drittanbieter-Tool exportierten Eintrag vor der Anwendung prüfen.
Der Validator wendet die RFC 8460-Spezifikation an: TLSRPTv1-Version, rua-Tag, Format von mailto:- und https:-Endpunkten, Cross-Domain-Autorisierung und Fehlen unbekannter Tags. Es wird keine DNS-Abfrage durchgeführt. Ihre Daten bleiben in Ihrem Browser.
So nutzen Sie diesen Validator in 3 Schritten
Schritt 1: Eintrag einfügen
Kopieren Sie den Wert Ihres TLS-RPT-Eintrags in das vorgesehene Feld:
v=TLSRPTv1; rua=mailto:tls-reports@captaindns.com
Sie können einen Entwurf, einen bestehenden Eintrag oder die Ausgabe eines Generators einfügen. Der Validator führt in diesem Schritt keine Netzwerkanfrage aus.
Schritt 2: Domain hinzufügen (optional)
Die Eingabe einer Domain aktiviert die Cross-Domain-Autorisierungsprüfung. Der Validator wechselt in den Modus record_and_domain und prüft jeden externen Endpunkt, um zu verifizieren, dass ein TLSRPT-Autorisierungseintrag auf der Empfängerseite existiert.
Ohne Domain wird nur die reine Syntax validiert (Modus record_only).
Schritt 3: Ergebnis analysieren
Ergebnisse werden nach Schweregrad klassifiziert:
- Fehler → blockierendes Problem, der Eintrag wird von sendenden Servern ignoriert oder abgelehnt
- Warnung → funktional, aber Verbesserung empfohlen
- Gültig → Syntax ist RFC 8460-konform
Beheben Sie jeden Hinweis, bevor Sie den Eintrag im öffentlichen DNS veröffentlichen.
Validator oder Record Check: wann welches Tool
Beide Tools sind komplementär. Sie ersetzen sich nicht: sie kommen an unterschiedlichen Punkten im Lebenszyklus eines TLS-RPT-Eintrags zum Einsatz.
| Dimension | Validator (dieses Tool) | Record Check |
|---|---|---|
| Einsatzzeitpunkt | vor der Bereitstellung | nach der Bereitstellung |
| DNS-Lookup | keiner | live _smtp._tls-Auflösung |
| Eintragsquelle | manuell (eingefügt) | öffentliches DNS |
| Cross-Domain-Prüfung | optional (über Domain) | systematisch |
| Erkennung des veröffentlichten Werts | statisch | echter Zustand |
| An Server gesendete Daten | keine | analysierte Domain |
Empfohlener Workflow:
- Eintrag entwerfen → Validator zur Syntaxprüfung
- TXT-Eintrag im DNS veröffentlichen → Propagation abwarten
- Record Check zur Bestätigung des Live-Zustands
Der Validator erkennt Eingabefehler vor der Veröffentlichung. Der Record Check erkennt Drift und bestätigt, dass der vom DNS ausgelieferte Eintrag dem geplanten Entwurf entspricht.
Validierungsmodi
Der Validator unterstützt zwei Modi je nach ausgefüllten Feldern.
Modus record_only
Sie fügen nur den TLS-RPT-Eintrag ein. Reine Syntaxvalidierung:
- exakte
TLSRPTv1-Version, in erster Position - Vorhandensein des
rua=-Tags - Endpunktformat (
mailto:oderhttps:) - wohlgeformte E-Mail-Adressen in
mailto:-Endpunkten - unbekannte Tags als Warnungen
Keine Netzwerkanfrage. Ideal zur Validierung eines Entwurfs vor der Veröffentlichung.
Modus record_and_domain
Sie fügen den Eintrag und eine Domain ein. Zusätzlich zur Syntaxvalidierung führt der Validator eine Cross-Domain-Autorisierungsprüfung für externe Endpunkte durch:
- erkennt jeden Endpunkt, dessen Domain sich von der analysierten Domain unterscheidet
- sucht den TLSRPT-Autorisierungseintrag auf der Empfängerseite
- markiert externe Endpunkte ohne Autorisierung
Dieser Modus hilft, Konfigurationen zu erkennen, in denen Sie auf einen Drittanbieter (verwaltete Berichtsanalyse) zeigen, ohne dass dieser die empfängerseitige Autorisierung veröffentlicht hat.
Geprüfte Syntaxregeln
Der Validator wendet die RFC 8460 §3-Regeln auf den TXT-Eintrag unter _smtp._tls.domain an:
| Feld | Regel |
|---|---|
| v | muss exakt TLSRPTv1 sein (case-sensitiv), in erster Position |
| rua | erforderlich, enthält einen oder mehrere durch , getrennte Endpunkte |
| Gesamtformat | schlüssel=wert-Paare getrennt durch ; |
| Unbekannte Tags | toleriert, aber als Warnungen markiert |
| Leerzeichen | toleriert um ; und nach = |
Gültiges Beispiel:
v=TLSRPTv1; rua=mailto:tls-reports@captaindns.com
Reporting-Endpunktformate
Jeder Endpunkt in rua= muss ein anerkanntes Schema verwenden:
| Schema | Format | Verwendung |
|---|---|---|
mailto: | mailto:adresse@domain | Berichte als E-Mail-Anhang |
https: | https://host/pfad | Berichte an Webhook gepostet |
Mehrere Endpunkte sind möglich, durch , getrennt:
v=TLSRPTv1; rua=mailto:tls-reports@captaindns.com,https://api.captaindns.com/tlsrpt
Jeder Endpunkt erhält dieselben aggregierten Berichte (einer pro 24 Stunden und Absender).
rua-Endpunkte: mailto vs. https
Die Wahl zwischen mailto: und https: beeinflusst die Komplexität der Bereitstellung und die Verarbeitung der Berichte.
mailto-Endpunkte
rua=mailto:tls-reports@captaindns.com
Eigenschaften:
- Berichte als E-Mail-Anhang (gzip-komprimiertes JSON)
- einfache Einrichtung, keine Entwicklung nötig
- oft eine dedizierte Adresse (
tlsrpt@,reports@) - keine Cross-Domain-Autorisierung erforderlich, wenn die E-Mail auf derselben Domain wie der Eintrag liegt
https-Endpunkte
rua=https://tlsrpt.captaindns.com/v1/report
Eigenschaften:
- Berichte per HTTP POST an einen Webhook
- ermöglicht automatisierte Echtzeit-Verarbeitung
- erfordert einen gültigen HTTPS-Endpunkt (anerkanntes Zertifikat)
- keine Cross-Domain-Autorisierung erforderlich, wenn der Host auf derselben Domain wie der Eintrag liegt
Cross-Domain-Autorisierung
Wenn ein Endpunkt auf eine andere Domain als die analysierte zeigt (z. B. einen Drittanbieter-Berichtssammler), verlangt RFC 8460 §3.3 eine empfängerseitige Autorisierung:
- der Empfänger veröffentlicht einen TLSRPT-Eintrag unter
[quell-domain]._report._tls.[empfänger-domain] - ohne diese Autorisierung liefern sendende Server die Berichte nicht aus
Der Validator markiert externe Endpunkte ohne diese Autorisierung, sofern Sie das Domain-Feld ausgefüllt haben.
Ungültige Beispiele
- rua=tls-reports@captaindns.com
+ rua=mailto:tls-reports@captaindns.com
- rua=mailto:tlsrpt
+ rua=mailto:tls-reports@captaindns.com
- rua=http://tlsrpt.captaindns.com/report
+ rua=https://tlsrpt.captaindns.com/report
Häufige Syntaxfehler und Korrekturen
Fehlende oder falsche Version
Ursache: fehlender v=-Tag oder anderer Wert als TLSRPTv1.
Korrektur:
- rua=mailto:tls-reports@captaindns.com
+ v=TLSRPTv1; rua=mailto:tls-reports@captaindns.com
- v=TLSRPT1; rua=mailto:tls-reports@captaindns.com
+ v=TLSRPTv1; rua=mailto:tls-reports@captaindns.com
Fehlender rua-Tag
Ursache: Eintrag enthält v=TLSRPTv1 ohne rua-Endpunkt.
Korrektur: fügen Sie mindestens einen Endpunkt hinzu:
- v=TLSRPTv1
+ v=TLSRPTv1; rua=mailto:tls-reports@captaindns.com
Ungültiger mailto-Endpunkt
Ursache: fehlendes mailto:-Schema, fehlerhafte oder abgeschnittene E-Mail-Adresse.
Korrektur:
- v=TLSRPTv1; rua=tls-reports@captaindns.com
+ v=TLSRPTv1; rua=mailto:tls-reports@captaindns.com
- v=TLSRPTv1; rua=mailto:tlsrpt@
+ v=TLSRPTv1; rua=mailto:tls-reports@captaindns.com
Ungültiger https-Endpunkt
Ursache: http:-Schema statt https: oder unvollständige URL.
Korrektur: RFC 8460 akzeptiert nur HTTPS-Endpunkte.
- v=TLSRPTv1; rua=http://tlsrpt.captaindns.com/report
+ v=TLSRPTv1; rua=https://tlsrpt.captaindns.com/report
Cross-Domain nicht autorisiert
Ursache: ein externer Endpunkt (andere Domain als die analysierte) zeigt auf einen Empfänger, der keinen TLSRPT-Autorisierungseintrag veröffentlicht hat.
Korrektur: bitten Sie den Drittanbieter, den Autorisierungseintrag zu veröffentlichen, oder verwenden Sie einen Endpunkt auf Ihrer eigenen Domain:
- rua=mailto:tls-reports@uriports.com
+ rua=mailto:tls-reports@captaindns.com
Unbekannter Tag
Ursache: Vorhandensein eines nicht von RFC 8460 definierten Tags (z. B. ruf=, der für TLS-RPT im Gegensatz zu DMARC nicht existiert).
Korrektur: entfernen Sie den unbekannten Tag:
- v=TLSRPTv1; rua=mailto:tls-reports@captaindns.com; ruf=mailto:forensic@captaindns.com
+ v=TLSRPTv1; rua=mailto:tls-reports@captaindns.com
TLS-RPT und MTA-STS: kombinierte Bereitstellung
TLS-RPT entfaltet sein Potenzial mit MTA-STS. Beide Protokolle bilden ein untrennbares Duo für die Sicherheit des SMTP-Transports.
| Protokoll | Rolle |
|---|---|
| MTA-STS | erzwingt TLS-Verschlüsselung für eingehende E-Mails |
| TLS-RPT | meldet TLS-Verbindungsfehler und Anomalien |
Warum gemeinsam einsetzen:
- MTA-STS ohne TLS-RPT → Sie erzwingen TLS, wissen aber nicht, ob Server stillschweigend scheitern
- TLS-RPT ohne MTA-STS → Sie erhalten nützliche Berichte, aber keine Verschlüsselungsdurchsetzung
- MTA-STS + TLS-RPT → Sie erzwingen UND messen, mit voller Sichtbarkeit
Empfohlene Bereitstellung:
- Validieren Sie Ihre MTA-STS-Policy mit dem MTA-STS Syntax Checker
- Validieren Sie Ihren TLS-RPT-Eintrag mit diesem Validator
- Veröffentlichen Sie TLS-RPT zuerst (so erhalten Sie Berichte ab Beginn der MTA-STS-Testing-Phase)
- Veröffentlichen Sie MTA-STS im
mode: testing - Überwachen Sie die TLS-RPT-Berichte 2 bis 4 Wochen lang
- Schalten Sie MTA-STS auf
mode: enforce, sobald die Probleme behoben sind
Ergänzende Tools und Ressourcen
| Tool | Wann verwenden |
|---|---|
| TLS-RPT Record Check | Live-Audit des im DNS veröffentlichten Eintrags |
| TLS-RPT-Monitoring | Ihre TLS-RPT-Berichte automatisch empfangen und analysieren |
| TLS-RPT Generator | RFC 8460-konformen TLS-RPT-Eintrag erstellen |
| MTA-STS Syntax Checker | zugehörige MTA-STS-Policy offline validieren |
| DMARC Record Check | E-Mail-Authentifizierung abrunden |
| DNS-Propagation | Propagation nach Veröffentlichung bestätigen |
Zugehörige Leitfäden
- TLS-RPT: Der umfassende Leitfaden zur Überwachung der TLS-Verschlüsselung von E-Mails - Protokoll und Integration mit MTA-STS verstehen.
- TLS-RPT für Microsoft 365, Google Workspace und OVHcloud einrichten - schrittweise Anleitung je Anbieter.
- TLS-RPT-Berichte analysieren: praktischer Leitfaden - empfangene Berichte lesen und verwerten.
Spezifikationen
- RFC 8460 - SMTP TLS Reporting (offizielle Spezifikation)
- RFC 8461 - MTA-STS (Begleitprotokoll)
- TLS-RPT-Eintragsformat (§3)
- Cross-Domain-Autorisierung (§3.3)