
MX-Eintrag (MX Record): Priorität und typische Fehler
Die Mail kommt nicht an, und niemand bekommt eine Fehlermeldung. Der Absender sieht nichts, der Empfänger weiß von nichts, und erst nach vier oder fünf Tagen gibt der sendende Server auf. Das ist das Fehlerbild eines falschen MX-Eintrags, und es ist der Grund, warum man diesen Eintrag nach jeder Änderung von außen testet.
Der MX-Eintrag beantwortet genau eine Frage: Welcher Server nimmt E-Mails für diese Domain an? Er hat nichts mit der Website zu tun. example.com kann bei einem Anbieter liegen und die Post bei einem völlig anderen: Der A-Eintrag zeigt auf den Webserver, der MX-Eintrag auf den Mailserver, und die beiden wissen nichts voneinander.
example.com. IN MX 10 mail1.anbieter.de.
example.com. IN MX 20 mail2.anbieter.de.
Die Zahl davor ist eine Reihenfolge, keine Gewichtung#
Die Zahl heißt Priorität, und kleiner bedeutet wichtiger. Ein sendender Server versucht zuerst die 10, und nur wenn die nicht erreichbar ist, die 20.

Das ist der häufigste Denkfehler: Zwei Einträge mit 10 und 20 sind kein Lastausgleich, sondern Haupt- und Ersatzserver. Wer verteilen will, gibt beiden dieselbe Zahl, dann muss der sendende Server laut RFC 5321 zufällig wählen.
Der Zahlenwert selbst ist bedeutungslos. 10 und 20 sind Konvention, 1 und 2 täten dasselbe. Die Abstände lassen nur Platz, um später etwas dazwischen zu setzen.
Warum ein fehlender Eintrag anders scheitert als ein falscher#
Kein MX-Eintrag vorhanden. Sendende Server fallen dann auf den A-Eintrag der Domain zurück (derselbe Abschnitt des Standards nennt das den impliziten MX mit Priorität 0) und versuchen, dem Webserver Post zu übergeben. Der nimmt sie nicht an, und die Mail kommt mit einer Fehlermeldung zurück, meist innerhalb von Sekunden. Unangenehm, aber sofort sichtbar.
Falscher MX-Eintrag. Die Mail geht an einen Server, der sie annimmt und nicht zustellt, oder an einen, der nicht antwortet. Im zweiten Fall versucht der Absender es weiter; RFC 5321 nennt mindestens vier bis fünf Tage, bevor er aufgibt. Das ist der gefährlichere Fall, weil er still ist. Der Absender denkt, die Mail sei unterwegs, der Empfänger weiß von nichts.
Deshalb gilt nach jeder Änderung: nicht auf das Ausbleiben von Fehlern warten, sondern eine Testmail von außen schicken.
Der Eintrag zeigt auf einen Namen, nicht auf eine Adresse#
Ein MX-Eintrag muss auf einen Hostnamen zeigen, der seinerseits einen A- oder AAAA-Eintrag hat. Eine IP-Adresse direkt im MX-Eintrag ist nicht zulässig, der Standard verlangt einen Domainnamen. Viele DNS-Oberflächen nehmen sie trotzdem an, und der Fehler fällt erst auf, wenn Post ausbleibt.
Ebenfalls unzulässig: ein MX-Eintrag, der auf einen CNAME zeigt. Auch das akzeptieren manche Oberflächen, und auch das führt zu Zustellproblemen, die schwer zu finden sind, weil sie nicht bei jedem Absender auftreten.
Was der MX-Eintrag nicht regelt#
Ob deine Mails ankommen. Der MX-Eintrag betrifft nur eingehende Post. Für ausgehende entscheiden SPF, DKIM und DMARC darüber, ob der Empfänger sie glaubt. Ob diese drei stehen, zeigt der E-Mail-Check, der zugleich die MX-Einträge der Domain ausliest.
Das ist eine häufige Verwechslung bei Umzügen: Der MX-Eintrag wird umgestellt, eingehende Post läuft, und ausgehende landet im Spam, weil der neue Versandserver nicht im SPF-Eintrag steht.
Ob der Server sicher ist. Ein MX-Eintrag sagt nichts über Verschlüsselung oder Konfiguration aus.
Welche Adresse hinter dem MX-Namen steckt und ob sie auf einer Sperrliste steht, zeigt der Blacklist-Check. Für die eigene Domain am 03.10.2026: mail3.meinehp.at löst auf 80.77.17.30 auf, der Webserver auf 75.2.60.5, beide auf keiner der fünf Listen.

