Um einen MX-Record einzurichten, legst du in der DNS-Zone einen Eintrag vom Typ MX für @ an, mit einer Priorität wie 10 und einem Hostnamen als Ziel, zum Beispiel mail.example.com. Dieser Hostname braucht einen eigenen A-Record (und gegebenenfalls AAAA) auf den Mailserver. Dazu gehören für zustellbare Mail SPF, DKIM, DMARC und ein passender PTR-Record.
Den MX-Record selbst einzurichten dauert eine Minute. Dass Mails danach auch wirklich bei Gmail oder Outlook im Posteingang landen, hängt an fünf weiteren Einträgen, von denen einer nicht einmal in deiner Zone steht. Wer einen Postfix auf einem VServer betreibt, sollte alle sechs auf einmal setzen.
Was der MX-Record macht
Der MX-Record (Mail Exchanger) sagt anderen Mailservern, wohin sie Mails für @example.com zustellen sollen. Er zeigt auf einen Hostnamen, nicht auf eine IP, und trägt eine Priorität:
$ORIGIN example.com.
@ 3600 IN MX 10 mail.example.com.
mail 3600 IN A 192.0.2.25
mail 3600 IN AAAA 2001:db8:10::25Ein absendender Server fragt MX example.com, bekommt mail.example.com, löst diesen Namen auf und verbindet sich auf Port 25. Zwei Regeln aus RFC 2181 und RFC 5321 gelten dabei hart: Das Ziel ist ein Name mit eigenem A- oder AAAA-Record, und es ist kein CNAME. Warum, steht im Artikel CNAME oder A-Record.
Prioritäten bei mehreren MX-Einträgen
| Eintrag | Bedeutung |
|---|---|
MX 10 mail.example.com. | Primärer Server |
MX 20 backup.example.net. | Wird nur benutzt, wenn 10 nicht erreichbar ist |
MX 10 mx1.example.com. + MX 10 mx2.example.com. | Gleichrangig, Last wird verteilt |
MX 0 . | Null-MX: Domain empfängt keine Mail (RFC 7505) |
Einen Backup-MX brauchst du für einen einzelnen VServer meist nicht. Absendende Server stellen bei Nichterreichbarkeit nicht sofort zurück, sondern versuchen es über Tage erneut. Ein schlecht gepflegter Backup-MX ohne Spamfilter ist dagegen ein beliebtes Einfallstor für Spam.
Den Null-MX solltest du für jede Domain setzen, die keine Mail empfängt. Ohne MX versuchen Absender sonst, an den A-Record zuzustellen, also an deinen Webserver.
MX-Record einrichten: alle Einträge für Postfix
Für einen eigenen Mailserver mit Postfix sieht die vollständige Zone so aus:
$ORIGIN example.com.
@ 3600 IN MX 10 mail.example.com.
mail 3600 IN A 192.0.2.25
mail 3600 IN AAAA 2001:db8:10::25
@ 3600 IN TXT "v=spf1 mx -all"
mail._domainkey 3600 IN TXT "v=DKIM1; k=rsa; p=MIIBIjANBgkqh...IDAQAB"
_dmarc 3600 IN TXT "v=DMARC1; p=none; rua=mailto:[email protected]"Kurz zu jedem:
SPF listet, wer für die Domain senden darf. mx erlaubt die Server aus dem MX-Record, -all lehnt alle anderen ab. Verschickt zusätzlich ein Newsletter-Dienst in deinem Namen, kommt dessen include: dazu. Pro Domain darf es nur einen SPF-Record geben.
DKIM signiert ausgehende Mails. Den Schlüssel erzeugst du auf dem Server, mit OpenDKIM zum Beispiel per opendkim-genkey -s mail -d example.com. Der Teil vor ._domainkey ist der Selektor und muss mit der Konfiguration übereinstimmen. Lange Schlüssel teilen manche Panels auf mehrere Zeichenketten auf, das ist in Ordnung.
DMARC sagt Empfängern, was bei SPF- oder DKIM-Fehlern passieren soll, und wohin sie Berichte schicken. Starte mit p=none, lies ein paar Wochen die Berichte und geh dann auf quarantine oder reject. Gmail und Yahoo verlangen seit 2024 von Absendern mindestens SPF oder DKIM, von Massenversendern zusätzlich DMARC.
All diese Einträge legst du bei betadomain im Kundenbereich bei den DNS-Einträgen der Domain an, TXT-Werte ohne die umschließenden Anführungszeichen, sofern das Panel sie nicht selbst erwartet.
Der Eintrag, der nicht in deiner Zone steht: PTR
Viele Empfänger prüfen, ob die IP deines Mailservers einen Reverse-DNS-Eintrag hat und ob dieser zum Hostnamen passt. Der PTR-Record liegt in der Zone deines Hosters, nicht in deiner, und wird in dessen Panel gesetzt. Ohne ihn landen Mails im Spam oder werden direkt abgelehnt. Wie das geht und welche Werte passen müssen, steht unter Reverse DNS und PTR-Record.
In Postfix muss myhostname dazu passen:
postconf myhostnamemyhostname = mail.example.comDer HELO-Name, der PTR der IP und der A-Record von mail.example.com sollten alle dasselbe sagen.
MX-Record und Mail-DNS prüfen
dig example.com MX +short
dig mail.example.com A +short
dig example.com TXT +short | grep spf
dig mail._domainkey.example.com TXT +short
dig _dmarc.example.com TXT +short
dig -x 192.0.2.25 +shortDann einmal von außen auf Port 25 und STARTTLS:
openssl s_client -starttls smtp -connect mail.example.com:25 -servername mail.example.comSchlägt die Verbindung von einem anderen Server aus fehl, obwohl Postfix läuft, prüfe die Firewall. Umgekehrt sperren manche VServer-Anbieter ausgehenden Port 25 für neue Kunden, bis man ihn per Support-Anfrage freischalten lässt. Das merkst du daran, dass Mails in der Queue (postqueue -p) mit Verbindungs-Timeouts hängen bleiben.
Ein Zertifikat für den Mail-Hostnamen
Absender verschlüsseln per STARTTLS, wenn dein Server es anbietet. Mit einem gültigen Zertifikat für mail.example.com vermeidest du Warnungen in Mail-Clients bei IMAP und Submission. Läuft auf dem Server ohnehin nginx, holst du es per certbot und trägst die Pfade in Postfix ein:
certbot certonly --nginx -d mail.example.com
postconf -e 'smtpd_tls_cert_file = /etc/letsencrypt/live/mail.example.com/fullchain.pem'
postconf -e 'smtpd_tls_key_file = /etc/letsencrypt/live/mail.example.com/privkey.pem'
systemctl reload postfixNach jeder Erneuerung muss Postfix (und Dovecot) neu laden, am einfachsten per --deploy-hook.
Die vier häufigsten Fehler beim MX-Record
- MX zeigt auf die Domain selbst (
MX 10 example.com.). Funktioniert, bis du die Website auf einen anderen Server umziehst. Dann wandert die Mail mit. Ein eigener Namemailtrennt beides. - Alte MX-Einträge bleiben stehen. Nach dem Wechsel vom Hoster-Postfach zum eigenen Server stehen dessen MX oft noch mit niedrigerer Priorität drin.
dig MXzeigt sie. - Zwei SPF-Records. Ein alter vom Hoster, ein neuer von dir. Das ergibt laut RFC 7208 einen permanenten Fehler, als hätte die Domain gar keinen SPF. Zusammenführen.
- AAAA ohne IPv6-PTR. Bekommt
maileinen AAAA-Record, stellt Postfix auch über IPv6 zu, und Gmail lehnt IPv6-Absender ohne PTR ab. Mehr dazu beim AAAA-Record.
MX umstellen ohne Mailverlust
Wechselst du den Mailserver, senke die TTL des MX vorher, wie im Artikel zur DNS-TTL beschrieben. Lass den alten Server so lange Mail annehmen, bis die alte TTL abgelaufen ist, und hol danach die Reste per IMAP-Sync (imapsync) ab. Absender, die in der Übergangszeit eine temporäre Ablehnung bekommen, versuchen es später erneut.
Nächster Schritt
Setz den PTR beim Hoster, dann den Testversand an ein Gmail-Konto und schau dir dort im Original der Mail die Zeilen für SPF, DKIM und DMARC an. Brauchst du eine eigene Domain nur für Mail, kannst du die passende Adresse bei betadomain finden. Eine .email-Domain kostet 29,99 € im Jahr, eine klassische .de für den Mailserver 2,99 €.
Schritt für Schritt
- A-Record für den Mail-Hostnamen setzenmail.example.com per A- und optional AAAA-Record auf die IP des Mailservers zeigen lassen.
- MX-Record anlegenFür @ einen MX mit Priorität 10 und Ziel mail.example.com anlegen und alte MX-Einträge entfernen.
- SPF setzenEinen TXT-Record auf @ mit v=spf1 mx -all anlegen, sodass nur der MX-Server für die Domain senden darf.
- DKIM einrichtenSchlüssel mit OpenDKIM oder rspamd erzeugen und den öffentlichen Teil als TXT unter selektor._domainkey veröffentlichen.
- DMARC veröffentlichenUnter _dmarc einen TXT mit v=DMARC1; p=none; rua=mailto:... anlegen und nach einigen Wochen Auswertung verschärfen.
- PTR beim Hoster setzen und testenDen Reverse-DNS der Server-IP auf mail.example.com setzen und mit dig MX, dig -x und einem Testversand prüfen.
Domain gefunden? Prüfen und registrieren kannst du sie direkt bei Domain-Preise vergleichen – Jahrespreis ab 2,99 €.
Häufige Fragen
Kann ein MX-Record direkt auf eine IP-Adresse zeigen?
Nein. Das Ziel eines MX-Records muss ein Hostname sein, der seinerseits einen A- oder AAAA-Record hat. Panels, die eine IP annehmen, legen intern meist einen Hilfsnamen an oder speichern einen ungültigen Eintrag.
Was bedeutet die Zahl vor dem MX-Ziel?
Das ist die Priorität (Preference). Absender versuchen zuerst den Eintrag mit der niedrigsten Zahl. Mehrere MX mit gleicher Zahl teilen sich die Last, höhere Zahlen sind Backup-Server.
Was passiert, wenn eine Domain gar keinen MX-Record hat?
Nach RFC 5321 versuchen Absender dann, an den A- oder AAAA-Record der Domain zuzustellen. Willst du für eine Domain ausdrücklich keine Mail empfangen, setzt du einen Null-MX nach RFC 7505 mit Priorität 0 und dem Ziel Punkt.
Wie lange dauert es, bis ein neuer MX-Record wirkt?
So lange wie die TTL des alten MX-Eintrags. Mailserver, die zwischenzeitlich den alten Server erreichen und abgewiesen werden, versuchen es mehrere Tage lang erneut. Kurze Übergänge verlieren deshalb in der Regel keine Mail.