Zum Hauptinhalt springen

Netzwerk & Web

Netzwerktools, Webseitenanalyse und Zertifikate.

Kostenloses TLS-RPT-Monitoring

TLS-Fehler erkennen, SMTP-Verschlüsselungsberichte automatisch analysieren

Täglich gehen E-Mails verloren. Still, ohne Fehlermeldung. Ein abgelaufenes Zertifikat, eine fehlerhafte MTA-STS-Richtlinie, ein STARTTLS-Downgrade: sendende Server scheitern an der TLS-Aushandlung (RFC 8460), und Sie erfahren es nicht. CaptainDNS empfängt Ihre TLS-RPT-Berichte automatisch, analysiert sie und macht die Ergebnisse sofort sichtbar. Fügen Sie Ihre Domain hinzu. Wir kümmern uns um den Rest.

Automatischer Empfang

Berichte werden automatisch empfangen und analysiert. Kein Server zu verwalten, kein JSON zu dekodieren. Fügen Sie den DNS-Eintrag hinzu und das war's.

Domain-Verifizierung

Ein Verifizierungs-TXT-Eintrag bestätigt die Inhaberschaft der Domain. Fügen Sie ihn Ihrem DNS hinzu und die Validierung erfolgt automatisch.

Detaillierte Analyse

Sehen Sie Erfolgs- und Fehlerzähler für TLS-Verbindungen, Richtliniendetails und Quell-IP-Adressen für jeden Berichtszeitraum ein.

Dedizierter Report-Kollektor

Jede Domain erhält einen eindeutigen HTTPS-Endpunkt. Der TLS-RPT-DNS-Eintrag wird automatisch mit der korrekten rua=-URL generiert.

Mehrere Domains

Überwachen Sie TLS-RPT-Berichte mehrerer Domains von einem einzigen Konto aus. Jede Domain verfügt über einen eigenen verifizierten Report-Kollektor.

Warum TLS-RPT-Berichte überwachen?

TLS-RPT (SMTP TLS Reporting, RFC 8460) ist Ihre einzige Informationsquelle über TLS-Fehler bei eingehender Post. Ohne TLS-RPT hinterlassen abgewiesene oder unverschlüsselt übertragene E-Mails keine Spur auf Empfängerseite. Ihre Domain-Reputation leidet. Ihre Nutzer erhalten nichts. Sie sehen nichts.

Drei häufige Probleme, die durch TLS-RPT erkannt werden:

  • Abgelaufene Zertifikate : Ihr MX-Server präsentiert ein ungültiges oder abgelaufenes TLS-Zertifikat. Verschlüsselte Verbindungen schlagen fehl. E-Mails kommen nicht an.
  • Fehlkonfiguriertes MTA-STS : Ihre MTA-STS-Richtlinie verweist auf MX-Server, die nicht mehr existieren. Strikte Sender verweigern die Verbindung.
  • STARTTLS-Downgrade : Netzwerk-Intermediäre entfernen die STARTTLS-Erweiterung. Der gesamte E-Mail-Verkehr läuft unverschlüsselt, ohne dass Sie es bemerken.

TLS-RPT-Monitoring in 3 Schritten einrichten

Schritt 1: Domain hinzufügen

Melden Sie sich an und registrieren Sie die zu überwachende Domain. CaptainDNS generiert einen eindeutigen HTTPS-Report-Kollektor und den zugehörigen TLS-RPT-DNS-Eintrag.

Schritt 2: Domain-Inhaberschaft verifizieren

Fügen Sie den Verifizierungs-TXT-Eintrag Ihrem DNS hinzu. Die Validierung erfolgt automatisch, sobald der Eintrag erkannt wird.

Schritt 3: TLS-RPT-Eintrag veröffentlichen

Fügen Sie den bereitgestellten _smtp._tls-TXT-Eintrag Ihrem DNS hinzu. Sendende Server beginnen dann, TLS-Fehlerberichte an Ihren CaptainDNS-Endpunkt zu übermitteln.


Was ist TLS-RPT?

TLS-RPT (Transport Layer Security Reporting) ist ein Standard gemäß RFC 8460. Er ermöglicht es sendenden Mailservern, TLS-Aushandlungsfehler an die Empfängerdomain zu melden.

Beispiel für einen DNS-Eintrag:

_smtp._tls.captaindns.com.  IN  TXT  "v=TLSRPTv1; rua=https://api.captaindns.com/tls-rpt/ingest/abc123"

