MX-Records erklärt: Prioritäten, Konfigurationen und häufige Fehler

MX-Records (Mail Exchange Records) sind DNS-Einträge, die steuern, wohin eingehende E-Mails für deine Domain weitergeleitet werden. Ohne korrekte MX-Records können E-Mails von niemandem empfangen werden – egal wie gut dein SPF, DKIM und DMARC konfiguriert sind.

Was ist ein MX-Record?

Wenn jemand eine E-Mail an info@deinedomain.de schickt, muss der sendende Mailserver wissen, an welchen Server er die E-Mail zustellen soll. Dazu fragt er das DNS der Domain nach dem MX-Record (Mail Exchange Record).

Der MX-Record gibt den Hostnamen des zuständigen Mailservers an – also zum Beispiel mail.google.com oder mx1.deinedomain.de. Der sendende Server stellt die E-Mail dann direkt an diesen Mailserver zu.

MX-Records sind ausschließlich für eingehende E-Mails zuständig. Ausgehende E-Mails werden vom Mailserver selbst oder über SPF und DKIM abgewickelt. Ein fehlender oder falscher MX-Record bedeutet: Niemand kann dir eine E-Mail schicken.

Wie funktionieren MX-Prioritäten?

Jeder MX-Record hat eine Prioritätszahl (auch Preference oder Priority genannt). Diese ist eine positive ganze Zahl – je kleiner die Zahl, desto höher die Priorität.

Der sendende Mailserver versucht zunächst, die E-Mail an den MX-Server mit der niedrigsten Prioritätszahl zuzustellen. Ist dieser nicht erreichbar, wechselt er zum nächsten Server mit der nächsthöheren Zahl.

In diesem Beispiel wird zuerst mail1 versucht. Nur wenn dieser nicht antwortet, wird mail2 probiert. fallback kommt nur zum Einsatz, wenn die ersten beiden Optionen ausfallen.

Praxistipp: Wenn du zwei MX-Records mit gleicher Priorität (z.B. beide Priority 10) einrichtest, wählt der sendende Server zufällig einen aus – das ermöglicht einfaches Load Balancing.

Typische MX-Konfigurationen für bekannte Anbieter

Google Workspace

Google empfiehlt, alle fünf Server einzutragen, um maximale Ausfallsicherheit zu gewährleisten. Die Priorität 1 (aspmx.l.google.com) ist der primäre Server.

Microsoft 365 (Exchange Online)

Microsoft 365 nutzt nur einen MX-Record. Der genaue Hostname wird im Microsoft 365 Admin Center angezeigt und ist für jede Domain individuell (basiert auf dem Domainnamen).

IONOS (1&1)

IONOS nutzt zwei MX-Records für Ausfallsicherheit. Diese werden bei IONOS-Hosting-Paketen automatisch eingerichtet.

Strato

MX-Records und E-Mail-Authentifizierung

Der MX-Record allein schützt nicht vor E-Mail-Spoofing. Ein Angreifer, der E-Mails mit deiner Domain als Absender versendet, muss keine E-Mails empfangen – er muss nur so tun als ob er sie sendet. Deshalb braucht jede Domain zusätzlich:

• SPF – um festzulegen, wer senden darf
• DKIM – um E-Mails kryptografisch zu signieren
• DMARC – um die Policy bei Verstößen durchzusetzen

MX-Records und E-Mail-Authentifizierung sind zwei verschiedene Themen: MX steuert, wohin eingehende Mails kommen. SPF/DKIM/DMARC schützen, wer ausgehend senden darf.

Häufige Fehler bei MX-Records

Fehler 1: Punkt am Ende des Hostnamens vergessen

Im DNS wird ein vollqualifizierter Domainname (FQDN) mit einem abschließenden Punkt markiert. Viele DNS-Interfaces erwarten diesen Punkt (z. B. aspmx.l.google.com.). Fehlt er, wird der Hostname manchmal als relativ zur Domain interpretiert und führt zu Fehladressierungen.

Fehler 2: MX-Record zeigt auf eine IP-Adresse

MX-Records dürfen laut RFC 5321 nicht direkt auf IP-Adressen zeigen, sondern immer auf einen Hostnamen. Der Hostname muss dann über einen A- oder AAAA-Record in eine IP aufgelöst werden. MX direkt auf 1.2.3.4 zeigen zu lassen ist ein häufiger, aber kritischer Konfigurationsfehler.

Fehler 3: Alte MX-Records nicht gelöscht

Wenn du den E-Mail-Anbieter wechselst (z. B. von Strato zu Google Workspace), müssen die alten MX-Records gelöscht werden. Wenn alte und neue Records gleichzeitig existieren, landen E-Mails im ungünstigsten Fall beim alten Anbieter.

Fehler 4: TTL zu hoch beim Anbieterwechsel

Die TTL (Time To Live) bestimmt, wie lange DNS-Server den MX-Record cachen. Vor einem geplanten Anbieterwechsel solltest du die TTL 24–48 Stunden vorher auf einen niedrigen Wert (z. B. 300 Sekunden) reduzieren, damit die Änderung schnell weltweit greift.

MX-Records und Mailserver-Betrieb: Was noch wichtig ist

Der MX-Record allein reicht nicht aus, damit E-Mails zuverlässig zugestellt werden. Der im MX-Record genannte Mailserver muss:

• Über einen gültigen A-Record erreichbar sein (der MX-Hostname muss zu einer IP-Adresse auflösen)
• Auf Port 25 (SMTP) Verbindungen akzeptieren – viele Hosting-Provider blockieren Port 25 bei Shared Hosting
• Ein gültiges SSL/TLS-Zertifikat haben, damit STARTTLS und MTA-STS funktionieren
• Reverse-DNS (PTR-Record) korrekt konfiguriert haben – viele Mailserver verweigern Verbindungen von IPs ohne gültigen Reverse-DNS

Wenn du einen eigenen Mailserver betreibst (z. B. Postfix, Microsoft Exchange On-Premises, Dovecot), musst du alle diese Aspekte selbst konfigurieren. Bei Cloud-Diensten wie Google Workspace oder Microsoft 365 übernehmen die Anbieter diese Infrastruktur komplett – du musst nur die richtigen MX-Records setzen.

MX-Records prüfen: Warum die Quelle der Abfrage wichtig ist

Wenn du einen MX-Record änderst und sofort überprüfst, ob die Änderung wirksam ist, erhältst du mit Standard-DNS-Resolver-Tools (wie dig oder nslookup) möglicherweise noch das alte Ergebnis. Das liegt am DNS-Caching: Öffentliche Resolver wie 8.8.8.8 (Google) oder 1.1.1.1 (Cloudflare) cachen DNS-Antworten für die Dauer des TTL-Werts – manchmal mehrere Stunden.

Um sofort das aktuelle Ergebnis zu sehen, musst du direkt am autoritativen Nameserver der Domain abfragen. Das ist der Nameserver, den dein Domain-Registrar oder Hoster betreibt. Unser DMARC-Checker tut genau das – er fragt immer direkt am autoritativen Nameserver ab, damit du nach DNS-Änderungen sofort das tatsächliche Ergebnis siehst.

Weiterführende Artikel

• E-Mail-Authentifizierung einrichten: SPF, DKIM und DMARC
• DMARC erklärt: Policies und Reporting
• MTA-STS und TLS-RPT: Verschlüsselte E-Mail-Übertragung erzwingen