Warum einen Offline-Validator nutzen
Ein TLS-RPT-Syntaxvalidator analysiert Ihren Eintrag ohne DNS-Veröffentlichung oder DNS-Abfrage. Dieser Offline-Ansatz deckt vier 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 reproduzieren und beheben, ohne auf das öffentliche DNS angewiesen zu sein, etwa an einem Pre-Production-Eintrag, der noch nicht veröffentlicht ist.
- Konfigurationsprüfung → Einen von einem Partner erhaltenen oder aus einem Drittanbieter-Tool exportierten Eintrag vor der Anwendung prüfen.
Der Validator wendet die Syntaxregeln der RFC 8460 an: TLSRPTv1-Version, rua-Tag, Format von mailto:- und https:-URIs und Fehlen unbekannter Tags. Die Validierung läuft auf unseren Servern: Der Eintrag, den Sie einfügen, wird zur Analyse an CaptainDNS übertragen. Veröffentlicht wird dabei nichts, es erfolgt keine DNS-Abfrage und keine rua-URI wird kontaktiert.
So nutzen Sie diesen Validator in 2 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 liest keine externe Quelle aus: Analysiert wird ausschließlich der Text, den Sie liefern.
Schritt 2: 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 |
| Erkennung externer URIs | keine | automatisch |
| Erkennung des veröffentlichten Werts | statisch | echter Zustand |
| An Server gesendete Daten | der eingefügte Eintrag | 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.
Ein Feld, ein Modus
Das Formular hat genau eine Eingabe: den TLS-RPT-Eintrag selbst. Keine Domain, kein zweiter Modus. Geprüft wird:
- exakte
TLSRPTv1-Version, in erster Position - Vorhandensein des
rua=-Tags - Endpunktformat (
mailto:oderhttps:) - wohlgeformte E-Mail-Adressen in
mailto:-Endpunkten - unbekannte Tags als Warnungen
Diese Kargheit stammt direkt aus RFC 8460. DMARC verlangt einen Autorisierungseintrag _report._dmarc auf der Empfängerseite, sobald Berichte an eine andere Domain gehen; §7 der RFC 8460 hat diesen Mechanismus für TLS-RPT bewusst verworfen. Es gibt somit nichts, woran Ihre rua-URIs zu messen wären: eine Adresse bei einem Drittanbieter für die Berichtssammlung ist unverändert gültig.
Welche Ihrer bereits veröffentlichten URIs die eigene Domain verlassen, zeigt der Record Check. Er erkennt sie anhand der abgefragten Domain.
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 (Groß-/Kleinschreibung beachten), in erster Position |
| rua | erforderlich, enthält eine oder mehrere durch , getrennte URIs |
| 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
Format der rua-URIs
Jede URI 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 URIs sind möglich, durch , getrennt:
v=TLSRPTv1; rua=mailto:tls-reports@captaindns.com,https://api.captaindns.com/tlsrpt
Jede URI erhält dieselben aggregierten Berichte (einer pro 24 Stunden und Absender).
rua-URIs: mailto vs. https
Die Wahl zwischen mailto: und https: beeinflusst die Komplexität der Bereitstellung und die Verarbeitung der Berichte.
mailto-URIs
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 Autorisierung auf der Empfängerseite erforderlich, auch für eine Adresse auf einer anderen Domain als der Eintrag
https-URIs
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 Autorisierung auf der Empfängerseite erforderlich, auch für einen Host auf einer anderen Domain als der Eintrag
Externe URIs (rua zu einer anderen Domain)
Wenn eine URI auf eine andere Domain als die analysierte zeigt (z. B. einen Drittanbieter-Berichtssammler), verlangt TLS-RPT keine Autorisierung auf der Empfängerseite:
- Anders als DMARC mit seinem
_report._dmarc-Eintrag definiert RFC 8460 keinen Verifizierungsmechanismus: §7 hat jede Cross-Domain-Autorisierung bewusst verworfen - Eine externe URI ist also unverändert gültig; sendende Server senden die Berichte ohne vorherige Prüfung auf der Empfängerseite
Der Validator lehnt sie niemals ab. Er hebt sie auch nicht hervor: ohne Referenzdomain fehlt ihm der Vergleichsmaßstab.
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: fehlendes 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
Fehlendes rua-Tag
Ursache: Eintrag enthält v=TLSRPTv1 ohne rua-URI.
Korrektur: fügen Sie mindestens eine URI hinzu:
- v=TLSRPTv1
+ v=TLSRPTv1; rua=mailto:tls-reports@captaindns.com
Ungültige mailto-URI
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ültige https-URI
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
Externe URI: Das ist kein Fehler
Zur Information: Eine rua-URI, die auf eine andere Domain zeigt (Drittanbieter-Sammler), ist vollkommen gültig. Anders als DMARC verlangt TLS-RPT keinen Autorisierungseintrag auf der Empfängerseite: Der Validator lehnt einen Eintrag niemals wegen einer externen rua ab.
Sie können also bedenkenlos auf einen Drittanbieter zeigen:
v=TLSRPTv1; rua=mailto:tls-reports@uriports.com
Unbekanntes Tag
Ursache: Vorhandensein eines nicht von RFC 8460 definierten Tags (z. B. ruf=, das es für TLS-RPT im Gegensatz zu DMARC nicht gibt).
Korrektur: entfernen Sie das unbekannte 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)
- Sicherheitsüberlegungen - externe rua (§7)