Was ist ein MX Record? MX-Einträge einfach erklärt (2026)

Was ist ein MX Record? Ein MX Record (auf Deutsch meist MX-Eintrag, MX steht für Mail Exchange) ist ein Eintrag im DNS, der festlegt, welcher Server die E-Mails für eine Domain annimmt. Wenn jemand an hallo@getmind.io schreibt, fragt sein Mailserver zuerst das DNS: „Wer nimmt Post für getmind.io an?” Die Antwort ist der MX Record. Ohne ihn weiß der Absender nicht, wohin er die Nachricht schicken soll.

Damit ist der MX-Eintrag so etwas wie der Briefkasten-Hinweis an einer Haustür. Die Website einer Domain kann auf einem ganz anderen Server liegen als das Postfach, und genau das regelt der MX Record: Er trennt „wo wohnt die Website” von „wo kommt die Post an”.

Wir betreiben mehrere Domains und mindestens einen eigenen Mailserver, und wir wollten es für diesen Artikel genau wissen. Am 10. November 2026 haben wir von unserem Produktionsserver (Hetzner, Ubuntu 24.04) die MX-Einträge von neun großen Mailanbietern und unseren eigenen Domains abgefragt und mit unserem eigenen Postfix-Mailserver getestet, was passiert, wenn etwas fehlt. Drei Befunde vorweg:

1. Gmail hat fünf MX-Einträge mit fünf verschiedenen Prioritäten, Outlook.com genau einen. Beide funktionieren zuverlässig, weil hinter dem einen Outlook-Namen vier IP-Adressen stehen.

2. Zwei unserer eigenen Domains haben gar keinen MX Record. Mails dorthin gehen trotzdem nicht ins Leere, sondern an die IP der Website. Und dort lief bei uns tatsächlich ein Mailserver, der sie abweisen musste.

3. example.com sagt mit einem Null-MX (0 .) ausdrücklich „hier gibt es keine Post”. Unser eigener Mailserver hat daraufhin eine Testmail mit diesem Absender sofort abgelehnt.

Wenn du DNS insgesamt noch nicht im Kopf hast: In unserem Artikel Was ist DNS? erklären wir Resolver, Nameserver und TTL von Grund auf. Hier geht es nur um den einen Eintrag, an dem deine E-Mails hängen.

Was ist ein MX Record genau? Aufbau eines MX-Eintrags

Ein MX Record besteht aus vier Teilen. So sieht unser eigener aus, abgefragt mit dig:

$ dig MX getmind.io +noall +answer
getmind.io.    300    IN    MX    10 ff-web.de.

Von links nach rechts:

Zwei Dinge fallen auf, die Einsteiger oft überraschen.

Erstens steht im MX Record keine IP-Adresse, sondern ein Hostname. Der absendende Server muss danach noch einmal nachfragen, welche Adresse ff-web.de hat. Bei uns ist das 89.22.110.102. Ein MX-Eintrag, der direkt eine IP enthält, ist laut Standard ungültig. Manche Admin-Oberflächen nehmen das trotzdem an, und dann wundert man sich, warum ein Teil der Mails nicht ankommt.

Zweitens hat der MX Record eine Zahl vor dem Ziel. Das ist die Priorität, auch Preference genannt. Sie ist der Grund, warum ein MX Record mehr ist als ein Wegweiser: Er kann eine ganze Reihenfolge aus Haupt- und Ersatzservern beschreiben.

Wie läuft die Zustellung einer E-Mail ab?

Wenn du in Gmail an hallo@getmind.io schreibst, passiert grob Folgendes:

1. Gmails Server nimmt den Teil nach dem @, also getmind.io.
2. Er fragt das DNS nach dem MX Record dieser Domain und bekommt 10 ff-web.de.
3. Er fragt nach der IP-Adresse von ff-web.de (A- und AAAA-Eintrag) und bekommt 89.22.110.102.
4. Er baut eine Verbindung auf Port 25 auf und spricht SMTP mit diesem Server.
5. Der Zielserver prüft Absender, Empfänger, SPF, DKIM und Spam und nimmt die Mail an oder lehnt sie ab.

