MX-Eintrag funktioniert nicht: So findest und behebst du Fehler im Mail-Routing

Wenn ein MX-Eintrag nicht funktioniert, steckt fast immer eine von fünf Ursachen dahinter: ein CNAME als Ziel statt eines Hostnamens mit A/AAAA-Eintrag, ein Tippfehler oder fehlender Schlusspunkt im Ziel, falsche oder doppelte Prioritätswerte, übrig gebliebene Einträge eines früheren Mail-Providers oder DNS-Änderungen, die sich schlicht noch nicht verbreitet haben. Zustellprobleme bedeuten selten, dass das DNS „kaputt“ ist. Meist passt ein einzelner Eintrag nicht zu dem, was der sendende Mailserver erwartet. Diese Anleitung geht jede Ursache durch und zeigt dir, wie du sie überprüfst.

Was ein MX-Eintrag eigentlich macht

Ein MX-Eintrag (Mail Exchange) teilt sendenden Mailservern mit, welcher Host E-Mails für deine Domain annimmt. Jeder MX-Eintrag besteht laut RFC 1035 aus zwei Teilen: einer Preference (oft Priorität genannt) und einem Exchange (dem Hostnamen des Mailservers). Niedrigere Preference-Werte werden zuerst versucht: Ein MX mit Preference 10 wird vor einem mit Preference 20 verwendet.

Eine entscheidende Regel aus RFC 5321 (dem SMTP-Standard) und RFC 2181: Das MX-Ziel muss auf einen A- oder AAAA-Eintrag auflösen, niemals auf einen CNAME und niemals auf eine nackte IP-Adresse. Zeigt dein MX auf einen Alias, lehnen manche empfangenden und sendenden Server ihn direkt ab oder verhalten sich unvorhersehbar. Allein diese Fehlkonfiguration steckt hinter einem großen Teil der Tickets à la „Mail funktioniert nicht“.

Schritt 1: Den Live-Eintrag abfragen, nicht dein Control Panel

Das Dashboard deines Registrars kann dem hinterherhinken, was tatsächlich im Internet veröffentlicht ist. Frag das DNS direkt ab:

dig MX yourdomain.com

oder

nslookup -type=MX yourdomain.com

Beide umgehen deinen lokalen Cache und fragen direkt einen Resolver ab, sodass du siehst, was Mailserver weltweit tatsächlich sehen. Ohne Terminal geht es auch mit unserem kostenlosen MX-Lookup-Tool. Das ist der schnellste Weg, um zu prüfen, was aktuell veröffentlicht ist, bevor du irgendetwas änderst.

TipPrüfe MX immer mit einem externen Tool oder aus einem anderen Netzwerk. Ein Eintrag kann im Büro-WLAN (das die alte Antwort zwischengespeichert hat) korrekt aussehen, während der Rest des Internets bereits den neuen sieht – oder umgekehrt.

Häufige Ursache 1: MX zeigt auf einen CNAME

Wenn dig MX ein Ziel zurückgibt, das selbst einen CNAME-Eintrag hat – zum Beispiel mail.yourdomain.com als CNAME auf ghs.example.net –, ist das laut RFC 1035/5321 ungültig. Behebe das, indem du den MX-Eintrag direkt auf einen Hostnamen mit eigenem A/AAAA-Eintrag zeigen lässt oder den kanonischen Hostnamen deines Mail-Providers verwendest (den dieser auf seiner Seite bereits korrekt eingerichtet hat).

Häufige Ursache 2: Schlusspunkt oder Tippfehler im Hostnamen

In einer rohen Zonendatei muss ein vollqualifizierter Domainname mit einem Punkt enden (mail.yourdomain.com.). Fehlt er, hängt manche DNS-Software stillschweigend deine Domain an und erzeugt etwas Kaputtes wie mail.yourdomain.com.yourdomain.com.. Die meisten modernen Registrar-Dashboards ergänzen den Schlusspunkt automatisch. Wenn du Zonendateien aber direkt bearbeitest (oder unser DNS-Management mit manueller Eingabe nutzt), solltest du den genauen Wert, den dein Provider verlangt, noch einmal prüfen.

Prüfe außerdem:

