MX-Record erklärt: Mailserver, Priorität und Einrichtung

Der MX-Record gehört zur DNS-Zone der Empfängerdomain. Sendende Mailserver fragen ihn ab, bevor sie eine Nachricht zustellen. Er beschreibt damit den Weg für eingehende E-Mails; über den Versand eigener Nachrichten, Postfächer oder Spamfilter entscheidet er nicht.

Wie ist ein MX-Record aufgebaut?

Eine Domain kann beispielsweise zwei Mailserver veröffentlichen:

example.com. 3600 IN MX 10 mail1.example.net.
example.com. 3600 IN MX 20 mail2.example.net.

Der Eintrag enthält den Namen, die TTL, die DNS-Klasse IN, den Typ MX, eine Präferenz und den Zielhost. Im Kundenbereich sind oft nur Host, Priorität und Ziel sichtbar. @ steht dort häufig für die Hauptdomain.

mail1.example.net wird wegen der niedrigeren Zahl zuerst versucht. Die Zahl ist weder eine Gewichtung noch eine Prozentangabe. Haben mehrere Ziele dieselbe Präferenz, gelten sie als gleichrangig und sendende Systeme dürfen zwischen ihnen auswählen.

Der abschließende Punkt kennzeichnet in einer Zonendatei einen vollständigen Domainnamen. Viele Verwaltungsoberflächen ergänzen ihn selbst. Entscheidend ist die Vorschau des Anbieters: Aus mail.example.net darf nicht versehentlich mail.example.net.example.com werden.

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

1. Der sendende Mailserver ermittelt die MX-Records der Domain hinter dem @ der Empfängeradresse.
2. Er ordnet die erreichbaren Ziele nach ihrer Präferenz.
3. Er löst den gewählten Zielhost über A und gegebenenfalls AAAA in IP-Adressen auf.
4. Er baut eine SMTP-Verbindung auf und versucht, die Nachricht zu übertragen.
5. Der empfangende Server prüft Empfängeradresse, Richtlinien und Nachricht und antwortet mit einem SMTP-Status.
6. Bei einem temporären Fehler stellt der Absender später erneut zu oder versucht ein nachrangiges Ziel. Ein dauerhafter Fehler führt dagegen in der Regel zu einer Unzustellbarkeitsmeldung.

Existiert kein MX-Record, sieht SMTP unter bestimmten Voraussetzungen einen Rückgriff auf die Adressen der Domain vor. Das ist kein sinnvoller Ersatz für eine geplante Mailkonfiguration. Ein ausdrücklich veröffentlichter Null-MX mit Präferenz 0 und Ziel . signalisiert dagegen, dass eine Domain gar keine E-Mails annimmt.

Was bedeuten mehrere MX-Records?

Mehrere Einträge können Ausfallsicherheit oder Lastverteilung ermöglichen, aber nur, wenn alle genannten Systeme für die Domain eingerichtet sind. Ein Server mit höherer Präferenzzahl ist nicht automatisch ein brauchbarer Backup-MX. Er muss Empfänger kennen, Nachrichten sicher zwischenspeichern und sie korrekt an das primäre System weitergeben.

Ein schlecht abgesicherter Backup-MX kann sogar zum Problem werden: Nimmt er Nachrichten ungeprüft an, entstehen Rückläufer erst später oder Spamfilter lassen sich umgehen. Verwende deshalb ausschließlich die vollständige MX-Gruppe, die Dein Mailanbieter dokumentiert. Eigene zusätzliche Ziele sind ohne abgestimmtes Routing keine Reserve.

Was hat MX mit SPF, DKIM und DMARC zu tun?

MX steuert den Empfang. Die Authentifizierung ausgehender E-Mails wird separat veröffentlicht: SPF beschreibt erlaubte Versandquellen, DKIM stellt einen öffentlichen Schlüssel für Signaturprüfungen bereit und DMARC verbindet diese Prüfungen mit der sichtbaren Absenderdomain. Dafür kommen überwiegend TXT-Records zum Einsatz.

Ein korrekter MX-Record verbessert daher nicht automatisch die Zustellbarkeit ausgehender Nachrichten. Umgekehrt ändert ein SPF- oder DKIM-Eintrag nicht, auf welchem Server eingehende E-Mails landen. Bei einem Anbieterwechsel müssen beide Seiten der Konfiguration getrennt geprüft werden.

MX-Record sicher ändern

1. Lege beim neuen Anbieter zuerst Domains, Postfächer, Aliasse und gegebenenfalls Weiterleitungen an.
2. Dokumentiere alle vorhandenen MX-Einträge und prüfe zusätzlich SPF, DKIM und DMARC.
3. Reduziere die TTL bei einer geplanten Umstellung rechtzeitig, wenn Dein DNS-Anbieter dies ermöglicht.
4. Übernimm sämtliche Zielhostnamen und Präferenzen exakt aus der aktuellen Anbieterdokumentation.
5. Entferne alte MX-Einträge erst, wenn der neue Dienst Nachrichten für alle benötigten Adressen annimmt.
6. Teste interne und externe Adressen sowie Antworten und Weiterleitungen. Lasse den alten Dienst während der Cache-Übergangszeit erreichbar.

Die Änderung erfolgt in der autoritativen Zone. Wo diese liegt, erklären die Beiträge zu Nameservern und DNS-Einträgen. Eine neue, niedrigere TTL löscht bereits vorhandene Cache-Einträge nicht rückwirkend.

MX-Record prüfen und Fehler finden

Mit dig MX example.com oder nslookup -type=MX example.com lässt sich die öffentlich sichtbare Antwort prüfen. Für eine Änderung ist zunächst die Antwort eines autoritativen Nameservers maßgeblich. Öffentliche Resolver können wegen ihrer Caches noch den alten Stand liefern.

• Wird der Record unter der richtigen Domain ausgegeben?
• Sind alle erwarteten Ziele und Präferenzen vorhanden?
• Lösen die Zielhostnamen direkt in A- oder AAAA-Adressen auf?
• Ist auf den Zielsystemen die betroffene Domain eingerichtet?
• Funktioniert eine echte Testzustellung von einem externen Anbieter?
• Zeigen SMTP-Fehlermeldung und Mailserver-Protokoll einen temporären oder dauerhaften Fehler?

Typische Ursachen sind ein am falschen DNS-Provider gepflegter Record, ein automatisch angehängter Domainname, alte und neue MX-Gruppen nebeneinander oder ein Zielserver, der die Domain noch nicht kennt. Ein erfolgreicher DNS-Test allein belegt deshalb noch keine funktionierende Zustellung.

Häufige Fragen

Dokumentiere nach der Umstellung, welcher Anbieter die MX-Ziele betreibt und wer für die Mailroute verantwortlich ist. Das verhindert, dass vermeintlich alte Records später ohne Prüfung entfernt oder fremde Ziele als Backup ergänzt werden.