Schritt 4 haben wir für diesen Artikel einmal von Hand nachgestellt. Unser Mailserver meldet sich so:

$ (Verbindung zu ff-web.de auf Port 25)
220 ff-web.de ESMTP Postfix
EHLO test.getmind.io
250-ff-web.de
250-PIPELINING
250-SIZE 1024000000
250-STARTTLS
250-AUTH DIGEST-MD5 CRAM-MD5 PLAIN LOGIN
250-ENHANCEDSTATUSCODES
250-8BITMIME
250 CHUNKING

Das ist genau der Server, auf den unser MX Record zeigt. Er bietet STARTTLS an, also eine verschlüsselte Verbindung, und erlaubt Mails bis etwa 1 GB. Der MX Record selbst sagt über all das nichts. Er ist nur die Adresse. Was hinter der Tür passiert, entscheidet der Mailserver.

Wichtig: Der MX Record betrifft nur eingehende Mails. Welcher Server in deinem Namen Mails verschicken darf, regeln andere Einträge, nämlich SPF, DKIM und DMARC. Dazu weiter unten mehr.

MX Record Priorität: Was bedeuten die Zahlen 5, 10 oder 20?

Hat eine Domain mehrere MX-Einträge, entscheidet die Priorität über die Reihenfolge. Die Regel ist simpel: Die kleinste Zahl wird zuerst probiert. Erreicht der Absender diesen Server nicht, nimmt er den nächsthöheren. Haben mehrere Einträge dieselbe Zahl, verteilt der Absender die Mails zufällig zwischen ihnen.

Die Zahlen selbst haben keine Bedeutung, nur ihr Verhältnis. 10 und 20 funktionieren genauso wie 1 und 2 oder 100 und 200. Dass man oft in Zehnerschritten arbeitet, hat einen praktischen Grund: Man kann später einen Server dazwischenschieben, ohne alles neu zu nummerieren.

Neun Mailanbieter im Vergleich

Wie machen das die Großen? Wir haben am 10. November 2026 die MX-Einträge von neun bekannten Anbietern abgefragt. Die TTL stammt jeweils direkt vom zuständigen Nameserver, nicht aus einem Zwischenspeicher.

Daraus lassen sich drei Strategien ablesen.

Die Kaskade (Gmail, Proton Mail): Ein Hauptserver mit der kleinsten Zahl, dahinter Ersatzserver mit steigenden Zahlen. Gmail treibt das mit fünf Stufen auf die Spitze. Fällt gmail-smtp-in.l.google.com (Priorität 5) aus, geht es mit alt1 (10) weiter, dann alt2 (20) und so fort.

Die Gleichverteilung (WEB.DE, GMX, T-Online, Posteo, iCloud): Mehrere Server mit derselben Zahl. Absender verteilen die Last zufällig, und fällt einer aus, nimmt man einfach einen anderen aus der Gruppe. Das ist Lastverteilung und Ausfallsicherheit in einem.

Die Mischform (mailbox.org): Vier gleichwertige Server mit 10 und ein fünfter mit 50 als letzte Rettung, falls alle vier gleichzeitig ausfallen.

Ein einzelner MX Record ist nicht automatisch ein Risiko

Outlook.com kommt mit genau einem MX-Eintrag aus. Klingt riskant, ist es aber nicht. Wir haben nachgesehen: Der Name outlook-com.olc.protection.outlook.com löst zu vier verschiedenen IP-Adressen auf. Die Ausfallsicherheit steckt hier nicht in mehreren MX-Einträgen, sondern in mehreren A-Einträgen hinter einem Namen. Ein absendender Server probiert sie nacheinander durch.

Für eine kleine Firma oder ein privates Projekt ist das die wichtigste Erkenntnis: Ein einziger MX Record reicht völlig, solange dein Mailanbieter dahinter ordentlich aufgestellt ist. Unser eigener Eintrag 10 ff-web.de ist auch nur einer. Einen zweiten, schlecht gepflegten Backup-MX hinzuzufügen, macht die Sache oft schlechter statt besser. Dazu gleich mehr.

