MX-Record

Ein MX-Record (Mail Exchanger Record, deutsch MX-Eintrag) ist ein Eintrag im Domain Name System (DNS), der festlegt, an welchen Mailserver E-Mails für eine Domain zugestellt werden. Schreibt jemand an info@beispiel.de, fragt sein Mailserver den MX-Record von beispiel.de ab und liefert die Nachricht an den dort genannten Server. Für Unternehmen mit Microsoft 365 entscheidet dieser eine Eintrag darüber, ob E-Mails in Exchange Online ankommen, beim alten Anbieter landen oder gar nicht zugestellt werden.

Was ist ein MX-Record?

Der MX-Eintrag ist die Postanschrift Ihrer Domain für E-Mails. Er besteht aus zwei Angaben: einer Priorität (auch Präferenz genannt) und dem Namen des Zielservers. Nach RFC 5321, dem Standard für den Mailtransport per SMTP (Simple Mail Transfer Protocol), muss das Ziel ein Hostname sein, zu dem ein A- oder AAAA-Eintrag mit IP-Adresse gehört. Eine IP-Adresse oder ein Alias über einen CNAME-Record ist als Ziel nicht vorgesehen.

Priorität: Die kleinere Zahl gewinnt

Bei mehreren MX-Einträgen versucht der sendende Server zuerst den mit der kleinsten Zahl und, falls dieser nicht erreichbar ist, den nächsten. Bei gleicher Zahl verteilt er die Mails zufällig. Gibt es nur einen MX-Eintrag, ist der Wert gleichgültig.

MX-Record in Microsoft 365

Den passenden Wert zeigt das Microsoft 365 Admin Center unter Settings > Domains (Einstellungen > Domänen) bei der jeweiligen Domain unter DNS records. Der vordere Teil, von Microsoft MX-Token genannt, entspricht meist der Domain mit Bindestrichen statt Punkten. Als Priorität gibt Microsoft die höchste an, also meist 0, als TTL (Time to Live, die Zeit, die andere Server den Eintrag zwischenspeichern) 3600 Sekunden. Exchange Online unterstützt nur TTL-Werte unter sechs Stunden.

Typ        MX
Name       @
Priorität  0
TTL        3600
Ziel       beispiel-de.mail.protection.outlook.com

Kopieren Sie den Wert immer aus dem Admin Center, statt ihn selbst zusammenzusetzen. In älteren Anleitungen tauchen auch Token der Form MSxxxxxxx auf.

Neueres Format mit DNSSEC: mx.microsoft

Seit dem 28. Oktober 2024 bietet Exchange Online für eingehende Mails SMTP DANE mit DNSSEC allgemein an. DNSSEC signiert DNS-Antworten kryptografisch, sodass sie sich nicht unbemerkt fälschen lassen. DANE (DNS-based Authentication of Named Entities) baut darauf auf: Der sendende Server prüft über einen TLSA-Eintrag im DNS das Zertifikat des Empfängerservers und schützt so vor Abhören und herabgestufter Verschlüsselung. Wer DNSSEC für eine Domain in Exchange Online aktiviert, erhält einen MX im neuen Format:

Typ        MX
Name       @
Priorität  0
TTL        3600
Ziel       beispiel-de.o-v1.mx.microsoft

Den Teil zwischen MX-Token und mx.microsoft, im Beispiel „o-v1“, vergibt Microsoft. Er lässt sich nicht aus dem Domainnamen ableiten. Auch neuere Domains können einen MX auf mx.microsoft erhalten. Den vollen Sicherheitsgewinn gibt es nur, wenn Ihre DNS-Zone beim DNS-Anbieter ebenfalls mit DNSSEC signiert ist.

Umgestellt wird in Exchange Online PowerShell mit zwei Befehlen:

Enable-DnssecForVerifiedDomain -DomainName beispiel.de
Enable-SmtpDaneInbound -DomainName beispiel.de

Die Reihenfolge laut Microsoft: TTL des alten MX senken (nicht unter 30 Sekunden), mit dem ersten Befehl den neuen MX-Wert abrufen, neuen MX mit Priorität 20 ergänzen und testen, Rangfolge tauschen (neu 0, alt 30), alten MX löschen und erst dann mit dem zweiten Befehl DANE einschalten. Wer MTA-STS nutzt (eine Richtlinie, mit der eine Domain verschlüsselte Zustellung vorschreibt), stellt sie vorher auf „testing“. Für onmicrosoft.com-Domains wird DNSSEC nicht unterstützt.

MX-Eintrag bei der Migration umstellen

Beim Wechsel zu Exchange Online, etwa von IONOS zu Exchange Online oder von STRATO zu Exchange Online, wechselt mit dem MX der Mailfluss auf das neue System. Nach den Migrationsanleitungen von Microsoft gilt diese Reihenfolge:

1. TTL früh senken: Setzen Sie die TTL des bestehenden MX vor Beginn der Migration auf 3600 Sekunden oder weniger. Absender übernehmen den neuen Wert dann schneller.
2. Postfächer zuerst: Legen Sie Benutzer und Postfächer in Microsoft 365 an, bevor der MX umgestellt wird. Sonst kommen Mails an Adressen, die es im neuen System noch nicht gibt, nicht an.
3. Neuen MX eintragen: Wert aus dem Admin Center übernehmen, Priorität 0.
4. Alte MX entfernen: Sobald Mails in Exchange Online ankommen, löschen Sie die Einträge, die auf das alte System zeigen.
5. Übergang abwarten: Beenden Sie die Synchronisation mit dem alten System erst, wenn alle Absender den neuen MX kennen.