• Das Host/Name-Feld steht bei Mails für die Root-Domain auf @ (oder bleibt leer), nicht auf mail oder dem wiederholten vollständigen Domainnamen.
• Der Ziel-Hostname enthält keine verirrten Leerzeichen und entspricht exakt dem, was dein Mail-Provider vorgegeben hat.

Häufige Ursache 3: Falsche oder doppelte MX-Priorität

Prioritätswerte (Preference) steuern die Failover-Reihenfolge, nicht welcher Eintrag namentlich der „primäre“ ist. Ein Setup wie dieses ist gültig und üblich:

Sendende Server versuchen zuerst Priorität 10 und weichen nur auf 20 aus, wenn dieser nicht erreichbar ist. Probleme entstehen, wenn:

• zwei Einträge dieselbe Priorität haben, obwohl sie es nicht sollten – dann verteilt sich die Mail zufällig auf beide, statt in der richtigen Reihenfolge auszuweichen.
• ein stillgelegter Server eine niedrigere Zahl (also höhere Priorität) behält als der aktive, sodass Absender immer zuerst den toten Host versuchen.

Google Workspace empfiehlt inzwischen einen einzigen MX-Eintrag – smtp.google.com mit Priorität 1 – anstelle des älteren Setups mit mehreren ASPMX.L.GOOGLE.COM-Einträgen. Microsoft 365 erzeugt bei der Domainverifizierung automatisch einen Eintrag, typischerweise yourdomain-com.mail.protection.outlook.com mit Priorität 0. Wenn deine Einträge nicht zum aktuell dokumentierten Setup deines Providers passen, liegt genau dort dein Problem.

Häufige Ursache 4: Alte Einträge vom vorherigen Provider

Ein sehr häufiger Fehler beim Umzug: Du wechselst von deinem alten Hoster zu Google Workspace oder Microsoft 365, legst die neuen MX-Einträge an, löschst die alten aber nie. Jetzt sind die MX-Einträge zweier Provider gleichzeitig aktiv, und Mails werden aufgeteilt oder abgewiesen – je nachdem, welche Priorität gewinnt. Lass dir immer alle MX-Einträge der Domain anzeigen und lösche alles, was nicht zu deinem aktuellen Provider gehört.

Häufige Ursache 5: Verzögerung bei der DNS-Propagation

Wenn der Eintrag korrekt ist, Mails aber trotzdem Probleme machen, prüf die TTL (Time to Live) des Eintrags. Manche Resolver speichern Antworten bis zum Ablauf ihrer TTL zwischen, auch wenn du längst eine Korrektur veröffentlicht hast, und bestimmte Caching-Ebenen halten sie sogar länger, unabhängig von einer niedrigeren TTL, die du gesetzt hast. Warte das TTL-Fenster ab, bevor du annimmst, dass die Korrektur nicht gegriffen hat, und prüf erneut mit einem externen Lookup-Tool statt mit deinem eigenen Browser oder Mail-Client, die womöglich einen veralteten lokalen Cache nutzen.

Gar kein MX-Eintrag – ist das zulässig?

Ja, in einem bestimmten Fall. RFC 7505 definiert den Null MX: einen einzelnen Eintrag mit Preference 0 und dem Ziel . (ein einzelner Punkt), der Absendern ausdrücklich mitteilt: „Diese Domain nimmt keine Mails an, bitte nicht erneut versuchen.“ Das ist für Domains gedacht, die nur für Websites und nicht für E-Mail genutzt werden – keine Fehlkonfiguration, wenn du ihn bewusst setzt.

Gibt es tatsächlich weder einen MX-Eintrag noch einen Null MX, sollen Absender laut RFC 5321 auf den A/AAAA-Eintrag der Domain als impliziten Mailhost zurückgreifen. Auf diesen Fallback zu setzen ist jedoch fragil und wird von neueren Mailsystemen zunehmend nicht mehr unterstützt. Verlass dich nicht darauf, sondern lege einen expliziten MX oder einen Null MX an.

MX sieht korrekt aus, aber Mails kommen trotzdem nicht an

Wenn dig MX genau das liefert, was du erwartest, und die Prioritäten sinnvoll sind, liegt der Fehler meist nach dem Routing, nicht im MX-Eintrag selbst:

• Fehlender oder falscher SPF-Eintrag, wodurch empfangende Server Mails ablehnen oder als Spam markieren – siehe unseren Leitfaden zum Erstellen eines sicheren SPF-Eintrags.
• Fehlende DKIM-Signatur.
• Eine Firewall auf dem Mailserver, die Port 25 oder 587 blockiert.

Das sind Zustellbarkeitsprobleme, keine MX-Probleme, aber für Endnutzer sehen sie identisch aus („E-Mail funktioniert nicht“) – es lohnt sich, sie auszuschließen, sobald der MX-Eintrag selbst in Ordnung ist. Wie MX mit A, TXT, CAA und anderen Eintragstypen zusammenspielt, erfährst du in unserem Leitfaden zu DNS-Eintragstypen.

Was die Bounce-Meldungen bedeuten

Mailserver melden MX-Probleme mit eigenen Worten, und genau dieser Text ist meist das, wonach Leute suchen. Die zwei häufigsten:

"No MX record found for domain=example.com; reason=empty DNS record" – der sendende Server hat das DNS nach den MX-Einträgen der Empfängerdomain gefragt und eine gültige, aber leere Antwort erhalten. Das DNS hat funktioniert; die Domain veröffentlicht einfach keine Mail-Route. Typische Ursachen:

• Die Adresse enthält einen Tippfehler, oder die Domain empfängt überhaupt keine Mails.
• Die MX-Einträge sind bei einem DNS-Umzug verloren gegangen: Sie existieren noch beim alten Provider, aber die Nameserver zeigen jetzt auf einen neuen, bei dem niemand sie neu angelegt hat.
• Die Adresse liegt auf einer Subdomain (user@mail.example.com). MX-Einträge werden nicht vererbt, die Subdomain braucht also einen eigenen MX, auch wenn die übergeordnete Domain einen hat.
• Die Domain veröffentlicht absichtlich einen Null MX (siehe oben), den manche Server auf dieselbe Weise melden.

Prüf das mit dig MX example.com +short und dig NS example.com +short. Eine leere MX-Antwort von den Nameservern, an die die Domain tatsächlich delegiert ist, bestätigt es. Lege den MX dort an, nicht bei dem Provider, bei dem du zuletzt etwas bearbeitet hast.

"Temporary error looking up MX record … timed out" – hier ist die Abfrage selbst gescheitert: Es kam überhaupt keine Antwort zurück. Das deutet auf die Nameserver der Domain hin, nicht auf ihre Einträge – sie sind ausgefallen, nicht erreichbar, oder die Delegation nennt Server, die die Zone nicht mehr ausliefern. Eine kaputte DNSSEC-Kette hat denselben Effekt: Validierende Resolver liefern SERVFAIL. Absender behandeln das als vorübergehend und versuchen es einige Tage lang erneut, Mails werden also verzögert statt verloren – bis die Wiederholungsversuche ausgeschöpft sind. Frag jeden Nameserver direkt ab (dig @ns1.example.net MX example.com), um den zu finden, der nicht antwortet.

Checkliste zur schnellen Diagnose

• Führe dig MX yourdomain.com aus oder nutze das MX-Lookup-Tool – prüfe, was tatsächlich veröffentlicht ist.
• Stelle sicher, dass der Ziel-Hostname kein CNAME ist und auf einen A/AAAA-Eintrag auflöst.
• Achte beim Bearbeiten roher Zonendateien auf Probleme mit dem Schlusspunkt.
• Prüfe, ob die Prioritätswerte zum aktuell dokumentierten Setup deines Providers passen und keine verwaisten Duplikate existieren.
• Entferne alte MX-Einträge früherer Mail-Provider.
• Warte nach einer Änderung das TTL-Fenster ab, bevor du erneut testest.

Wenn du DNS für mehrere Domains bei verschiedenen Registraren verwaltest, wird es mit jeder weiteren Domain schwieriger, MX, SPF und andere Mail-Einträge konsistent zu halten. Mit unserem DNS-Management prüfst und bearbeitest du Einträge über alle Provider hinweg an einem Ort, statt ihnen einzeln hinterherzujagen.