Der MX-Eintrag („MX“: Mail Exchanger) in DNS-Daten gibt an, welcher Mailserver für den Empfang von E-Mails an eine bestimmte Ziel-Domäne zuständig ist.
Beim Versand einer E-Mail an „info@example.com“ befragt der Absender-Mailserver seinen DNS, welche Mailserver für „example.com“ zuständig sind (im Bild Schritte #1 bis #3). Als Antwort (#4) erhält er den MX-Eintrag, z.B. „mail.example.com“, der dann in eine IP Adresse aufgelöst werden kann. Der Absender-Mailserver tritt dann direkt mit dem Empfänger-Mailsystem in Verbindung und versendet die E-Mail per SMTP (#5).
MX-Einträge im DNS
Ein MX-Eintrag muss stets auf einen Hostnamen, nie auf eine IP Adresse (auch wenn manche Mailserver damit zurecht kommen) eingetragen werden.
In den Zonedaten der Domain werden die MX-Einträge mit einem Kostenfaktor eingetragen:
IN MX 10 mail01.example.com.
IN MX 50 mail02.example.com.
Über den Kostenfaktor wird der bevorzugte Mailserver für E-Mail an diese Domain festgelegt; im Beispiel oben der „mail01“, da er den kleineren Kostenfaktor/ Preference Wert (10) hat.
Werden mehrere Mailserver eingetragen, so werden die Backup-Mailserver normalerweise nur dann kontaktiert, wenn der erste Mailserver (der mit dem günstigsten Kostenfaktor) nicht erreicht werden kann. Der Backup-Mailserver kann dann je nach Konfiguration entweder seine Mails an den ersten Mailserver schicken sobald dieser wieder erreichbar ist oder er kann die Mails direkt in ein hausinternes Postfachsystem schicken. Die genaue Umsetzung hängt ggf. vom E-Mail-Szenario ab.
Beispiele: MX-Einträge in der DNS Zone
IN MX 10 mail.ihr-provider.de.
IN MX 10 mail.example.com. mail IN A 220.10.20.30
Mailserver beim Provider als zusätzlicher Backup-MX.
IN MX 10 mail.example.com.
IN MX 20 mail.ihr-provider.de.
mail IN A 220.10.20.30
Beide Mailserver im Haus, „mail02“ bekommt E-Mails gesendet, wenn „mail01“ nicht erreichbar ist.
IN MX 10 mail01.example.com.
IN MX 20 mail02.example.com.
mail01 IN A 220.10.20.30
mail02 IN A 220.10.20.31
Beide Mailserver im Haus, gleicher Kostenfaktor ergibt grobe Lastverteilung auf den beiden Mailgateways.
IN MX 10 mail01.example.com.
IN MX 10 mail02.example.com.
mail01 IN A 220.10.20.30
mail02 IN A 220.10.20.31
Mailserver beim Provider als zusätzlicher Backup-MX
IN MX 10 mail01.example.com.
IN MX 20 mail02.example.com.
IN MX 100 mail.ihr-provider.de.
mail01 IN A 220.10.20.30
mail02 IN A 220.10.20.31
MX-Einträge mit nslookup und dig prüfen
Die MX Einträge kann man mit nslookup auf der Kommandozeile prüfen:
C:\>nslookup -q=mx netzprisma.de [...] netzprisma.de MX preference = 10, mail exchanger = mx1.netzprisma.de mx1.netzprisma.de internet address = 85.10.###.###
Unter Linux (und wohl auch auf Apple Systemen) verwendet man das Tool „dig“:
# dig netzprisma.de mx [...] netzprisma.de. IN MX 10 mx1.netzprisma.de. [...]
Backup MX
Ein Backup MX Server ist dazu gedacht, Ihre E-Mails entgegen zu nehmen, wenn Ihr Mailserver nicht erreichbar ist. Der Backup MX Server versucht dann, die empfangenen E-Mails an den eigentlichen Ziel-Mailserver weiterzuleiten, was ihm gelingt, sobald der Ziel-Server wieder erreichbar ist.
Ein Backup MX Server ist nicht zwingend nötig – er kann manchmal auch Probleme bereiten.
Ein sendender Mailserver hat meistens eine Warteschlangenzeit von wenigstens ein bis zwei Tagen. Kann die E-Mail innerhalb dieser Zeit nicht zugestellt werden, erhält der Absender einen Unzustellbarkeitsbericht. Ohne Backup MX haben Sie demnach ein bis zwei Tage Zeit, Ihre Mailanbindung zu warten – danach gehen E-Mails als unzustellbar an die Absender zurück.
Falls Sie zwei Mailserver im Haus stehen haben, die beide für den Empfang von E-Mails zur Verfügung stehen können: hier gewinnen Sie mit einem zweiten MX Eintrag den Nutzen, dass die E-Mails auch während der Wartung des einen Mailservers weiterhin zugestellt werden können. In solchen Umgebungen wird jedoch auch häufig mit anderen Lastverteilungstechniken gearbeitet – ein Backup-MX ist nur eine von mehreren Möglichkeiten.
Ein externer Backup MX Server macht dann Sinn, wenn seine Warteschlangenzeit länger als die üblichen zwei Tage eingestellt ist, z.B. eine Woche. Er puffert dann die eingehenden E-Mails länger als die sendenden Mailserver und Sie haben damit etwas länger Zeit für die Wartung Ihrer Mailanbindung.
Leider wird häufig übersehen, dass der Backup MX Server mindestens genauso restriktiv administriert werden muss wie der primäre Mailserver. Oft wird davon ausgegangen, dass E-Mails vom Backup MX Server (von dessen IP) auf jeden Fall angenommen werden müssen, er wird dazu häufig in die Whitelist von Filtersystemen eingetragen. Damit kann jedoch z.B. ein Spammer, der seinen Spam gleich beim Backup MX Server ablädt, seine E-Mails durchaus an Filtersystemen vorbei zu den Empfängern senden. Der Backup MX Server sollte also über ähnliche Filter wie Blacklists etc. verfügen wie der eigentliche Mailserver. Vor allem wenn man einen Backup MX Server beim Provider verwendet, ist das häufig nicht der Fall – am besten den Anbieter danach fragen.
E-Mail ohne MX Eintrag / „implicit MX“ Regel
Ist im DNS kein MX-Eintrag vorhanden, verwenden Mailserver laut RFC 2821 auch einen passenden A-Eintrag als Ziel-Mailserver.
Bei einem nicht vorhandenen MX-Eintrag sollten Mails an die Domain „example.com“ also an den Host „example.com“ gesendet werden, wenn dafür ein A-Eintrag gesetzt ist:
@ IN A 220.10.20.30
Dennoch sollte man natürlich einen MX-Eintrag einrichten, selbst wenn Mail- und Webserver über dieselbe IP erreichbar sind.
Null-MX-Eintrag
Durch die „implicit MX“-Regel ergibt sich für Domains, die zwar eine Webadresse http://example.com (ohne „www“ o.ä.) haben, jedoch keine Mails empfangen sollen, ein Problem: Ein Mailserver muss versuchen, eine Mail an „example.com“ auch ohne MX-Eintrag zuzustellen, da ja ein „A“-Eintrag vorhanden ist. Die Zustellversuche gehen dann an den Webserver.
Entsprechend der RFC 7505 kann ein sogenannter „Null-MX-Eintrag“ verwendet werden, der angibt, dass eine Domain keine E-Mails empfangen soll. Die etwas seltsame Angabe kann derzeit wohl nicht bei allen Domainanbietern eingetragen werden – fragen Sie ggf. den dortigen Support.
Beispiel (Kostenfaktor „0“ und der Punkt als Eintrag ergeben den Null-MX-Eintrag):
IN MX 0 .
Ergänzend kann man noch SPF- und DKIM-Angaben einrichten, um mit dieser Maildomain verschickte Mails als ungültig zu deklarieren und so möglichen Missbrauch der Absender-Domain einzuschränken.
Verwendung des MX-Eintrags für „glückliche“ Spamfilter
Spamfilter prüfen ggf. beim Empfang einer E-Mail den MX-Eintrag. Wenn der sendende Mailserver behauptet „mail.example.com“ zu sein und eine E-Mail von „john@example.com“ übertragen möchte prüfen manche Spamfilter, ob die IP Adresse des Mailservers zum Hosteintrag passt und ob es einen MX-Eintrag für diese E-Mail-Domain gibt. Falls SPF eingesetzt wird, kann ggf. noch geprüft werden, ob die Absende-IP eine legitime Absende-IP für E-Mails von dieser Domain ist.
Im Standard-Szenario sollten die Einträge (Helo String, Hostname, IP und reverse-DNS) zueinander passen:
| Name Ihres Mailservers im SMTP Dialog (= Name im HELO/EHLO; hausintern kann er durchaus anders heißen) | mail.example.com |
| IP Ihres Mailservers wie sie ein empfangender Mailserver sieht (d.h. die offizielle IP Ihres Internetzugangs) | 220.10.20.30 |
| Reverse-DNS Eintrag („PTR“) für Ihre IP Adresse [220.10.20.30] | mail.example.com |
| MX und Host Einträge in Ihrer Domain |
IN MX 10 mail.example.com. mail IN A 220.10.20.30 |