Vorgeschaltete Spamfilter und Gateways

Microsoft empfiehlt, den MX direkt auf Microsoft 365 zeigen zu lassen, weil die Spamfilter dann am zuverlässigsten arbeiten. Häufig steht aber ein Spamfilter oder E-Mail-Gateway eines Drittanbieters davor, also ein Server, der Mails prüft und an den Microsoft-Hostnamen weiterreicht. Das wird unterstützt. Wichtig sind dabei diese Punkte:

• Enhanced Filtering for Connectors einschalten: Damit erkennt Microsoft 365 den ursprünglichen Absender hinter dem Filter. Ohne diese Einstellung scheinen alle Mails vom Filter zu kommen, SPF, DKIM und DMARC werden nicht richtig ausgewertet, und die DMARC-Richtlinien fremder Absender greifen nicht. Das schwächt den Schutz vor E-Mail-Spoofing.
• Direktzustellung sperren: Absender können den MX umgehen und Microsoft 365 direkt ansprechen. Ein Partner-Connector in Exchange Online, der nur Mails vom Filter annimmt (erkennbar an dessen Zertifikat oder IP-Adressen), schließt diese Lücke.
• DNSSEC trotz Gateway: Tragen Sie im Gateway den neuen Zielnamen auf mx.microsoft ein. Abgesichert ist die Strecke vom Gateway zu Exchange Online aber nur, wenn das Gateway selbst DANE mit DNSSEC prüft.

Typische Fehler beim MX-Eintrag

Ein falscher MX-Eintrag fällt oft erst spät auf, weil der Versand weiter funktioniert, nur der Empfang nicht. Die häufigsten Ursachen:

• Zwei MX zu verschiedenen Systemen: Bleibt der alte Anbieter mit größerer Zahl stehen, landen Mails dort, sobald Microsoft 365 für einen Absender kurz nicht erreichbar ist. Bei gleicher Zahl geht ein Teil zufällig an das alte System, in Postfächer, die niemand mehr liest.
• MX zeigt noch auf den alten Anbieter: Neue Mails kommen weiter dort an oder werden abgewiesen, sobald die alten Postfächer gekündigt sind.
• Kein MX-Eintrag: Absender weichen laut RFC 5321 auf die IP-Adresse der Domain selbst aus, meist auf den Webserver, der in der Regel keine Mails annimmt. Soll eine Domain gar keine Mails empfangen, zeigt das ein Null-MX nach RFC 7505 eindeutig an: ein MX-Eintrag mit Priorität 0 und einem einzelnen Punkt als Ziel.
• Tippfehler im Ziel: Ein selbst zusammengesetzter oder falsch kopierter Hostname existiert nicht. Absender können dann nicht zustellen und erhalten eine Unzustellbarkeitsnachricht.
• Punkt am Ende: Manche DNS-Anbieter verlangen einen abschließenden Punkt hinter dem Hostnamen, andere lehnen ihn ab.

Praxis-Tipp: Notieren Sie vor jeder Änderung alle MX-Einträge mit Priorität und TTL. Prüfen Sie danach, was tatsächlich öffentlich im DNS steht, etwa mit unserem Microsoft 365 DNS-Checker, statt nur in der Oberfläche Ihres DNS-Anbieters.

Typische Fragen zum MX-Record

Brauche ich einen zweiten MX als Ausfallsicherung?

Nein. Microsoft empfiehlt genau einen MX zu einem System, weil Microsoft 365 selbst mehrfach redundant ausgelegt ist. Kann ein Absender vorübergehend nicht zustellen, stellt sein Server die Nachricht in eine Warteschlange und versucht es später erneut.

Muss ich auf das Format mx.microsoft umstellen?

Für bestehende Domains kündigt Microsoft bisher keine Pflicht zur Umstellung an, der Eintrag auf mail.protection.outlook.com funktioniert weiter. Sinnvoll ist der Wechsel, wenn Sie eingehende Mails zusätzlich mit DNSSEC und DANE absichern wollen.

Was hat der MX-Record mit SPF, DKIM und DMARC zu tun?

Der MX regelt nur den Eingang. Welche Server im Namen Ihrer Domain senden dürfen, steht im SPF-Eintrag. Mit DKIM werden ausgehende Mails signiert, und DMARC legt fest, was mit Mails geschieht, die keine der beiden Prüfungen passend bestehen. Ein korrekter MX schützt also nicht vor gefälschten Absendern.

Wie lange dauert es, bis ein neuer MX-Eintrag wirkt?

Das hängt von der TTL des alten Eintrags ab, so lange dürfen andere Server den alten Wert zwischenspeichern. Microsoft rechnet mit bis zu 72 Stunden, bis alle Mailsysteme von Kunden und Partnern den geänderten MX kennen.

MX-Record mit CodeKlar einrichten

Wir richten die DNS-Einträge für Microsoft 365 sauber ein, und zwar nicht nur den MX: Wir erfassen alle Systeme, die im Namen Ihrer Domain Mails versenden, bereinigen den SPF-Eintrag, aktivieren DKIM und führen DMARC stufenweise bis zur Richtlinie reject ein. Danach übernehmen wir das DMARC-Tracking: Wir werten die Berichte laufend aus, finden vergessene Versender und melden Ihnen Auffälligkeiten.

Mehr dazu lesen Sie auf unseren Seiten zu Exchange Online und zu Security und Compliance in Microsoft 365. Wie Ihre Domain heute dasteht, zeigt der kostenlose Microsoft 365 DNS-Checker sofort.