MX-Records erklärt: Wie E-Mail ihren Weg findet

Wenn jemand eine E-Mail an name@example.com sendet, schlägt der sendende Mailserver nicht einfach den regulären A-Record von example.com nach. Er fragt einen völlig anderen Record-Typ ab: MX, kurz für Mail Exchange. Der MX-Record verweist auf den Hostnamen des Servers, der für die Annahme von Mail dieser Domain zuständig ist – und der ist sehr oft eine ganz andere Adresse als die, unter der die Website selbst liegt.

Priorität: der Teil, der Leute überrascht

Eine Domain kann mehrere MX-Records haben, jeweils mit einem numerischen Prioritätswert. Niedrigere Zahlen werden bevorzugt. Ein sendender Server probiert zuerst den Mailserver mit dem niedrigsten Prioritätswert (dem am meisten bevorzugten) und weicht auf höhere Werte nur aus, wenn dieser nicht erreichbar ist. Das ermöglicht eine redundante Mailzustellung – ein Backup-Mailserver mit einem höheren Prioritätswert, bereit, Mail anzunehmen, wenn der primäre ausfällt.

• Das Ziel eines MX-Records muss sich selbst zu einem A- oder AAAA-Record auflösen – es kann nicht direkt auf eine IP-Adresse zeigen.
• Eine Domain ganz ohne MX-Record kann in der Regel keine E-Mail empfangen, selbst wenn ihre Website einwandfrei funktioniert – beides wird über völlig getrennte DNS-Lookups abgewickelt.
• Zwei MX-Records mit identischem Prioritätswert sind beide gleichzeitig gültig – der sendende Server darf einen beliebigen wählen, was mitunter bewusst als einfache Form der Lastverteilung genutzt wird.

Warum das über „E-Mail funktioniert oder nicht“ hinaus wichtig ist

MX-Records sind auch der Ausgangspunkt, um das umfassendere E-Mail-Setup einer Domain zu verifizieren – SPF-, DKIM- und DMARC-Records dienen alle dazu nachzuweisen, dass Mail, die vorgibt, von einer Domain zu stammen, dazu tatsächlich autorisiert ist, und die Prüfung der MX-Konfiguration ist meist der erste Schritt, bevor man diese verifiziert. Der Umzug zu einem neuen E-Mail-Anbieter ist im Kern eine DNS-Änderung am MX-Record (plus der unterstützenden Records) – und erbt damit jede Einschränkung durch Propagierungsverzögerung, die für jedes andere DNS-Update gilt.

Eine Domain, die bewusst keine E-Mail versendet

Nicht jede Domain möchte Mail empfangen, und das undefiniert zu lassen ist selbst eine kleine Sicherheitslücke: Ohne ein explizites Signal versuchen manche Mailsysteme dennoch die Zustellung oder treffen Annahmen über eine fehlende Konfiguration. RFC 7505 definiert dafür einen „Null-MX“ – einen einzelnen MX-Record, der auf „.“ (die Root, also ins Nirgendwo) mit Priorität 0 zeigt und ausdrücklich erklärt: „Diese Domain nimmt keine Mail an, versuchen Sie es gar nicht erst.“ Das ist eine kleine, einfache Ergänzung, die sich für jede Domain lohnt – eine Marketing-Weiterleitungsdomain, eine rein interne Dienstdomain –, die garantiert nie E-Mail versenden oder empfangen wird.

Der häufige Fehler, den man vermeiden sollte

Eine überraschend häufige Fehlkonfiguration ist, einen MX-Record direkt auf eine IP-Adresse zeigen zu lassen oder auf einen Hostnamen, der selbst nur einen CNAME statt eines echten A-/AAAA-Records hat. Beides verstößt gegen die Regeln des Record-Typs selbst, und Mailsysteme, die die Spezifikation strikt befolgen, verweigern die Zustellung komplett, statt zu raten, was gemeint war. Funktioniert die Website einer Domain einwandfrei, die E-Mail-Zustellung aber scheitert vollständig statt nur langsam zu sein, gehört zu den ersten und günstigsten Prüfungen, ob jedes MX-Ziel tatsächlich zu einem einfachen A- oder AAAA-Record aufgelöst wird – nicht zu einem CNAME und nicht zu einer versehentlich eingetippten nackten IP.