MX-Record im DNS verständlich erklärt: E-Mail-Routing
Der MX-Record (kurz für Mail Exchange Record) ist der DNS-Eintrag, der für die Zustellung von E-Mails verantwortlich ist. Er teilt anderen Mailservern im Internet mit, welche Server für den Empfang von E-Mails für eine bestimmte Domain (z. B. @allerate.com) zuständig sind. Ohne einen korrekt konfigurierten MX-Record können keine E-Mails an eine Domain zugestellt werden.
Der MX-Record ist Teil eines Zusammenspiels mehrerer DNS-Einträge, die über die Mail-Zustellbarkeit entscheiden. Während der MX-Record den Empfang steuert, sichern SPF, DKIM und DMARC die Authentizität versendeter Nachrichten ab. Eine vollständige Übersicht aller Record-Typen finden Sie im DNS-Leitfaden.
So findet eine E-Mail ihren Weg
Wenn ein Mailserver eine Nachricht an name@example.com zustellen soll, läuft im Hintergrund eine DNS-Abfrage ab:
- Der sendende Server fragt den DNS-Resolver nach den MX-Records von
example.com. - Er erhält eine Liste von Zielhosts mit Prioritäten und wählt den mit der niedrigsten Zahl.
- Für diesen Hostnamen löst er den zugehörigen A/AAAA-Record auf, um die IP-Adresse zu erhalten.
- Über diese IP baut er die SMTP-Verbindung auf und übergibt die Nachricht.
Schlägt ein Schritt fehl – etwa weil der Zielhost keinen A-Record besitzt – bricht die Zustellung ab oder weicht auf den nächsten MX aus.
Aufbau und Syntax eines MX-Records
In einer DNS-Zonendatei enthält ein MX-Eintrag zusätzlich eine Prioritätsstufe:
example.com. 3600 IN MX 10 mail.example.com.
example.com. 3600 IN MX 20 backupmail.example.com.
- Host/Name (
example.com.): Die Domain, für die E-Mails empfangen werden sollen. - Time to Live (TTL -
3600): Die Cache-Dauer. - Klasse (
IN): Internet. - Typ (
MX): Identifiziert den Eintrag als Mail Exchange Record. - Priorität (
10bzw.20): Bestimmt die Reihenfolge, in der Mailserver kontaktiert werden. Ein niedrigerer Wert hat Vorrang. - Wert/Ziel (
mail.example.com.): Der Name des zuständigen Mailservers.
Das Prioritätssystem und Backup-Server
Das Prioritätssystem bei MX-Records dient der Ausfallsicherheit. Im obigen Beispiel wird versucht, E-Mails zuerst an den Server mit der Priorität 10 (mail.example.com) zu senden.
- Ist dieser Server erreichbar, wird die E-Mail zugestellt.
- Ist der Server
10wegen einer Störung oder Wartungsarbeiten offline, weicht der sendende Mailserver automatisch auf den Eintrag mit der nächsthöheren Priorität20(backupmail.example.com) aus. - Dieser Backup-Mailserver nimmt die E-Mail entgegen, speichert sie in einer Warteschlange (Queue) und stellt sie dem Primärserver zu, sobald dieser wieder online ist.
Die häufigsten Fehler bei MX-Records
- Direkte Angabe von IP-Adressen: Ein Eintrag wie
10 192.0.2.10im MX-Wert ist ungültig. Es muss zwingend ein Hostname angegeben werden. - Verweis auf CNAME-Records: Der im MX-Record angegebene Hostname darf nicht auf einen CNAME-Record verweisen, sondern muss direkt auf einen A- oder AAAA-Record zeigen. Dies verhindert Endlosschleifen bei der Auflösung.
- Fehlende A/AAAA-Records für den Mailserver: Wenn der MX-Record auf
mail.example.comzeigt, dieser Name aber keinen entsprechenden A- oder AAAA-Record im DNS besitzt, können Absender die IP-Adresse des Mailservers nicht auflösen und brechen den Sendevorgang ab. - Fehlkonfiguration bei Spam-Filtern: Wird ein externer Spam-Filter vorgeschaltet, muss der MX-Record auf den Filter verweisen und nicht mehr direkt auf den eigentlichen Mailserver.
MX-Record-Beispiele bekannter Anbieter
In der Praxis verweisen MX-Records meist auf die Infrastruktur eines E-Mail-Anbieters. Die folgende Übersicht zeigt typische Konfigurationen:
| Anbieter | Beispielhafter MX-Eintrag | Priorität |
|---|---|---|
| Google Workspace | smtp.google.com. | 1 |
| Microsoft 365 | example-com.mail.protection.outlook.com. | 0 |
| Eigener Server | mail.example.com. | 10 |
| Backup-Server | backupmail.example.com. | 20 |
Wichtig: Nach einem Anbieterwechsel müssen alte MX-Einträge vollständig entfernt werden. Bleiben veraltete Einträge mit niedriger Priorität bestehen, landen E-Mails beim falschen Server.
MX-Records und Mail-Zustellbarkeit
Ein korrekter MX-Record sorgt dafür, dass E-Mails überhaupt ankommen – ob sie im Posteingang oder im Spam landen, entscheiden hingegen die Authentifizierungs-Records. Das Zusammenspiel im Überblick:
| Record | Aufgabe | Richtung |
|---|---|---|
| MX | Legt fest, welcher Server E-Mails empfängt | Empfang |
| SPF | Definiert erlaubte sendende Server | Versand |
| DKIM | Signiert E-Mails kryptografisch | Versand |
| DMARC | Regelt den Umgang mit gefälschten Mails | Versand |
| PTR | Reverse-DNS für die Sende-IP | Versand |
Fehlt eines dieser Puzzleteile, leidet die Zustellbarkeit. Für eine produktive Domain sollten daher immer alle fünf Einträge sauber gesetzt sein.
[!TIP] Fehlkonfigurationen bei MX-Records führen zu unzustellbaren E-Mails und Fehlern im Mailverkehr. Prüfen Sie die Mailserver-Zustellbarkeit und Reputation Ihrer Domain mit der Mail Deliverability Suite auf balou.tools.
Häufig gestellte Fragen (FAQ)
Darf eine IP-Adresse direkt in einem MX-Record eingetragen werden?
Nein. Laut RFC 2181 muss der Zielwert eines MX-Records immer ein Hostname (z. B. `mail.example.com`) sein, der wiederum über einen A- oder AAAA-Record auf eine IP-Adresse verweist.
Was passiert, wenn mehrere MX-Records dieselbe Priorität besitzen?
Wenn zwei Mailserver dieselbe Priorität aufweisen, verteilt der sendende Mailserver die Last (Load Balancing) gleichmässig auf beide Systeme.
Wie prüfe ich die MX-Records einer Domain?
Mit dem Befehl `dig MX example.com +short` oder `nslookup -type=mx example.com` lassen sich die MX-Einträge samt Prioritäten abfragen. Online-Werkzeuge zeigen zusätzlich, ob die Zielhosts gültige A/AAAA-Records besitzen und erreichbar sind.
Brauche ich einen MX-Record, wenn ich nur E-Mails sende?
Zum reinen Versenden ist technisch kein eigener MX-Record nötig, da dieser nur den Empfang steuert. Für Zustellbarkeit und Reputation sollten Sie aber dennoch SPF, DKIM und DMARC sowie einen passenden PTR-Record konfigurieren.
Was ist der Null-MX-Record?
Ein Null-MX (`0 .`) signalisiert nach RFC 7505 explizit, dass eine Domain keine E-Mails empfängt. Das verhindert Zustellversuche und reduziert Rückläufer bei Domains, die ausschliesslich für Webseiten genutzt werden.