ExchangeServer

MX-Record (Mail Exchanger)

Allgemeine Infos

Der MX-Record (Mail Exchanger) ist ein DNS-Eintragstyp, der für eine Domäne die Server nennt, die E-Mails für sie annehmen. SMTP nutzt ihn nach RFC 5321 (Oktober 2008), um den nächsten Zielserver einer Nachricht zu ermitteln. Jeder Eintrag besteht aus einem Präferenzwert und einem Hostnamen; der sendende Server versucht den Eintrag mit dem niedrigsten Wert zuerst und weicht auf höhere Werte aus, wenn dieser nicht erreichbar ist.

In Exchange-Umgebungen entscheidet der MX über den Eingangsweg: Er zeigt auf den eigenen Exchange- oder Edge-Server, auf einen vorgeschalteten Filterdienst oder auf Exchange Online. Im Hybridbetrieb setzt der Hybrid Configuration Wizard den MX nicht. Microsoft empfiehlt, ihn auf Microsoft 365 zeigen zu lassen, weil nur dann die Cloud-Schutzfunktionen auch lokale Postfächer abdecken können.

Aktuelle Änderung bei Exchange Online: Microsoft stellt MX-Ziele unter mx.microsoft bereit, etwa contoso-com.o-v1.mx.microsoft, weil diese Zone DNSSEC-signiert ist und damit Inbound SMTP DANE ermöglicht (allgemein verfügbar seit Oktober 2024). Laut MC1048624 erhalten neue akzeptierte Domänen solche Ziele seit Juli 2026 automatisch, bestehende Domänen wechseln per Enable-DnssecForVerifiedDomain. Den korrekten Wert liefern das Exchange Admin Center oder die Graph-API serviceConfigurationRecords, er lässt sich nicht aus dem Domänennamen ableiten.

Abgrenzung: DNS beschreibt den Namensdienst allgemein. SPF, DKIM und DMARC nutzen TXT-Einträge zur Absenderprüfung, sie legen nicht fest, wohin Mails zugestellt werden. Exchange Mailflow und akzeptierte Domänen beschreiben, was nach der Ankunft am Server passiert.

Funktionsweise & Details

Die Zustellung an eine Domäne läuft so ab:

  1. Der sendende Mailserver fragt per DNS die MX-Records der Empfängerdomäne ab, zum Beispiel contoso.com MX 0 contoso-com.o-v1.mx.microsoft.
  2. Er sortiert die Einträge nach Präferenz; der niedrigste Wert hat die höchste Priorität.
  3. Er löst den Hostnamen des gewählten Eintrags per A- oder AAAA-Record in eine IP-Adresse auf und baut eine SMTP-Verbindung auf Port 25 auf.
  4. Ist die Domäne DNSSEC-signiert und hat der MX-Host einen TLSA-Record, validiert der Absender per DANE (RFC 7672) zusätzlich das TLS-Zertifikat des Zielservers.
  5. Scheitert die Verbindung, versucht der Absender den nächsten Eintrag oder stellt die Mail später erneut zu.

Für Exchange Online beschreibt Microsoft die Umstellung so: Enable-DnssecForVerifiedDomain liefert den neuen Wert (DnssecMxValue), der neue MX kommt zunächst mit Priorität 20 dazu, nach erfolgreichem Test erhält er Priorität 0, der alte Eintrag unter mail.protection.outlook.com wird gelöscht und die TTL auf 3.600 Sekunden gesetzt. Danach aktiviert Enable-SmtpDaneInbound die TLSA-Records.

Vorteile & Nutzen

  • Mehrere MX-Records mit abgestuften Präferenzen sorgen für Ausfallsicherheit, weil sendende Server bei Störungen automatisch auf den nächsten Eintrag ausweichen.
  • Der Eingangsweg lässt sich ohne Eingriff in Exchange umstellen, etwa von lokal auf Exchange Online oder auf einen Filterdienst, weil nur der DNS-Eintrag wechselt.
  • Mit DNSSEC und DANE wird der MX zur Vertrauensbasis für eine verschlüsselte Zustellung, die gegen Downgrade- und Man-in-the-Middle-Angriffe geschützt ist.
  • Eine kurze TTL während der Umstellung beschleunigt den Wechsel, weil Resolver alte Einträge schneller verwerfen.

Praxisbeispiel

Ein Elektrotechnik-Betrieb mit 70 Postfächern hat seine Postfächer per Hybrid nach Exchange Online migriert, der MX zeigt aber noch auf den lokalen Exchange-Server. Die IT senkt einen Tag vor der Umstellung die TTL, setzt den MX auf das Ziel aus dem Exchange Admin Center und kontrolliert den Eingang per Message Trace. Später signiert sie die Zone beim DNS-Anbieter mit DNSSEC, ruft per Enable-DnssecForVerifiedDomain den neuen mx.microsoft-Wert ab, ergänzt ihn mit Priorität 20, tauscht nach dem Test die Prioritäten und entfernt den alten Eintrag. Seitdem kommen Mails von DANE-fähigen Absendern nur noch über zertifikatsvalidierte TLS-Verbindungen an.

Worauf sollte man achten?

  • Vor einer MX-Änderung die TTL rechtzeitig senken; Microsoft empfiehlt bei der DANE-Umstellung die niedrigste mögliche TTL, aber nicht unter 30 Sekunden, und danach 3.600 Sekunden.
  • MX-Werte für Exchange Online nicht aus einem Namensmuster zusammenbauen, sondern aus dem Exchange Admin Center oder der Graph-API serviceConfigurationRecords übernehmen, weil neue Domänen seit Juli 2026 Ziele unter mx.microsoft erhalten.
  • Connectoren und Smarthost-Einträge, die auf den alten MX-Hostnamen zeigen (etwa contoso-com.mail.protection.outlook.com), vor der DNSSEC-Umstellung anpassen; Microsoft empfiehlt dafür den onmicrosoft.com-Namen des Tenants.
  • Inbound DANE setzt voraus, dass ein vorgeschalteter Filterdienst selbst DANE und DNSSEC beherrscht; onmicrosoft.com-Domänen und Self-Service-Domänen werden nicht unterstützt.
  • Im Hybridbetrieb den MX bewusst setzen: Zeigt er auf Microsoft 365, kann für den Schutz lokaler Postfächer das Built-in security add-on for on-premises mailboxes nötig sein.

Fazit

Der MX-Record ist der Wegweiser für jede eingehende Mail und gehört in jede Mailflow-Dokumentation. Plane Änderungen mit kurzer TTL und nutze bei Exchange Online die Umstellung auf mx.microsoft, um DNSSEC und DANE einzuführen.

Weiterführende Links

Verwandte Artikel