Die Reihenfolge in der DNS-Antwort ist egal

Ein Detail, das wir selbst nachgemessen haben: Wir haben den Resolver 1.1.1.1 zwanzigmal hintereinander nach den MX-Einträgen von Gmail gefragt und jeweils notiert, welcher Eintrag in der Antwort oben stand. Ergebnis: Mal war es alt1 (Priorität 10), mal alt3 (30), mal der eigentliche Hauptserver (5). Die Reihenfolge wechselte fast bei jeder Abfrage.

Das ist Absicht und völlig harmlos. Ein korrekter Mailserver sortiert die Einträge selbst nach der Priorität. Wer also in einem Tool sieht, dass „der falsche” MX Record oben steht, muss nichts reparieren. Entscheidend ist allein die Zahl.

MX Record abfragen: So prüfst du den MX-Eintrag einer Domain

Den MX Record einer Domain kannst du in wenigen Sekunden selbst nachsehen. Je nach System gibt es drei Werkzeuge.

Unter Linux und macOS mit dig:

$ dig MX gmail.com +short
5 gmail-smtp-in.l.google.com.
10 alt1.gmail-smtp-in.l.google.com.
20 alt2.gmail-smtp-in.l.google.com.
30 alt3.gmail-smtp-in.l.google.com.
40 alt4.gmail-smtp-in.l.google.com.

+short liefert nur die Einträge. Ohne +short siehst du zusätzlich TTL, Status und die Antwortzeit.

Unter Windows mit nslookup:

nslookup -type=mx gmail.com

Mit host (kurz und lesbar):

$ host -t mx getmind.io
getmind.io mail is handled by 10 ff-web.de.

Die Ausgabe von host erklärt den MX Record eigentlich schon selbst: „mail is handled by”, also „die Post übernimmt”.

Direkt beim zuständigen Nameserver nachfragen

Wenn du gerade einen MX-Eintrag geändert hast, zeigt dir dein normaler Resolver unter Umständen noch die alte Antwort aus dem Zwischenspeicher. Dann lohnt es sich, den autoritativen Nameserver direkt zu fragen. Der kennt immer den aktuellen Stand:

$ dig NS getmind.io +short
launch1.spaceship.net.
launch2.spaceship.net.

$ dig @launch2.spaceship.net MX getmind.io +noall +answer
getmind.io.    300    IN    MX    10 ff-web.de.

Steht dort schon der neue Wert, ist deine Änderung korrekt angekommen. Der Rest ist nur noch Warten, bis die alten Zwischenspeicher ablaufen.

Drei mögliche Antworten und was sie bedeuten

Bei unseren Abfragen sind uns drei grundverschiedene Antworten begegnet. Sie sehen auf den ersten Blick ähnlich leer aus, bedeuten aber völlig unterschiedliche Dinge:

Den Unterschied zwischen Zeile zwei und drei kennen erstaunlich wenige, und er hat uns bei unseren eigenen Domains überrascht.

Unser Fund: Eine Domain ohne MX Record bekommt trotzdem Post

Zwei unserer Domains, heynyx.dev und nyx.fish, verschicken und empfangen keine Mails. Einen MX Record hatten wir dort deshalb nie angelegt. Logisch, dachten wir: kein MX, keine Post.

Das stimmt nicht. Der Mail-Standard (RFC 5321, Abschnitt 5.1) sieht für genau diesen Fall eine Rückfallregel vor, den sogenannten impliziten MX: Hat eine Domain keinen MX-Eintrag, aber eine IP-Adresse (A- oder AAAA-Eintrag), dann soll der Absender die Mail direkt an diese IP zustellen. Die Regel stammt aus der Frühzeit des Internets, als viele Domains genau einen Rechner hatten, der alles machte.

Bei heynyx.dev heißt das konkret:

$ dig MX heynyx.dev +short
(keine Ausgabe)

$ dig A heynyx.dev +short
46.225.123.163

