SMTP-TLS-Berichtsrichtlinie
DNS & Einträge
DNS-Abfrage Alle DNS-Einträge für jede Domain A-Eintrag-Abfrage IPv4-Adressen für eine Domain AAAA-Eintrag-Abfrage IPv6-Adressen für eine Domain MX-Abfrage Mailserver für eine Domain NS-Abfrage Autoritative Nameserver TXT-Abfrage TXT-Einträge, SPF, Verifizierung CNAME-Abfrage Kanonische Namen (Alias)-Einträge SOA-Abfrage Start-of-Authority-Eintrag SRV-Abfrage Dienst-Standort-Einträge CAA-Abfrage Welche CAs Zertifikate ausstellen dürfen Reverse DNS (PTR) IP-Adresse zu Hostname DNSSEC-Prüfung Ist die Domain signiert und validiert? DNS-Gesundheitscheck Ein vollständiger Bericht zu Delegierung & DNSE-Mail-Zustellbarkeit
SPF-Prüfung Validieren Sie Ihren Sender-Policy-Framework-Eintrag DMARC-Prüfung Untersuchen und bewerten Sie Ihre DMARC-Richtlinie DKIM-Prüfung Finden und validieren Sie Ihren öffentlichen DKIM-Schlüssel Blacklist-Prüfung Prüfen Sie eine IP gegen E-Mail-Sperrlisten (DNSBLs) SMTP-Test Mit einem Mailserver verbinden und STARTTLS prüfen MTA-STS-Prüfung Erzwungene TLS-Richtlinie für eingehende Mails BIMI-Prüfung Markenlogo-Eintrag für E-Mail TLS-RPT-Prüfung SMTP-TLS-BerichtsrichtlinieNetzwerk & Web
SSL-Zertifikat-Prüfung TLS-Zertifikat und Ablauf einer Website untersuchen HTTP-Header-Prüfung Antwort-Header, Weiterleitungen und Sicherheit untersuchen Ping (TCP) Erreichbarkeit und Latenz über TCP Port-Prüfung Welche gängigen Ports offen sindDomain
WHOIS-Abfrage Registrierungsdaten für Domains, IPs und ASNsTLS-RPT (SMTP TLS Reporting) erlaubt einer Domain, tägliche Berichte über TLS-Verbindungsfehler von sendenden Servern zu erhalten, sodass Sie erkennen können, wenn Mail unsicher zugestellt wird. IPeek liest den _smtp._tls-TXT-Record und zeigt die Berichtsziele. Es ergänzt MTA-STS und DANE, indem es Ihnen Einblick gibt, wie diese Richtlinien in der Praxis abschneiden.
TLS-RPT wird als einzelner DNS-TXT-Record unter _smtp._tls.ihre-domain veröffentlicht. Der Record enthält einen Versions-Tag und einen rua=-Tag, der auflistet, wohin Berichte gesendet werden sollen, entweder eine mailto-Adresse oder ein HTTPS-Endpunkt. Sendende Server, die den Standard unterstützen, aggregieren die Ergebnisse ihrer TLS-Aushandlungen mit Ihren MX-Hosts über einen Tag und liefern einen JSON-Bericht an diese Ziele. Jeder Bericht zählt erfolgreiche und fehlgeschlagene Sitzungen und kategorisiert Fehler, etwa Zertifikatsvalidierungsfehler oder nicht verfügbares STARTTLS, und gibt Ihnen so eine Rückmeldeschleife zur tatsächlichen Zustellung.
IPeek bestätigt, ob der _smtp._tls-TXT-Record existiert, und zeigt die rua-Ziele, die es analysiert. Verifizieren Sie, dass die Version TLSRPTv1 ist und dass jedes rua-Ziel ein gültiges Postfach oder eine HTTPS-URL ist, die Sie tatsächlich überwachen. Der Record selbst erzwingt nichts; er fordert nur Berichte an, sodass seine Präsenz bedeutet, dass Sender wissen, wohin sie TLS-Fehlerdaten senden. Sobald Berichte eintreffen, betrachten Sie die Fehlertypen: certificate-expired, Validierungsfehler und starttls-not-supported weisen jeweils auf eine bestimmte Behebung an Ihrer empfangenden Infrastruktur hin, bevor sie stille Zustellprobleme verursachen.
MTA-STS und DANE erzwingen TLS bei eingehender Mail, aber die Durchsetzung ist nur dann sicher, wenn Sie sehen können, was sie mit dem echten Verkehr macht. TLS-RPT liefert diese Sichtbarkeit: Wenn Sie MTA-STS im testing-Modus einsetzen, zeigen die Berichte, welche Sender TLS-Fehler treffen, bevor Sie zu enforce wechseln. Dasselbe gilt für DANE-TLSA-Abweichungen. Betrachten Sie TLS-RPT als die Überwachungsebene Ihrer TLS-Lage, eingesetzt neben – nicht anstelle – der Durchsetzungsmechanismen, sodass Sie Zertifikats- und Konfigurationsprobleme früh erkennen.
Es ist ein TXT-Record, der unter _smtp._tls.ihre-domain veröffentlicht wird und TLS-Fehlerberichte anfordert. Der Record enthält einen v=TLSRPTv1-Versions-Tag und einen rua=-Tag, der angibt, wohin Berichte gehen, als mailto-Adresse oder HTTPS-URL. Sendende Server, die TLS-RPT unterstützen, nutzen ihn, um zu wissen, wohin sie ihre täglichen aggregierten Berichte über TLS-Verbindungen zu Ihrer Domain liefern.
Ein TLS-RPT-Bericht ist ein JSON-Dokument, das einen Tag an TLS-Aushandlungen zwischen einem sendenden Server und Ihren MX-Hosts zusammenfasst. Er zählt erfolgreiche und fehlgeschlagene Sitzungen und schlüsselt Fehler nach Typ auf, etwa abgelaufene Zertifikate, Zertifikatsvalidierungsfehler oder nicht verfügbares STARTTLS. So können Sie genau bestimmen, welche empfangenden Hosts oder Zertifikate unsichere oder fehlgeschlagene Zustellungen verursachen.
Nein. TLS-RPT ist ein reiner Berichtsmechanismus und erzwingt von sich aus nichts. Die Durchsetzung kommt von MTA-STS oder DANE, die TLS verlangen und unsichere Zustellungen blockieren können. TLS-RPT steht neben diesen Richtlinien als Überwachungsebene und gibt Ihnen Einblick, wie oft TLS gelingt oder scheitert, sodass Sie die Durchsetzung sicher einsetzen können.
Veröffentlichen Sie einen TXT-Record unter _smtp._tls.ihre-domain, der v=TLSRPTv1 und einen rua=-Tag enthält, der auf ein Postfach oder einen HTTPS-Endpunkt verweist, den Sie überwachen, zum Beispiel rua=mailto:tlsrpt@ihre-domain. Wählen Sie ein Ziel, das Sie tatsächlich beobachten, da Berichte täglich als JSON eintreffen. Kombinieren Sie es mit MTA-STS oder DANE, damit die Berichte beschreiben, wie Ihre durchgesetzte TLS-Richtlinie abschneidet.
TLS-RPT liefert die Sichtbarkeit, die MTA-STS sicher einsetzbar macht. Wenn Sie eine MTA-STS-Richtlinie im testing-Modus veröffentlichen, melden sendende Server etwaige TLS-Fehler über TLS-RPT, sodass Sie sehen, welche Sender blockiert würden, bevor Sie zu enforce wechseln. Die beiden sind dafür ausgelegt, zusammenzuarbeiten: MTA-STS setzt die Richtlinie, und TLS-RPT sagt Ihnen, wie sie in der Praxis abschneidet.