Der _smtp._tls-Eintrag teilt sendenden Servern mit, wohin sie ihre JSON-Berichte senden sollen, wenn eine TLS-Verbindung zu Ihrer Domain fehlschlägt.


Was enthält ein TLS-RPT-Bericht?

FeldBeschreibung
Sendende OrganisationDer E-Mail-Anbieter, der den Bericht gesendet hat
ZeitraumStart- und End-Zeitstempel des Berichtszeitraums
Angewandte RichtlinienErkannte MTA-STS-, DANE- oder STARTTLS-Richtlinien
Erfolgreiche SitzungenAnzahl erfolgreich aufgebauter TLS-Verbindungen
Fehlgeschlagene SitzungenAnzahl fehlgeschlagener TLS-Aushandlungen mit Fehlerdetails

TLS-RPT-Fehlertypen (RFC 8460)

FehlertypBeschreibung
starttls-not-supportedDer empfangende Server unterstützt kein STARTTLS
certificate-expiredDas vom MX präsentierte TLS-Zertifikat ist abgelaufen
certificate-host-mismatchDas Zertifikat stimmt nicht mit dem MX-Hostnamen überein
certificate-not-trustedDie Zertifikatskette wird vom Sender nicht als vertrauenswürdig eingestuft
validation-failureAllgemeiner TLS-Validierungsfehler
sts-policy-invalidDie MTA-STS-Richtlinie konnte nicht validiert werden
sts-webpki-invalidDer MTA-STS-Richtlinienhost hat ein ungültiges Web-PKI-Zertifikat
tlsa-invalidDer DANE-TLSA-Eintrag ist ungültig oder stimmt nicht überein
dane-requiredDANE ist erforderlich, konnte aber nicht validiert werden

TLS-RPT vs DMARC

TLS-RPTDMARC
SchütztTransportverschlüsselung (SMTP TLS)Absender-Authentifizierung (SPF/DKIM)
Berichtet überTLS-Verbindungsfehler, ZertifikatsfehlerAuthentifizierungs-Abgleichfehler
RFCRFC 8460RFC 7489
DNS-Eintrag_smtp._tls TXT_dmarc TXT
Erkannte BedrohungenAbgelaufene Zertifikate, STARTTLS-Entfernung, DANE/MTA-STS-FehlkonfigurationenSpoofing, Phishing, Domain-Identitätsmissbrauch

Beide Protokolle ergänzen sich. Setzen Sie das DMARC-Monitoring parallel zu TLS-RPT ein, um volle Transparenz über Ihre E-Mail-Sicherheit zu erhalten.


Wer sendet TLS-RPT-Berichte?

Die wichtigsten E-Mail-Anbieter, die TLS-RPT-Berichte senden, wenn sie TLS-Fehler bei der Verbindung zu Ihrer Domain feststellen:

  • Google (Gmail, Workspace): Sendet tägliche aggregierte Berichte über alle Verbindungsversuche
  • Microsoft (Outlook, Exchange Online): Meldet TLS-Aushandlungsfehler für Microsoft-365-Mandanten
  • Yahoo: Liefert TLS-RPT-Daten für die Yahoo-Mail- und AOL-Infrastruktur
  • Apple (iCloud Mail): Berichtet über TLS-Fehler bei der iCloud-Mail-Zustellung
  • Comcast: Einer der ersten ISPs mit TLS-RPT-Reporting-Implementierung

Praxisbeispiele

Vorfall 1: Unerkanntes abgelaufenes Zertifikat

Symptom: Google und Microsoft melden certificate-expired-Fehler. Ihre Nutzer erhalten keine E-Mails mehr von diesen Anbietern.

Diagnose: Das CaptainDNS-Dashboard zeigt einen Fehleranstieg über 24 Stunden. Ursache: ein abgelaufenes Let's Encrypt-Zertifikat auf dem Haupt-MX.

Maßnahme: TLS-Zertifikat sofort erneuern. Die nachfolgenden TLS-RPT-Berichte bestätigen die Wiederherstellung der verschlüsselten Verbindungen.

Vorfall 2: Desynchronisierte MTA-STS-Richtlinie

Symptom: Berichte melden sts-policy-invalid-Fehler. Eine MTA-STS-Richtlinie ist veröffentlicht. Trotzdem werden E-Mails abgewiesen.

Diagnose: Die MTA-STS-Richtlinie verweist auf einen MX-Server, der bei einer Migration entfernt wurde. Sender im enforce-Modus verweigern die Verbindung.

Maßnahme: MTA-STS-Richtlinie aktualisieren und den Versions-id erhöhen. Die nachfolgenden Berichte bestätigen die Korrektur.