Jede Mail an irgendwas@heynyx.dev würde also an 46.225.123.163 gehen, an den Server, auf dem die Website liegt. Bei den meisten Webservern ist Port 25 geschlossen, dann scheitert die Zustellung nach einigen Tagen mit einer Fehlermeldung an den Absender. Bei uns war das anders. Auf genau dieser IP läuft ein Postfix-Mailserver für ein Shop-Projekt. Wir haben uns selbst eine Testmail an diese Adresse geschickt:

EHLO probe.getmind.io
MAIL FROM:<probe@getmind.io>
250 2.1.0 Ok
RCPT TO:<test@heynyx.dev>
454 4.7.1 <test@heynyx.dev>: Relay access denied

Unser Mailserver hat das Richtige getan: Er kennt heynyx.dev nicht als eigene Domain und lehnt die Mail ab, statt sie weiterzuleiten. Wäre er falsch konfiguriert, wäre er ein offenes Relay, und Spammer könnten ihn nutzen. Der Code 454 ist außerdem ein vorübergehender Fehler. Ein absendender Server wird es deshalb tagelang erneut versuchen, bevor er aufgibt (Postfix wartet standardmäßig bis zu fünf Tage).

Die Lektion daraus: „Kein MX Record” heißt nicht „keine Post”. Wer auf einer Domain wirklich keine Mails empfangen will, sollte das ausdrücklich sagen. Dafür gibt es den Null-MX.

Null-MX: Wie man im DNS sagt „hier gibt es keine Post”

Der Null-MX (RFC 7505) ist ein MX Record mit Priorität 0 und einem einzelnen Punkt als Ziel:

$ dig MX example.com +short
0 .

Der Punkt steht für „kein Host”. Ein Absender, der diesen Eintrag sieht, weiß sofort, dass er gar nicht erst versuchen muss, eine Mail zuzustellen. Statt tagelanger Wiederholungsversuche gibt es sofort eine klare Fehlermeldung.

Der Null-MX wirkt aber auch in die andere Richtung, und das haben wir mit unserem eigenen Mailserver ausprobiert. Wir haben eine Testmail mit der Absenderadresse probe@example.org eingeliefert. Auch example.org hat einen Null-MX. Die Antwort kam sofort:

MAIL FROM:<probe@example.org>
RCPT TO:<test@heynyx.dev>
550 5.7.27 <probe@example.org>: Sender address rejected:
    Domain example.org does not accept mail (nullMX)

Unser Postfix hat die Mail abgelehnt, bevor er sich überhaupt den Empfänger angesehen hat. Die Logik: Eine Domain, die keine Post annimmt, kann auch keine Antworten und keine Fehlermeldungen empfangen. Eine Mail mit so einem Absender ist mit hoher Wahrscheinlichkeit gefälscht.

Damit hat der Null-MX zwei Vorteile für Domains, die nur Websites hosten:

• Absender bekommen sofort Bescheid, statt dass Mails tagelang in Warteschlangen hängen.
• Spammer können deine Domain schlechter als Absender missbrauchen, weil viele Mailserver solche Mails direkt abweisen.

Für eine Domain, die gar keine Mails nutzt, empfiehlt sich deshalb dieses Paket aus drei Einträgen:

beispiel.de.          MX    0 .
beispiel.de.          TXT   "v=spf1 -all"
_dmarc.beispiel.de.   TXT   "v=DMARC1; p=reject;"

Der Null-MX sagt „ich empfange nichts”, v=spf1 -all sagt „es gibt keinen Server, der in meinem Namen senden darf”, und DMARC mit p=reject fordert alle Empfänger auf, gefälschte Mails abzulehnen. example.com macht es übrigens genauso und hat ebenfalls v=spf1 -all gesetzt. Für heynyx.dev und nyx.fish steht das jetzt auf unserer eigenen Liste.

MX Record einrichten: Schritt für Schritt

Wie du einen MX-Eintrag anlegst, hängt von deinem Domain-Anbieter ab, die Schritte sind aber überall gleich.

1. Die Werte vom Mailanbieter holen. Dein Mailanbieter (Google Workspace, Microsoft 365, Posteo, mailbox.org, dein Hoster oder dein eigener Server) sagt dir, welche Hostnamen und Prioritäten du eintragen sollst. Übernimm sie exakt, inklusive aller Einträge, wenn es mehrere sind.

