SMTP-TLS-Handshake / Mail-Domain-Empfangsbereitschaft
Verbindet MX, begrenzte STARTTLS- und Zertifikatsproben mit optionaler Policy- und FCrDNS-Evidenz.
E-Mail-SicherheitMail-Empfangsbereitschaft Ende zu Ende auditieren
Eine empfangende Domain ist erst bereit, wenn jeder von strikten Sendern wählbare Weg die ganze Kette von DNS bis zu authentifiziertem TLS übersteht. Einzelne grüne Checks sind billig; belastbar ist nur die Übereinstimmung von MX, Zertifikaten, Policy und Hostidentität.
Nimm die Perspektive des Senders ein
Beginne mit der Domain und ohne internes Vorwissen. Ein fremder MTA löst MX auf, ordnet nach Präferenz, ermittelt die Adressen der Exchanger, verbindet sich auf Port 25, liest die SMTP-Fähigkeiten und handelt eventuell STARTTLS aus. Ein strikter Sender prüft danach, ob Zertifikat und veröffentlichte Transport-Policy genau den gewählten Weg autorisieren. Dass mx-old intern „fast abgeschaltet“ heißt oder nächste Woche ein Zertifikat bekommt, weiß er nicht. Publizierter Zustand ist Vertrag.
Halte Evidenz pro Exchanger fest, nicht als pauschales Domainurteil: Präferenz, Adressen, Verbindung, Banner, STARTTLS-Ankündigung, ausgehandeltes Protokoll, Zertifikatsnamen und Laufzeit, MTA-STS-Abdeckung, TLSA-Ergebnis sowie PTR mit Vorwärtsbestätigung. Notiere zusätzlich Resolver, Messstandort und Uhrzeit, damit ein späterer Vergleich nicht scheinbar identische Beobachtungen vermischt. Die SMTP-TLS-Handshake / Mail-Domain-Empfangsbereitschaft liefert dafür einen begrenzten Außenblick. Ihre Grenze gehört ins Protokoll: erste Exchanger, ein Netzpfad, ein Zeitpunkt. Ein Betriebsaudit ergänzt Wiederholungen und echte Senderdaten.
Erstes Gate: Führt DNS zu einem Empfänger?
Löse den autoritativen MX-RRset auf und sortiere korrekt: kleinere Präferenz zuerst, gleiche Werte als alternative Normalwege. Jedes Ziel muss ein Hostname statt eines CNAME sein und auf Adressen zeigen, an denen du absichtlich SMTP anbietest. Prüfe beide publizierten Adressfamilien. Ein kaputtes AAAA ist keine harmlose Dekoration; IPv6-bevorzugende Sender erleben Verzögerung oder Ausfall, während ein reiner IPv4-Test grün bleibt. Nimm jedes Backup auf, denn genau im Störungsfall wird es angesprochen.
DNS-Fehler stehen am Fundament. Null MX erklärt, dass die Domain keine Mail annimmt; eine Mischung aus Null MX und normalen Zielen ist widersprüchlich. NXDOMAIN, ein alter Providerhostname oder ein unerreichbares Backup zerstören den Weg, bevor TLS überhaupt beginnt. Prüfe Delegation und Antworten über mehr als einen autoritativen Server, denn Zonendrift kann nur einen Teil der Welt treffen. Sichere TTLs und autoritative Antworten und vergleiche sie mit dem Soll-Inventar. Nur den rekursiven Cache zu befragen kann einen Teil-Rollout verbergen; nur autoritativ zu schauen unterschlägt, was Sender noch gecacht haben.
Zweites Gate: STARTTLS und Zertifikatsidentität
Verbinde dich mit jeder Adresse und sende EHLO. STARTTLS muss konsistent angeboten werden, der Handshake mit unterstütztem Protokoll und Cipher gelingen. Entscheidend ist die Identitätsprüfung gegen den per MX ausgewählten Hostnamen, nicht bloß gegen die Empfängerdomain. Ein Zertifikat für mail.example.com authentifiziert mx.provider.net nur, wenn auch dieser Providername enthalten ist. Prüfe Gültigkeitsfenster, Chain, Trust Anchor und Intermediates aus einem sauberen externen Client.
Priorisiere harte Verbindungsfehler, fehlendes STARTTLS bei bestehender Policy und Namens- oder Chainfehler auf bevorzugten MX-Hosts. Sie blockieren jeden Sender, der auf diesem Weg verifizierbares TLS verlangt. Protokollkosmetik folgt später. Prüfe Clusterknoten und IP-Adressen getrennt; ein Load-Balancer kann einen defekten Knoten hinter mehreren erfolgreichen Handshakes verstecken. Trenne außerdem einen einmaligen Probe-Fehler von reproduzierbarer Evidenz: Wiederhole über einen zweiten Pfad und prüfe Serverlogs, bevor du eine Ursache benennst. Gesucht ist nicht der Screenshot eines Erfolgs, sondern der Nachweis, dass jeder veröffentlichte Weg die Identität der nächsten Schicht liefert.
Drittes Gate: Policy muss die Live-Wege beschreiben
MTA-STS ergänzt eine per HTTPS geladene und über _mta-sts angekündigte Policy. Im Modus enforce müssen ihre mx:-Muster jeden legitimen Exchanger abdecken; diese Hosts brauchen öffentlich validierbares TLS. Prüfe TXT-id, feste Policy-URL, Syntax, Modus, max_age und Abdeckung gemeinsam. Der MTA-STS-Prüfer/Generator vergleicht diese Flächen. Gegen einen neuen MX, den der Change-Prozess vergessen hat, kann aber kein Parser helfen.
DANE nutzt einen anderen Vertrauenspfad und bindet härter. Für SMTP liegen TLSA-Records unter Namen wie _25._tcp.mx1.example.net, also unter dem Exchanger, und zählen nur mit validiertem DNSSEC. Der DANE-Validator bewertet Ownername, TLSA-Parameter, DNSSEC-Kontext und optionale Zertifikatsevidenz als eine Bindung. Prüfe bei mehreren TLSA-Records, ob mindestens ein aktueller Wert passt und der zusätzliche Wert tatsächlich einem geplanten Rollover dient. Ein alter Digest nach Schlüsselwechsel ist für validierende Sender keine Warnung, sondern ein Ablehnungsgrund. Daher wird jeder MX-Host einzeln auditiert.
FCrDNS ist Reputation, nicht TLS
Löse für jede Exchanger-Adresse PTR auf, danach den erhaltenen Hostnamen wieder vorwärts, und bestätige die ursprüngliche Adresse in diesem Ergebnis. Das ist Forward-confirmed Reverse DNS. Richte Banner und HELO-Namen nach Möglichkeit auf eine schlüssige betriebliche Identität aus. FCrDNS authentifiziert jedoch kein STARTTLS-Zertifikat, und SMTP-Transportsicherheit hängt nicht davon ab. Wer beide Befunde vermischt, repariert in der falschen Reihenfolge.
Trotzdem ist der Check relevant. Große Betreiber nutzen kohärentes Reverse DNS als Reputationssignal; Abweichungen verraten oft hastige IP-Wechsel oder generische Cloud-Pools. Prüfe auch, ob der PTR-Name betrieblich dir gehört und nicht bloß zufällig wieder auf die Adresse zeigt. Behebe fehlende oder widersprüchliche PTR-Daten nach zustellungsblockierenden Transportfehlern — außer ein bekannter Partner lehnt bereits aus Reputationsgründen ab. Beachte die Zuständigkeit: Meist kontrolliert der Adressprovider die Reverse-Zone, dein DNS-Team die Vorwärtsrecords. Ein Ticket, das nur auf einer Seite geschlossen wurde, ist keine Reparatur.
Befunde nach Wirkung und Drift ordnen
Nutze eine betriebliche Reihenfolge. Erstens: kein brauchbarer MX-Weg, Connection Refused oder DNS ins Nichts. Zweitens: STARTTLS- oder Zertifikatsfehler auf einem bevorzugten Weg, wenn strikter Transport erwartet wird. Drittens: erzwungenes MTA-STS oder authentifiziertes DANE widerspricht dem Live-Server. Viertens: Fehler nur auf Backup oder einer Adressfamilie. Fünftens: FCrDNS und Hygiene. Neben der Schwere zählt die Breite: Ein kaputter gleichrangiger Host kann viel Verkehr treffen, obwohl sein Partner perfekt ist.
Der normale Fehlermodus heißt Drift zwischen den Schichten. Eine Migration ändert MX, aber nicht MTA-STS; ein Renewal rotiert den DANE-gebundenen Key; IPv6 landet auf einem älteren TLS-Terminator; der Provider benennt Hosts um, während PTR und Monitoring alt bleiben. Verknüpfe deshalb jeden Change mit den Namen und Policies, die er indirekt berührt, statt Teams getrennt abzeichnen zu lassen. Baue das Audit um Quervergleiche statt unabhängige Checklisten. Wiederhole es nach DNS-, Zertifikats-, Policy-, Netz- und Provideränderungen und behalte die vorige Matrix zum Diff. Ein Readiness-Urteil ohne Zeitpunkt und getestetes Host-Set altert sofort.