MX-Eintrag einrichten: so finden E-Mails an deine Domain ihr Ziel

Wenn jemand eine Mail an info@beispiel.de schreibt, muss der Server des Absenders herausfinden, wohin er sie schicken soll. Er fragt dazu im DNS nach dem MX-Eintrag der Domain beispiel.de. MX steht für Mail Exchanger. Fehlt der Eintrag oder zeigt er auf den falschen Server, kommen Mails verspätet, gar nicht oder beim alten Anbieter an. Dieser Ratgeber zeigt, wie der Eintrag aufgebaut ist, wie du ihn setzt und woran es typischerweise hakt. Den größeren Zusammenhang mit SPF, DKIM und DMARC erklärt der Bereich E-Mail mit eigener Domain absichern.

Aufbau eines MX-Eintrags

Ein MX-Eintrag hat zwei Bestandteile: eine Präferenz, meist Priorität genannt, und den Namen eines Hosts, der Mails für die Domain annimmt. Die Priorität ist eine Zahl von 0 bis 65535 (16 Bit), und kleinere Werte werden bevorzugt ^[1]. In der Verwaltungsoberfläche deines DNS-Anbieters sieht ein Eintrag etwa so aus:

Das "@" steht für die Domain selbst. Manche Oberflächen erwarten das Feld leer oder den vollen Domainnamen. Einige Registrare verlangen beim Ziel einen Punkt am Ende, also mx1.mailanbieter.example. mit Schlusspunkt ^[5].

Wie ein sendender Server den Eintrag auswertet

RFC 5321, der Standard für den Mailtransport per SMTP, beschreibt den Ablauf genau ^[2]. Der sendende Server sucht zuerst nach MX-Einträgen der Zieldomain. Findet er mehrere, sortiert er sie nach Priorität und versucht die Server mit der kleinsten Zahl zuerst. Haben mehrere Einträge dieselbe Priorität, muss er zufällig zwischen ihnen wählen, damit sich die Last verteilt. Er soll mindestens zwei Adressen probieren, bevor er aufgibt.

Gibt es gar keinen MX-Eintrag, behandelt der Server die Domain so, als hätte sie einen MX-Eintrag mit Priorität 0, der auf sie selbst zeigt. Er stellt dann an die IP-Adresse aus dem A- oder AAAA-Eintrag der Domain zu ^[2]. Sobald aber mindestens ein MX-Eintrag existiert, darf er die Adresseinträge der Domain nur noch über die MX-Ziele nutzen. Meldet das DNS, dass die Domain nicht existiert, ist das ein Fehler. Bei einem vorübergehenden DNS-Fehler muss der Server die Mail in die Warteschlange legen und es später erneut versuchen ^[2].

Zwei Einträge mit unterschiedlicher Priorität ergeben also einen Hauptserver und einen Ausweichserver. Zwei Einträge mit gleicher Priorität teilen sich die eingehenden Mails ungefähr gleichmäßig.

Ausweichserver mit höherer Zahl

Ein zweiter MX-Eintrag mit größerer Zahl soll Mails annehmen, wenn der Hauptserver nicht erreichbar ist. RFC 5321 regelt, was ein solcher Ausweichserver tun muss: Er sortiert die MX-Einträge der Domain, sucht sich selbst darin und verwirft alle Einträge mit gleicher oder schlechterer Priorität. Übrig bleiben die besseren Server, an die er die Mail weiterreicht. Bleibt keiner übrig, muss er die Mail als unzustellbar zurückgeben ^[2].

Ein Ausweichserver ist also nur nützlich, wenn er für deine Domain eingerichtet ist und Mails zwischenspeichern und weiterleiten kann. Ein beliebiger zweiter Server, der deine Domain nicht kennt, lehnt die Mails ab. Google nennt für Workspace nur einen einzigen MX-Eintrag ^[5].

Was als Ziel erlaubt ist

Das Ziel eines MX-Eintrags muss ein Hostname sein, der selbst mindestens einen A- oder AAAA-Eintrag hat ^[2]. Zwei Dinge sind deshalb falsch, kommen aber immer wieder vor:

