TLS-RPT Record Checker

Was prüft dieser TLS-RPT-Checker?

Dieses Tool führt eine vollständige Analyse der TLS-RPT-Konfiguration für jede Domain durch:

1. DNS-Lookup: Fragt _smtp._tls.domain nach TXT-Einträgen ab
2. Syntaxvalidierung: Prüft RFC 8460-Konformität
3. URI-Verifizierung: Validiert alle Reporting-Adressen
4. Externe Autorisierung: Prüft Autorisierungseinträge für Drittanbieter-Ziele
5. Best Practices: Empfiehlt Verbesserungen

TLS-RPT-Einträge verstehen

DNS-Standort

TLS-RPT-Einträge werden als TXT-Einträge bei einer spezifischen Subdomain veröffentlicht:

_smtp._tls.captaindns.com  TXT  "v=TLSRPTv1; rua=mailto:tlsrpt@captaindns.com"

Eintragsstruktur

Unterstützte URI-Schemata

mailto: - Berichte als E-Mail gesendet

rua=mailto:tlsrpt@captaindns.com

https: - Berichte an Endpunkt gepostet

rua=https://tlsrpt.captaindns.com/report

Externe Domain-Autorisierung

Wenn Berichte an eine externe Domain gehen, ist eine Autorisierung erforderlich.

Szenario

Ihre Domain: captaindns.com Berichtsziel: mailto:reports@analyzer.com

Erforderliche Autorisierung

Die externe Domain (analyzer.com) muss veröffentlichen:

captaindns.com._report._tls.analyzer.com  TXT  "v=TLSRPTv1"

Was dieses Tool prüft

1. Erkennt externe Reporting-Ziele
2. Fragt nach Autorisierungseintrag
3. Meldet fehlende Autorisierung als Fehler
4. Zeigt korrektes Autorisierungseintragsformat an

Häufig erkannte Probleme

Kein TLS-RPT-Eintrag gefunden

Ursache: Domain hat TLS-RPT nicht konfiguriert Auswirkung: Keine TLS-Fehlerberichte empfangen Behebung: TLS-RPT-Eintrag generieren und im DNS veröffentlichen

Ungültiger Versions-Tag

Ursache: Falsche Versionszeichenkette (z.B. "v=TLSRPT1") Auswirkung: Eintrag von sendenden Servern ignoriert Behebung: Verwenden Sie genau v=TLSRPTv1 (Groß-/Kleinschreibung beachten)

Fehlende Reporting-URI

Ursache: Kein rua=-Tag im Eintrag Auswirkung: Eintrag ungültig, keine Berichte gesendet Behebung: Fügen Sie rua=mailto:adresse@domain.com oder rua=https://endpunkt hinzu

Externe Autorisierung fehlt

Ursache: Drittanbieter-Ziel hat nicht autorisiert Auswirkung: Berichte an dieses Ziel können abgelehnt werden Behebung: Autorisierungseintrag von Ziel-Domain anfordern

TLS-RPT und MTA-STS-Beziehung

Diese beiden Protokolle arbeiten zusammen:

Empfohlene Bereitstellungsreihenfolge

1. MTA-STS im Testmodus bereitstellen

   • Policy bei https://mta-sts.captaindns.com/.well-known/mta-sts.txt
   • DNS-Eintrag bei _mta-sts.captaindns.com

2. TLS-RPT konfigurieren

   • Ermöglicht Sichtbarkeit vor Durchsetzung
   • Sehen, was fehlschlagen würde

3. Berichte überwachen

   • Auf unerwartete Fehler prüfen
   • Falsch konfigurierte Absender identifizieren

4. MTA-STS durchsetzen

   • Von mode: testing zu mode: enforce wechseln
   • Weiter über TLS-RPT überwachen

FAQ - Häufig gestellte Fragen

F: Was ist TLS-RPT und was prüft dieses Tool?

A: TLS-RPT (SMTP TLS Reporting) ist ein DNS-basierter Mechanismus zum Empfangen von Berichten über TLS-Verschlüsselungsfehler. Dieses Tool schlägt den _smtp._tls.captaindns.com TXT-Eintrag nach, validiert seine Syntax gemäß RFC 8460, prüft Reporting-URIs und verifiziert externe Domain-Autorisierung bei Bedarf.

F: Wo sollte der TLS-RPT-Eintrag veröffentlicht werden?

A: Der TLS-RPT-Eintrag muss als TXT-Eintrag bei _smtp._tls.captaindns.com veröffentlicht werden. Der Eintragswert beginnt mit v=TLSRPTv1 und enthält eine oder mehrere Reporting-URIs.

F: Was ist externe Domain-Autorisierung?

A: Wenn Ihr TLS-RPT-Eintrag Berichte an eine E-Mail-Adresse auf einer anderen Domain sendet (z.B. tlsrpt@drittanbieter.de), muss die empfangende Domain dies autorisieren. Sie veröffentlicht einen TXT-Eintrag bei captaindns.com._report._tls.drittanbieter.de mit dem Wert v=TLSRPTv1. Ohne dies können Berichte abgelehnt werden.

Ergänzende Tools

Nützliche Ressourcen

• RFC 8460 - SMTP TLS Reporting (offizielle Spezifikation)
• RFC 8461 - MTA-STS (Begleitprotokoll)
• Google Workspace - TLS-Reporting konfigurieren
• Microsoft 365 - Eingehendes SMTP TLS