2. Im DNS-Bereich deines Domain-Anbieters einen neuen Eintrag anlegen. Typ MX, als Name meistens @ (das steht für die Domain selbst, ohne Subdomain), als Ziel den Hostnamen des Mailservers, dazu die Priorität.

3. Alte MX-Einträge entfernen. Das ist der häufigste Fehler beim Umzug: Der neue MX wird angelegt, der alte bleibt stehen. Haben beide dieselbe Priorität, landet ein Teil der Mails beim alten Anbieter. Hat der alte eine kleinere Zahl, landet sogar alles dort.

4. Prüfen. Mit dig MX deinedomain.de +short gegen den autoritativen Nameserver, wie oben beschrieben. Danach eine Testmail von einem fremden Konto, zum Beispiel einer Gmail-Adresse.

5. SPF, DKIM und DMARC ergänzen. Der MX Record sorgt nur dafür, dass Post ankommt. Damit deine ausgehenden Mails nicht im Spam landen, brauchst du die drei Schutzeinträge. Unsere eigene Domain hat sie: v=spf1 a:ff-web.de mx ~all als SPF und einen DMARC-Eintrag, der Berichte an ein Postfach schickt.

Die TTL vor einem Umzug senken

Die TTL bestimmt, wie lange Resolver die alte Antwort zwischenspeichern dürfen. Bei Gmail sind es 3600 Sekunden (eine Stunde), bei WEB.DE sogar 7200 Sekunden (zwei Stunden). Unsere eigene Domain steht auf 300 Sekunden.

Wenn du den Mailanbieter wechseln willst, setze die TTL deines MX Records ein bis zwei Tage vorher auf 300 Sekunden. Dann wechseln nach dem Umzug alle Absender innerhalb von fünf Minuten auf den neuen Server, statt noch stundenlang beim alten anzuklopfen. Nach dem Umzug kannst du die TTL wieder erhöhen.

Ein Trost für alle, die das vergessen haben: Bei E-Mail geht durch eine hohe TTL selten etwas verloren. Solange der alte Server die Mails noch annimmt, landen sie eben dort, und du holst sie per IMAP ab. Kritisch wird es nur, wenn das alte Postfach schon gekündigt ist.

Häufige MX-Record-Fehler aus der Praxis

Die meisten Mailprobleme, die wir bei eigenen und fremden Domains gesehen haben, gehen auf eine Handvoll Fehler zurück.

Der MX zeigt auf eine IP-Adresse. Laut Standard muss das Ziel ein Hostname sein. Trag also nicht 10 89.22.110.102 ein, sondern lege einen A-Eintrag wie mail.beispiel.de an und lass den MX darauf zeigen.

Der MX zeigt auf einen CNAME. Auch das ist laut Standard nicht erlaubt. Das Ziel eines MX Records muss direkt einen A- oder AAAA-Eintrag haben. Viele Mailserver folgen dem CNAME trotzdem, verlassen solltest du dich darauf nicht.

Der Ziel-Hostname existiert nicht. Ein Tippfehler im Hostnamen, und der MX zeigt ins Nichts. dig zeigt dir den MX Record dann ganz normal an. Erst wenn du die IP des Ziels abfragst, merkst du, dass da nichts ist. Prüfe deshalb immer beide Stufen: erst dig MX, dann dig A auf das Ziel.

Der vergessene Punkt am Ende. In Zonendateien (BIND und Co.) bedeutet ein Hostname ohne abschließenden Punkt „relativ zur Zone”. Aus mail.beispiel.de wird dann mail.beispiel.de.beispiel.de.. Webbasierte DNS-Oberflächen ergänzen den Punkt meist selbst, in Zonendateien musst du ihn setzen.

Subdomains erben den MX nicht. Ein MX Record gilt nur für genau den Namen, an dem er steht. Wir haben es getestet: getmind.io hat einen MX, www.getmind.io hat keinen. Wer Mails an info@shop.beispiel.de empfangen will, braucht einen eigenen MX-Eintrag für shop.beispiel.de.