FAQ - Häufig gestellte Fragen

F: Was ist ein TLS-RPT-Eintrag?

A: Ein TLS-RPT-Eintrag ist ein DNS-TXT-Eintrag unter _smtp._tls.ihredomain.com. Er enthält eine rua=-Direktive, die sendenden Servern mitteilt, wohin TLS-Fehlerberichte gesendet werden sollen (RFC 8460).


F: Ist das TLS-RPT-Monitoring von CaptainDNS kostenlos?

A: Ja, das TLS-RPT-Monitoring ist vollständig kostenlos. Wir sind überzeugt, dass jede Domain ihre TLS-Sicherheit ohne technische Hürden überwachen können sollte.


F: Wie konfiguriere ich meine Domain, um Berichte hierher zu senden?

A: Fügen Sie einen TXT-Eintrag bei _smtp._tls.ihredomain.com mit dem Wert v=TLSRPTv1; rua=https://api.captaindns.com/tls-rpt/ingest/{ihr-token} hinzu. Der genaue Eintrag wird bereitgestellt, wenn Sie Ihre Domain hinzufügen.


F: Welche Berichtsformate werden unterstützt?

A: Wir akzeptieren TLS-RPT-Berichte im JSON-Format gemäß RFC 8460, komprimiert (gzip) oder unkomprimiert. Berichte werden per HTTPS POST entgegengenommen.


F: Wie funktioniert die Domain-Verifizierung?

A: Sie fügen einen von CaptainDNS bereitgestellten Verifizierungs-TXT-Eintrag in Ihrem DNS hinzu. Sobald er erkannt wird, ist die Domain-Inhaberschaft bestätigt und das Monitoring wird aktiviert.


F: Brauche ich MTA-STS, um TLS-RPT zu nutzen?

A: Nein, TLS-RPT funktioniert unabhängig. Es wird jedoch empfohlen, MTA-STS mit TLS-RPT zu kombinieren: MTA-STS erzwingt die Verschlüsselung, TLS-RPT informiert Sie, wenn Sender diese nicht einhalten können.


F: Wie oft treffen Berichte ein?

A: Berichte werden innerhalb weniger Sekunden nach Empfang analysiert und in Ihrem Dashboard angezeigt. Die meisten E-Mail-Anbieter senden Berichte täglich.


F: Welche Risiken bestehen ohne TLS-RPT?

A: Ohne TLS-RPT erfahren Sie nicht, wenn E-Mails an Ihre Domain scheitern. Ein abgelaufenes Zertifikat kann tagelang unbemerkt bleiben. Nachrichten werden still abgewiesen oder unverschlüsselt übertragen. TLS-RPT macht diese Ausfälle sichtbar, bevor sie sich auf Ihre Kommunikation auswirken.


F: Welche TLS-Fehlertypen meldet TLS-RPT?

A: TLS-RPT deckt alle in RFC 8460 definierten Fehlertypen ab: starttls-not-supported, certificate-expired, certificate-host-mismatch, certificate-not-trusted, validation-failure, sts-policy-invalid, sts-webpki-invalid, tlsa-invalid und dane-required. Jeder Fehlertyp weist auf ein spezifisches Problem in der TLS-Aushandlung oder Richtlinienvalidierung hin.


F: Was ist der Unterschied zwischen TLS-RPT und DMARC?

A: TLS-RPT und DMARC schützen unterschiedliche Ebenen. DMARC (RFC 7489) prüft die Absender-Authentifizierung über SPF- und DKIM-Abgleich und bekämpft Spoofing und Phishing. TLS-RPT (RFC 8460) überwacht die Transportverschlüsselung und meldet, wenn SMTP-TLS-Verbindungen scheitern, Zertifikate ablaufen oder STARTTLS herabgestuft wird. Beide sind unverzichtbar.


Ergänzende Tools

ToolNutzen
TLS-RPT-SyntaxprüfungSyntax eines TLS-RPT-Eintrags validieren
TLS-RPT-EintragsprüfungDen TLS-RPT-DNS-Eintrag Ihrer Domain prüfen
TLS-RPT-GeneratorEinen TLS-RPT-DNS-Eintrag generieren
TLS-RPT-BerichtsleserEinen TLS-RPT-JSON-Bericht manuell analysieren
MTA-STS-HostingIhre MTA-STS-Richtlinie kostenlos hosten
DMARC-MonitoringDMARC-Aggregatberichte überwachen und analysieren

Nützliche Ressourcen