MX-Record-Prüfung
Liest die Live-MX-Reihenfolge, löst Exchanger-Adressen auf und markiert Null-MX-, CNAME- und tote Routingziele.
E-Mail-SicherheitMX-Architektur planen: Präferenzen, Kapazität und sichere Migration
Ein MX-RRset ist keine dekorative Serverliste. Es ist der Ausfallplan, den fremde Sender ohne Rückfrage ausführen — deshalb muss jede Präferenz und jedes angebliche Backup einen vollständigen, belastbaren Zustellweg beschreiben.
Präferenz ist Failover, keine Prozentangabe
Die MX-Präferenz bestimmt eine Reihenfolge: Kleine Zahlen kommen zuerst. Mit 10 mx1.example.net. und 20 mx2.example.net. bestellst du also keine Lastverteilung im Verhältnis zwei zu eins. Du sagst Sendenden, dass sie mx1 bevorzugen und erst bei Nichterreichbarkeit oder temporärer Ablehnung auf mx2 ausweichen sollen. Wann und wie oft ein fremder MTA neu versucht, entscheidet dessen Queue — MX garantiert weder sofortiges noch überall gleiches Umschalten.
Gleiche Präferenzen ermöglichen eine grobe Verteilung. Bei zwei erreichbaren Hosts mit Wert 10 darf ein Sender frei wählen; viele randomisieren, aber DNS ist kein Load-Balancer mit garantiertem 50/50-Split. Plane jeden gleichrangigen Host für Schieflast und Spitzen. Filter, Empfängerwissen, Queueing und Weiterleitung müssen austauschbar sein. Ein gemeinsamer Anycast-Dienst kann darunter verteilen, ändert aber nichts an der MX-Semantik und braucht eine eigene Ausfallanalyse. Die MX-Record-Prüfung sortiert das veröffentlichte Set und löst die ersten Exchanger auf — damit siehst du zunächst genau die Anweisung, die draußen ankommt.
Das Backup-MX, das den Ausfall verschlimmert
Ein höher priorisiertes, also später versuchtes Backup hilft nur als echter Mail-Eingang. Es braucht aktuelle Empfängerprüfung, vergleichbare Abuse-Kontrollen, genug Queue-Speicher, funktionierende Weiterleitung und Monitoring bis ins Zielpostfach. Ein Host, der TCP annimmt, akzeptierte Nachrichten aber nicht zustellen kann, ist keine Redundanz, sondern eine Verlustmaschine mit Verzögerung. Ein totes Backup bleibt noch länger unbemerkt: Erst die Störung des Primärwegs schickt das gesamte Problem in den vergessenen Zweig.
Schwach gefilterte Backups sind zudem klassische Spam-Magneten. Angreifer sprechen absichtlich den MX mit der schlechteren Präferenz an, weil alte Installationen dort häufiger großzügig relayn, jeden Local Part akzeptieren oder den Primärfilter umgehen. Das erzeugt Backscatter, volle Queues und einen Nebenweg um deine teuer gepflegten Kontrollen. Greylisting und verzögerte Annahme dürfen sich ebenfalls nicht so unterscheiden, dass legitime Sender zwischen den Wegen pendeln. Kann ein Provider Empfänger- und Missbrauchsregeln nicht gleichwertig durchsetzen, entferne den Record. Ein ehrlicher, gesunder Zustellweg ist sicherer als aufgemalte Hochverfügbarkeit.
Null MX: bewusst nicht empfangen
Eine Domain, die niemals Mail annehmen soll, darf das eindeutig erklären: example.com. MX 0 .. Dieser Null-MX-Record sagt konformen Sendenden, dass für die Domain kein SMTP-Dienst existiert. So entfallen sinnlose Adress-Fallbacks und wiederholte Verbindungsversuche; zugleich wird die betriebliche Absicht prüfbar. Das passt zu geparkten Domains, reinen Infrastruktur-Namen und dedizierten Versanddomains, deren Konzept Antworten ausdrücklich ausschließt.
Null MX gehört nicht neben gewöhnliche Exchanger. MX 0 . und MX 10 mail.example.com. zusammen sind ein Widerspruch, kein raffinierter Notaus-Schalter. Setze Null MX auch nicht für eine vorübergehende Plattformstörung ein: Sender dürfen daraus eine dauerhafte Nichtzustellbarkeit ableiten und sofort ablehnen. Eine spätere Rückkehr zum Mailbetrieb ist deshalb ein geplanter Produktwechsel, keine spontane DNS-Korrektur. Inventarisiere vorher Reply-Adressen, Bounces, Zertifikatskontakte und alte Aliase. „Wir betreiben keine Postfächer“ beweist noch lange nicht, dass niemand an diese Domain schreibt.
MX-Ziele sind Hosts, keine Aliase
Ein MX-Ziel muss einen Host mit Adressrecords benennen; ein CNAME an dieser Stelle verletzt die Standards. Manche Resolver und MTAs folgen der Alias-Kette trotzdem — genau deshalb überlebt der Fehler einfache Tests. Andere lehnen sie ab, cachen einen unglücklichen Zwischenstand oder reagieren anders, sobald sich die Kette ändert. Übrig bleiben partnerabhängige Ausfälle: die unangenehmste Sorte, weil erfolgreiche Zustellung eines großen Providers das Design scheinbar entlastet.
Gib jedem Exchanger einen stabilen kanonischen Namen mit direkten A- und, falls wirklich bedient, AAAA-Records. Diese Namen werden zugleich Zertifikatsidentitäten, MTA-STS-Muster, TLSA-Owner, Logschlüssel und Monitoring-Ziele. Ein beiläufiges Rename reicht deshalb weit über den MX-RRset hinaus. Publiziere IPv6 nur, wenn Firewall, Listener, Zertifikat und Monitoring dort denselben Dienst wie über IPv4 sehen. Wenn DNS stimmt, prüft die SMTP-TLS-Handshake / Mail-Domain-Empfangsbereitschaft die ersten Exchanger begrenzt live und vergleicht STARTTLS-Zertifikate mit den tatsächlichen MX-Hostnamen.
Bei Migrationen Wege hinzufügen, dann entfernen
Ein sicherer Providerwechsel ist eine Überlappung, kein DNS-Sprung. Richte zuerst jede Domain, jeden Empfänger, Alias, Routingweg, jedes Größenlimit und jede Abuse-Regel am neuen Edge ein. Teste Weiterleitung und echte Nachrichten in beide Richtungen. Danach veröffentlichst du neue und alte Exchanger gemeinsam — den neuen zunächst mit schlechterer Präferenz, wenn die Plattform einen sauberen Pilotbetrieb zulässt. So wird der Fallback real benutzt, ohne sofort zum Normalweg zu werden. Benennen Policy-Schichten die MX-Hosts, müssen sie den Neuzugang vorher abdecken.
Anschließend machst du das neue Set bevorzugt und behältst den alten Weg lange genug für DNS-Caches und fremde Mailqueues. Beobachte Annahmelogs, Queues, Bounces und TLS-Reports; die TTL allein ist keine Wartezeit, denn ein Sender kann bereits gegen eine ältere Antwort queueen. Definiere vorab ein Rollback, das Routing und alle referenzierenden Policies gemeinsam zurücksetzt. Erst danach entfernst du die alten MX-Records. Lass den früheren Dienst für ein begrenztes Rückbau-Fenster späte Eingänge weiterleiten. Eine rechtzeitig gesenkte TTL beschleunigt neue Abfragen, leert aber keinen bereits gefüllten Cache.
Die Abhängigkeiten als ein System betreiben
Dokumentiere das Soll-Set mit Owner, Präferenz, Adressfamilien, Zertifikatsnamen, Kapazitätsrolle und Policy-Abdeckung. Jede Produktionsänderung wird dagegen geprüft. Ein Exchanger ist nicht bereit, nur weil DNS ihn findet: Port 25 muss antworten, Empfängerregeln müssen stimmen, STARTTLS eine brauchbare Identität liefern und MTA-STS oder DANE dürfen nicht widersprechen. Authentifizierung ist eine andere Schicht. Der SPF/DMARC/DKIM-Prüfer untersucht, wie angenommene und versandte Mail bewertet wird, repariert aber kein defektes Inbound-Routing.
Teste schließlich den Fehlerfall statt die Redundanz auf dem Papier zu bewundern. Nimm in einem kontrollierten Zeitfenster den bevorzugten Weg heraus, lass mehrere externe Sender zustellen und verfolge Nachrichten bis zum Ziel. Messe dabei auch Verzögerung und Deduplizierung; „kam irgendwann an“ ist für zeitkritische Mail kein vollständiger Erfolg. Alarme gehören auf unerreichbare MX-Hosts, Adressdrift, Zertifikatserneuerung, Queue-Tiefe und Policy-Mismatch. Die brauchbare Betriebsregel ist knapp: Jeder publizierte Host ist ein Versprechen an Fremde. Kannst du dieses Versprechen nicht fortlaufend belegen, publiziere ihn nicht.