Der veraltete Backup-MX. Früher war ein zweiter Mailserver mit höherer Priorität üblich, der Mails zwischenspeichert, wenn der Hauptserver ausfällt. Heute ist das oft eher ein Problem. Spammer zielen gezielt auf Backup-MX-Server, weil diese häufig schwächere Spamfilter haben und keine Liste der gültigen Empfänger kennen. Moderne Absender speichern Mails ohnehin bis zu fünf Tage und versuchen es erneut. Einen Backup-MX solltest du nur betreiben, wenn er dieselben Filter und dieselbe Empfängerliste hat wie der Hauptserver.

Nur der MX geändert, nicht das Postfach. Ein neuer MX Record zeigt Absendern den neuen Server, aber dort muss das Postfach auch schon existieren. Sonst lehnt der neue Server die Mails mit „Benutzer unbekannt” ab. Erst Postfächer beim neuen Anbieter anlegen, dann den MX umstellen.

MX Record, SPF, DKIM und DMARC: Wer macht was?

Diese vier Begriffe werden oft in einem Atemzug genannt und gern verwechselt. Dabei haben sie klar getrennte Aufgaben:

Der MX Record ist also der einzige der vier, der eingehende Mails betrifft. Die drei anderen schützen deine Domain davor, dass jemand in ihrem Namen Mails fälscht, und helfen deinen eigenen Mails durch die Spamfilter. Ein typisches Missverständnis: Jemand stellt den MX auf einen neuen Anbieter um, vergisst aber, den SPF-Eintrag anzupassen. Dann kommt Post zwar an, aber ausgehende Mails des neuen Anbieters landen bei den Empfängern im Spam.

Wenn dein MX auf deinen eigenen Mailserver zeigt, lohnt sich ein Blick auf die Absicherung des Servers insgesamt. Ein Mailserver auf Port 25 ist für Angreifer ein dankbares Ziel. Wie du einen Linux-Server grundlegend absicherst, zeigen wir in Linux-Server einrichten, und wie du wiederholte Login-Versuche automatisch blockierst, in Fail2ban einrichten.

Checkliste: MX Record richtig gesetzt?

Bevor du dich wunderst, warum Mails nicht ankommen, geh diese Liste durch:

1. dig MX deinedomain.de +short liefert die Einträge, die dein Mailanbieter vorgibt, und keine alten mehr.
2. Jedes Ziel ist ein Hostname, keine IP und kein CNAME.
3. dig A ziel-hostname +short liefert für jedes Ziel eine IP-Adresse.
4. Die Prioritäten stimmen: Der Hauptserver hat die kleinste Zahl.
5. Subdomains, die Mails empfangen sollen, haben einen eigenen MX.
6. Domains, die keine Mails empfangen sollen, haben einen Null-MX (0 .), dazu v=spf1 -all und DMARC mit p=reject.
7. SPF, DKIM und DMARC passen zum Anbieter, der tatsächlich sendet.
8. Vor einem Umzug ist die TTL auf 300 Sekunden gesenkt.
9. Eine Testmail von einem fremden Konto ist angekommen.

FAQ zum MX Record

Was ist ein MX Record einfach erklärt? Ein MX Record ist ein Eintrag im DNS, der sagt, welcher Server die E-Mails einer Domain annimmt. Er ist der Briefkasten-Hinweis einer Domain: Absender schauen dort nach, bevor sie eine Mail zustellen.

Wofür steht MX? MX steht für Mail Exchange, auf Deutsch etwa „Mail-Austausch”. Gemeint ist der Server, der Mails für eine Domain entgegennimmt.

Was bedeutet die Zahl vor dem MX Record? Das ist die Priorität. Absender probieren den Eintrag mit der kleinsten Zahl zuerst. Ist er nicht erreichbar, nehmen sie den nächsthöheren. Gleiche Zahlen bedeuten, dass die Last zufällig zwischen den Servern verteilt wird.

Brauche ich mehrere MX Records? Nicht unbedingt. Outlook.com kommt mit einem einzigen aus, weil hinter dem Namen vier IP-Adressen stehen. Für die meisten Domains reicht genau das, was der Mailanbieter vorgibt. Ein zusätzlicher, schlecht gepflegter Backup-MX schadet eher.