• Eine IP-Adresse als Ziel. Das Feld erwartet einen Domainnamen ^[1].
• Ein Hostname, der nur ein Alias ist, also einen CNAME-Eintrag hat. RFC 2181 sagt dazu klar, dass der Name im MX-Eintrag kein Alias sein darf. Beim Nachschlagen eines MX-Eintrags liefert der Nameserver die Adressen des Ziels gleich mit, CNAME-Ketten aber nicht. Das kostet zusätzliche Abfragen und kann im Einzelfall scheitern ^[3].

Wenn dein Mailanbieter dir einen Hostnamen vorgibt, übernimmst du ihn genau so. Richtest du einen eigenen Namen wie mail.beispiel.de ein, bekommt dieser einen A-Eintrag mit der IP-Adresse des Servers. Betreibst du den Mailserver selbst, gehört zu dieser IP-Adresse auch ein passender Reverse-DNS-Eintrag.

Schritt für Schritt: MX-Eintrag setzen

Der Ablauf ist bei fast allen DNS-Anbietern gleich, nur die Namen der Menüpunkte unterscheiden sich. Microsoft nennt als übliche Bezeichnungen etwa Zonendateieinstellungen, Domänen verwalten oder DNS-Manager ^[4]. Unterstützt dein Registrar das Verfahren Domain Connect, kann Microsoft 365 die nötigen Einträge nach deiner Zustimmung sogar selbst anlegen. Andernfalls trägst du sie von Hand ein ^[4].

1. Postfächer beim neuen Anbieter anlegen. Microsoft rät ausdrücklich, Benutzer und Postfächer einzurichten, bevor der MX-Eintrag geändert wird, damit keine Mail ins Leere geht ^[4].
2. Die Werte des Mailanbieters notieren: Zielhost und empfohlene Priorität.
3. In der DNS-Verwaltung der Domain einen Eintrag vom Typ MX für "@" anlegen.
4. Alte MX-Einträge entfernen, die auf den früheren Anbieter zeigen. Microsoft lässt alternativ zu, den alten Eintrag mit schlechterer Priorität (größerer Zahl) stehen zu lassen ^{[4, 5]}.
5. Speichern und abwarten. Google nennt bis zu 72 Stunden, bis neue MX-Einträge überall erkannt werden ^[5]. Wie lange es im Einzelfall dauert, hängt von der TTL des alten Eintrags ab.
6. Mit dem DNS-Check prüfen, ob der neue Eintrag ausgeliefert wird, und eine Testmail von einer fremden Adresse schicken.

Werte der großen Anbieter

Für Google Workspace lautet der MX-Eintrag smtp.google.com mit Priorität 1. Google verlangt, alle anderen MX-Einträge zu entfernen, weil alte oder falsche Einträge den Mailempfang stören können. Als TTL nennt Google den Standardwert des Registrars oder den Wert 1 ^[5].

Bei Microsoft 365 kopierst du den Zielwert aus dem Admin Center, weil er je Domain unterschiedlich ist. Die Priorität soll auf den höchsten verfügbaren Wert gesetzt werden, in der Regel 0, die TTL auf 3600 Sekunden (eine Stunde). Exchange Online unterstützt laut Microsoft nur TTL-Werte unter sechs Stunden (21.600 Sekunden) ^[4].

Ältere Empfehlungen sahen für MX-Einträge sehr lange TTL-Werte vor. RFC 1912 von 1996 nannte für die MX-, A- und PTR-Einträge des Mailservers ein bis zwei Wochen ^[8]. Mit den Vorgaben heutiger Anbieter passt das nicht mehr zusammen, Microsoft etwa akzeptiert für Exchange Online weniger als sechs Stunden ^[4].

Bei Hostern mit eigenem Mailangebot trägt die Verwaltungsoberfläche den MX-Eintrag meist selbst ein, solange die Domain dort auch im DNS liegt. Hast du die Nameserver geändert, etwa zu einem CDN, musst du die Mail-Einträge in der neuen Zone von Hand nachtragen.

