Eingaben
Beispiel
example.com -> MX-Hosts, STARTTLS-Banner und Zertifikatsabgleich, MTA-STS-Policy-Abgleich, TLS-RPT, optionale DANE-Hinweise und FCrDNS-Bestätigung.
SMTP-TLS-Handshake / Mail-Domain-Empfangsbereitschaft
Bewertet MX, STARTTLS, Zertifikatsabgleich, MTA-STS, TLS-RPT sowie optionale DANE- und FCrDNS-Hinweise.
Nutze es, um die SMTP-Transport-Security-Evidenz einer Mail-Domain für die Empfangsbereitschaft zu prüfen.
Eine Probe, die ganze Empfangsgeschichte
Wenn ein anderer Betreiber fragt, ob deine Domain Mail sicher empfangen kann, umfasst die ehrliche Antwort ein halbes Dutzend Mechanismen: MX-Routing, STARTTLS auf den Exchangern, Zertifikate, die zu den richtigen Namen passen, und — wo deployed — MTA-STS, TLS-RPT, DANE und forward-confirmed Reverse DNS. Jeder hat sein eigenes Tool; Zustellprobleme entstehen aber aus der Kombination. Eine gültige MTA-STS-Policy, die auf einen Exchanger mit unpassendem Zertifikat zeigt, ist zwei grüne Checks und ein kaputtes Deployment.
Dieser Checker fährt die Kombination als einen Readiness-Report: Er löst effektive MX-Ziele einschließlich RFC-5321-Implicit-MX ohne MX-RRset auf und versucht für jede aufgelöste öffentliche A- und AAAA-Adresse jedes ausgewählten Exchangers eine eigene STARTTLS-Session. Er bewahrt Zertifikatsevidenz pro Adresse und legt — wenn aktiviert — strikte MTA-STS-WebPKI-/SAN-Validierung, gültiges TLS-RPT, DANE/TLSA-Vergleich aus jeder Adress-Session und FCrDNS-Roundtrips mit kanonischen IPs darüber. Die Trust-Modi bleiben getrennt; eine grüne Schicht löscht keinen Fehler einer anderen.
Checks in der Reihenfolge schichten, in der Sender sie erleben
Fahre zuerst den Basis-Check: MX plus STARTTLS liefert begrenzte diagnostische Transportevidenz. Aktiviere MTA-STS, wenn die Frage WebPKI-Chain- und SAN-Identitätsbeweis verlangt, und nur die weiteren Schichten, die wirklich zum Scope gehören. Eine nicht ausgewählte fehlende Policy ist kein Fehler: Eine Domain ohne DANE ist nicht kaputt, sie hat DANE nur nicht deployed.
Lies Befunde so, wie ein Sender sie erlebt. Ein Zertifikats-Mismatch auf dem ersten MX-Host blockiert MTA-STS und andere WebPKI-Identitätsprüfungen, während die DANE-Behandlung von der Certificate Usage abhängt; ein fehlender TLSA-Record betrifft nur DANE-validierende Sender, und ein Reverse-DNS-Mismatch kostet vor allem Reputationspunkte bei großen Providern. Diese Reihenfolge ist deine Prioritätenliste. Nach jeder Änderung — neue Zertifikate, neue MX-Hosts, eine Policy-Anpassung — den ganzen Satz erneut fahren, denn diese Schichten referenzieren einander über Namen, und Drift zwischen ihnen ist der Standard-Fehlermodus.
Probe-Grenzen und ehrlicher Scope
Live-Checks laufen nur auf Anforderung über geschützte Helper: DNS-Abfragen, die feste MTA-STS-Policy-URL ohne Redirect und SMTP-Proben zu öffentlichen MX-Hosts auf Port 25 mit kurzen Timeouts, begrenzt auf die ersten drei Exchanger. Innerhalb dieser ausgewählten Exchanger wird jede aufgelöste öffentliche IPv4- und IPv6-Adresse versucht. Eine nicht versuchte Adresse hält die Coverage incomplete, ohne einen STARTTLS-, Zertifikats-, MTA-STS-, DANE- oder FCrDNS-Fehler zu erfinden; ein realer Protokollfehler einer versuchten Adresse wird als solcher ausgegeben. TLS-RPT validiert einen nutzbaren Record und dessen Zielsyntax, beweist aber keine Report-Zustellung. Die Probe beobachtet einen Netzwerkpfad zu einem Zeitpunkt und niemals Ende-zu-Ende-Mailzustellung.
Häufige Fragen
Warum sind die Policy-Checks optional?
Weil nicht jede Domain MTA-STS, TLS-RPT, DANE oder sauberes FCrDNS publiziert und deren Fehlen ein Deployment-Status ist, kein Defekt. Die explizite Aktivierung verhindert, dass ein reiner STARTTLS-Check kaputt aussieht, nur weil eine Schicht nicht adoptiert wurde.
Beweist eine bestandene STARTTLS-Probe sichere Zustellung?
Nein. Sie beweist, dass der geprobte Host auf diesem Pfad in diesem Moment TLS angeboten und ausgehandelt hat. Echte Sender nehmen andere Routen, retrien anders oder erzwingen Policies, die diese Probe nicht ausgeübt hat — starke Evidenz, keine Garantie.
Warum muss das Zertifikat zum MX-Host passen?
MTA-STS verlangt eine vertrauenswürdige WebPKI-Kette und eine passende SAN-DNS-Identität für den ausgewählten MX-Host. Bei DANE hängen die Identitätsanforderungen von der Certificate Usage ab; eine gültige DANE-EE-Association mit Usage 3 benötigt weder PKIX- noch Zertifikatsnamensprüfung.
Was bringt FCrDNS für Mail-Readiness?
Es bestätigt, dass die PTR-Namen der MX-Adressen vorwärts wieder auf dieselben Adressen auflösen. TLS hängt nicht daran, aber große Empfänger nutzen es als Reputationssignal — ein Mismatch ist billig zu beheben, bevor er Zustellbarkeit kostet.
Wie viele MX-Hosts probt der Check?
Der Live-Helper begrenzt sich bewusst auf die ersten Exchanger nach Präferenz, mit kurzen Timeouts. Das hält den Check gebunden und höflich und deckt trotzdem die Hosts ab, die echte Sender zuerst versuchen würden.
Der Report ist grün, Mail scheitert trotzdem — wo weiter?
Dann ist Transport vermutlich nicht dein Problem. Weiter zur Authentifizierungsschicht — SPF, DKIM, DMARC samt Alignment — und zu echter Evidenz: Message-Header einer gescheiterten Zustellung und deine TLS-RPT-Reports, die Fehlerklassen benennen, die dieser Schnappschuss nicht sehen kann.