Was passiert, wenn eine Domain keinen MX Record hat? Dann stellen Absender die Mail an die IP-Adresse aus dem A- oder AAAA-Eintrag zu (impliziter MX nach RFC 5321). Läuft dort kein Mailserver, scheitert die Zustellung nach Tagen. Wer gar keine Mails empfangen will, sollte einen Null-MX setzen.

Was ist ein Null-MX? Ein MX Record mit der Priorität 0 und einem Punkt als Ziel (0 .), festgelegt in RFC 7505. Er sagt ausdrücklich, dass die Domain keine Mails annimmt. Absender geben sofort auf, und viele Mailserver lehnen Mails mit so einer Absenderdomain direkt ab. Unser eigener Postfix hat das im Test mit 550 5.7.27 getan.

Wie lange dauert es, bis ein neuer MX Record wirkt? Beim autoritativen Nameserver sofort. Bei allen anderen nach Ablauf der alten TTL, also meist zwischen fünf Minuten und einigen Stunden. Die oft genannten „24 bis 48 Stunden” sind eine Faustregel für den schlimmsten Fall, nicht der Normalfall.

Kann ein MX Record auf eine IP-Adresse zeigen? Nein, nicht laut Standard. Das Ziel muss ein Hostname mit A- oder AAAA-Eintrag sein. Lege für die IP einen Namen wie mail.beispiel.de an und lass den MX darauf zeigen.

Kann ich Website und E-Mail bei verschiedenen Anbietern haben? Ja, genau dafür gibt es den MX Record. Der A-Eintrag zeigt auf den Webserver, der MX-Eintrag auf den Mailserver. Bei uns liegt die Website von getmind.io auf einem Server bei Hetzner, die Post geht an einen ganz anderen Server.

Wie finde ich heraus, welcher Mailanbieter hinter einer Domain steckt? Frag den MX Record ab. Endet das Ziel auf google.com, ist es Google Workspace, bei outlook.com oder protection.outlook.com Microsoft 365, bei ionos.de IONOS. Unter Linux und macOS mit dig MX domain.de +short, unter Windows mit nslookup -type=mx domain.de.

Beeinflusst der MX Record, ob meine Mails im Spam landen? Nur indirekt. Für die Zustellbarkeit deiner ausgehenden Mails sind SPF, DKIM und DMARC entscheidend. Manche Empfänger prüfen aber, ob die Absenderdomain überhaupt Post annehmen kann. Eine Domain ohne funktionierenden MX wirkt verdächtig, eine mit Null-MX wird oft direkt abgelehnt.

Fazit: Was ist ein MX Record, und worauf solltest du achten?

Ein MX Record ist der kleinste Eintrag im DNS mit der größten Wirkung auf deinen Posteingang. Er sagt der ganzen Welt, welcher Server die Mails deiner Domain annimmt, und mit seiner Priorität auch, in welcher Reihenfolge. Die großen Anbieter zeigen, dass es dafür keinen einzigen richtigen Weg gibt: Gmail setzt auf eine Kaskade aus fünf Stufen, Posteo auf vier gleichwertige Server, Outlook.com auf einen einzigen Namen mit vier Adressen dahinter.

Aus unseren eigenen Tests nehmen wir zwei Dinge mit, die in kaum einer Kurzerklärung stehen. Erstens: Kein MX Record bedeutet nicht keine Post. Ohne MX gehen Mails an die IP der Website, und wenn dort zufällig ein Mailserver läuft, muss der richtig konfiguriert sein. Zweitens: Wer keine Post will, sollte es sagen. Ein Null-MX, kombiniert mit v=spf1 -all und DMARC, macht aus einer schweigenden Domain eine, die Absender sofort informiert und Fälschern das Leben schwer macht.

Wenn du tiefer einsteigen willst, wie DNS-Anfragen überhaupt beantwortet werden und warum Änderungen manchmal dauern, lies weiter in unserem Artikel Was ist DNS?.