Domains, die keine Mails empfangen

Viele Domains empfangen nie Mails, etwa reine Weiterleitungsdomains. Ohne MX-Eintrag versuchen sendende Server trotzdem, an den Webserver zuzustellen, weil die Regel mit dem gedachten MX-Eintrag greift ^[2]. Für diesen Fall gibt es den Null-MX-Eintrag aus RFC 7505: ein einziger MX-Eintrag mit Priorität 0 und einem einzelnen Punkt als Ziel. Da ein Punkt kein gültiger Hostname ist, kann er nicht mit einem normalen Eintrag verwechselt werden. Neben einem Null-MX darf die Domain keinen weiteren MX-Eintrag haben ^[6].

Typische Fehler und ihre Folgen

• Alter und neuer Anbieter mit gleicher Priorität: Sendende Server verteilen die Mails dann zufällig auf beide ^[2]. Ein Teil der Post landet beim alten Anbieter.
• Tippfehler im Zielhost oder fehlender Punkt am Ende, wo der Registrar ihn verlangt: In Zonendateien gilt ein Name ohne Schlusspunkt als relativ und wird um den Namen der Zone ergänzt ^[1]. Aus dem Ziel wird dann etwa smtp.google.com.beispiel.de.
• MX-Eintrag auf einer Subdomain statt auf der Domain: Ein Eintrag für mail.beispiel.de gilt für Adressen wie name@mail.beispiel.de, nicht für name@beispiel.de.
• Ziel ohne A- oder AAAA-Eintrag: Der MX-Eintrag ist dann nicht nutzbar, und RFC 5321 verlangt, das als Fehler zu melden ^[2].
• Ein zweiter SPF-Eintrag beim Anbieterwechsel: Microsoft verlangt, keinen neuen SPF-Eintrag anzulegen, wenn schon einer existiert. Am Ende soll ein einziger Eintrag stehen, der die Werte des alten und des neuen Anbieters enthält ^[4].
• Sehr lange TTL kurz vor einem Umzug: Resolver halten den alten Eintrag so lange fest, wie die TTL erlaubt. Wer umziehen will, senkt die TTL einige Tage vorher.

Dass Mails ankommen, aber beim Empfänger im Spam landen, liegt meist an fehlender Absenderprüfung. Die Ursachen dafür stehen auf Eigene E-Mails landen im Spam. Wer sich als Empfänger über unerwünschte Post ärgert, findet Hilfe auf Spam-Mails: woher sie kommen und was dagegen hilft.

1. Gesetz RFC 1035: Domain Names, Implementation and Specification. IETF. Stand November 1987. abgerufen am 29.10.2026
2. Gesetz RFC 5321: Simple Mail Transfer Protocol, Abschnitt 5.1. IETF. Stand Oktober 2008. abgerufen am 29.10.2026
3. Gesetz RFC 2181: Clarifications to the DNS Specification, Abschnitt 10.3. IETF. Stand Juli 1997. abgerufen am 29.10.2026
4. Organisation Verbinden Ihrer Domäne durch Hinzufügen von DNS-Einträgen. Microsoft. Stand 23.04.2026. abgerufen am 29.10.2026
5. Organisation MX-Einträge für Google Workspace einrichten. Google. Stand ohne Datum. abgerufen am 29.10.2026
6. Gesetz RFC 7505: A "Null MX" No Service Resource Record for Domains That Accept No Mail. IETF. Stand Juni 2015. abgerufen am 29.10.2026
7. Gesetz RFC 7208: Sender Policy Framework (SPF), Abschnitt 10.1.2. IETF. Stand April 2014. abgerufen am 29.10.2026
8. Gesetz RFC 1912: Common DNS Operational and Configuration Errors, Abschnitt 2.2. IETF. Stand Februar 1996. abgerufen am 29.10.2026

Zuletzt geprüft am 29.10.2026, nächste Prüfung spätestens im Oktober 2027. Fehler entdeckt? Schreib uns.