Wohin die Post in Tirol geht#
In eigener Sache eine Zählung: die MX-Einträge von 140 Tiroler Domains (115 Betriebe aus meiner Akquise-Liste und 25 Tourismusverbände), abgefragt per DNS-over-HTTPS am 27.09.2026. Nur Summen, keine Namen.
| MX-Ziel | Domains |
|---|---|
Microsoft 365 (*.mail.protection.outlook.com) | 59 |
ein Mailserver unter der eigenen Domain (mail.<eigene-domain>) | 26 |
| Filterdienst vor dem Postfach (Hornetsecurity) | 8 |
| Hoster agenturserver.de | 5 |
| Google Workspace | 1 |
| andere Hoster und Anbieter | 37 |
| kein MX-Eintrag | 4 |
| Anzahl MX-Einträge | Domains |
|---|---|
| keiner | 4 |
| einer | 97 |
| zwei | 19 |
| drei oder mehr | 20 |
Zwei Befunde daraus. Vier Domains haben keinen MX-Eintrag und laufen auf den impliziten MX von oben: Post geht an den A-Eintrag, also meist an den Webserver. Ob dort ein Mailserver antwortet, weiß von außen niemand, und das ist der stille Fehler vom Anfang. Und 97 von 140 kommen mit einem einzigen MX-Eintrag aus. Bei Microsoft 365, wo hinter einem Namen viele Server stehen, ist das in Ordnung. Bei mail.<eigene-domain> auf einem einzelnen Server heißt es, dass die Post wartet, wenn er steht. Sendende Server warten, aber sie liefern nicht woanders ab.
Was der MX nicht verrät, zeigt dieselbe Abfrage: Von den 59 Domains bei Microsoft 365 haben 56 kein wirksames DMARC (26 ohne Eintrag, 30 mit p=none). Der Anbieter stellt die Technik, den Eintrag setzt der Domaininhaber. Die Zahlen dazu stehen in DMARC einrichten.
Häufige Fragen#
Wie lange dauert eine Änderung?
So lange, wie die TTL des alten Eintrags noch läuft, bei jedem Sender einzeln. Setz die TTL vor einem geplanten Wechsel herunter, dann ist die Umstellung nachher schneller durch. Danach wieder hochsetzen.
Brauche ich einen zweiten MX-Eintrag?
Nur, wenn es einen zweiten Server gibt, der Post wirklich annehmen und weitergeben kann. Ein Ersatzeintrag, der auf denselben Server zeigt, hilft nicht, und ein Ersatzserver, der nur annimmt und nichts weiterreicht, ist schlimmer als keiner.
Kann ich Mail und Website bei verschiedenen Anbietern haben?
Ja, das ist der Normalfall. A-Eintrag zum Webhoster, MX-Eintrag zum Mailanbieter. Beide werden unabhängig voneinander gesetzt und stören sich nicht.
Stand 03.10.2026. Quellen abgerufen am selben Tag; die MX-Zählung stammt vom 27.09.2026.
Quellen (4)
- RFC 5321: SMTP, Abschnitt 5.1: Reihenfolge nach Priorität, zufällige Wahl bei gleicher Priorität, impliziter MX aus dem A-Eintrag
- RFC 5321, Abschnitt 4.5.4.1: Wiederholversuche, Aufgabe „generally … at least 4-5 days“
- RFC 2181, Abschnitt 10.3: ein MX darf nicht auf einen CNAME zeigen
- Eigene Messung: MX-Einträge von 140 Tiroler Domains per DNS-over-HTTPS (Cloudflare) am 27.09.2026, je Domain ein Ziel. Nur Summen, keine Namen.
Weiterlesen
Kommentare
Gespeichert werden nur dein Name und dein Text — keine E-Mail-Adresse, keine IP-Adresse, kein Cookie. Jeder Kommentar wird vor der Veröffentlichung gelesen; das dauert meist einen Tag. Näheres in der Datenschutzerklärung.