Mailserver mit mehreren Domains: PTR, MX, SPF und IPv6 richtig konfigurieren
Chris //Wer einen eigenen Mailserver betreibt, merkt manchmal erst dann, wie viele DNS-Einträge wirklich zusammenspielen müssen, wenn ein einzelner großer Mailanbieter plötzlich die Annahme verweigert.
Genau das ist mir passiert.
Mein Mailserver lief eigentlich unauffällig. E-Mails an Google/Gmail wurden zugestellt und auch Empfänger bei Microsoft 365 beziehungsweise Outlook akzeptierten meine Nachrichten problemlos. Entsprechend war ich zunächst ziemlich verwundert, als eine Nachricht an GMX plötzlich nicht mehr zugestellt werden konnte.
Die Rückmeldung von GMX war recht eindeutig:
554 No SMTP service
554 Invalid DNS PTR resource recordDas Überraschende daran: Der Mailserver selbst funktionierte. Postfix verschickte Nachrichten, SPF war vorhanden und andere große Anbieter akzeptierten die Mails.
Trotzdem war die Konfiguration nicht vollständig sauber.
Die Ursache lag letztlich beim Reverse DNS, genauer gesagt beim PTR-Record der öffentlichen IP-Adresse.
Und genau diese Erfahrung zeigt ganz gut: Nur weil Gmail oder Microsoft 365 eine E-Mail akzeptieren, bedeutet das nicht automatisch, dass die DNS-Konfiguration eines Mailservers vollständig korrekt ist.
Unterschiedliche Mailanbieter bewerten einzelne Kriterien unterschiedlich streng. Ein Anbieter kann eine Nachricht trotz einer nicht optimalen Reverse-DNS-Konfiguration annehmen, während ein anderer bereits die SMTP-Verbindung ablehnt.
In diesem Artikel zeige ich, wie man einen Plesk-Mailserver sauber für mehrere Domains konfiguriert, welche Rolle PTR, MX, A/AAAA, SPF und SRV spielen und worauf insbesondere bei IPv6 geachtet werden sollte.
Ausgangssituation
Nehmen wir folgenden beispielhaften Aufbau:
Domain:
example.com
Mailserver:
mail.example.com
IPv4:
203.0.113.10
IPv6:
2001:db8:100::10Der Server läuft beispielsweise als VPS bei einem Hoster und wird mit Plesk verwaltet.
Die Domain selbst kann durchaus bei einem anderen Registrar liegen. Die DNS-Zone kann wiederum bei Cloudflare verwaltet werden.
Das ist vollkommen problemlos.
Man muss lediglich unterscheiden, wer für welchen Eintrag zuständig ist:
Registrar
│
└── legt fest, welche Nameserver verwendet werden
│
▼
DNS-Provider
z. B. Cloudflare
│
├── A / AAAA
├── MX
├── SPF
├── DKIM
├── DMARC
└── SRV
VPS-Anbieter
│
└── PTR / Reverse DNS
Plesk / Server
│
├── Hostname
├── Postfix
├── Dovecot
└── TLS-ZertifikatDer PTR ist dabei eine Besonderheit: Er wird nicht dort gesetzt, wo die Domain verwaltet wird, sondern beim Anbieter der IP-Adresse.
Warum funktionierten Gmail und Microsoft 365 trotzdem?
Das war für mich zunächst der irritierendste Teil des Problems.
Wenn Nachrichten bei Gmail und Microsoft 365 ankommen, liegt die Vermutung nahe:
Der Mailserver kann eigentlich nicht grundsätzlich falsch konfiguriert sein.
Das stimmt auch teilweise.
Der Mailserver war tatsächlich funktionsfähig. Die SMTP-Kommunikation funktionierte, die Absenderdomain war grundsätzlich autorisiert und die Nachrichten konnten erfolgreich übertragen werden.
Aber Empfänger prüfen nicht alle Kriterien identisch.
Ein Mailanbieter kann beispielsweise bei der Bewertung berücksichtigen:
SPF
DKIM
DMARC
PTR / Reverse DNS
HELO/EHLO
IP-Reputation
Domain-Reputation
Nachrichteninhalt
VersandverhaltenWie streng einzelne Punkte behandelt werden, entscheidet jedoch der jeweilige Anbieter.
Google oder Microsoft können eine Nachricht unter bestimmten Umständen akzeptieren, obwohl der Reverse-DNS-Eintrag nicht optimal ist.
GMX kann dagegen bereits beim Verbindungsaufbau entscheiden:
Reverse DNS ungültig
↓
SMTP-Verbindung ablehnenDann kommt die eigentliche Nachricht überhaupt nicht mehr beim Empfänger an.
Genau das war hier der Fall.
Die wichtige Erkenntnis daraus:
Eine erfolgreiche Zustellung an einen großen Provider ist kein vollständiger Mailserver-Konfigurationstest.
Für einen sauber betriebenen Mailserver sollten deshalb alle relevanten DNS- und SMTP-Komponenten unabhängig davon korrekt konfiguriert sein, ob einzelne Anbieter eine weniger optimale Konfiguration noch tolerieren.
1. Der Mailserver braucht einen eindeutigen Hostnamen
Auch wenn ein Server mehrere Maildomains verwaltet, braucht der eigentliche Server nur einen einzigen Hostnamen.
Zum Beispiel:
mail.example.comDieser Hostname beschreibt den Server selbst.
Er hat nichts damit zu tun, von welcher Domain eine Nachricht später verschickt wird.
Ein Server kann also problemlos E-Mails verschicken wie:
max@example.com
info@example.net
kontakt@example.orgund sich gegenüber anderen Mailservern trotzdem immer melden als:
mail.example.comGenau das ist sogar empfehlenswert.
2. A-Record des Mailservers
Zunächst braucht der Server einen normalen DNS-Eintrag:
mail.example.com. A 203.0.113.10Bei IPv6 zusätzlich:
mail.example.com. AAAA 2001:db8:100::10Bei Cloudflare muss der Mailhost unbedingt auf:
DNS onlystehen.
Also keine orange Cloudflare-Proxy-Wolke.
SMTP, IMAP und POP3 werden nicht über den normalen Cloudflare-Webproxy geleitet.
3. PTR / Reverse DNS
Jetzt kommt der Eintrag, der in meinem Fall letztlich für die Ablehnung verantwortlich war.
Der normale DNS-Eintrag sagt:
mail.example.com
↓
203.0.113.10Der PTR macht genau das Gegenteil:
203.0.113.10
↓
mail.example.comDamit ergibt sich:
mail.example.com
│
│ A
▼
203.0.113.10
│
│ PTR
▼
mail.example.comDas wird häufig als Forward-confirmed Reverse DNS bezeichnet.
Der entscheidende Punkt:
Der PTR wird beim Anbieter des VPS beziehungsweise der öffentlichen IP-Adresse eingerichtet.
Nicht bei Cloudflare.
Nicht beim Domain-Registrar.
Nicht direkt in Plesk.
Für IPv6 sollte dasselbe gelten:
2001:db8:100::10
↓ PTR
mail.example.comund umgekehrt:
mail.example.com
↓ AAAA
2001:db8:100::104. Plesk-Hostname ebenfalls anpassen
Der PTR alleine ist nur ein Teil der Konfiguration.
Der SMTP-Server sollte sich ebenfalls mit demselben Hostnamen melden.
Ideal ist daher:
A:
mail.example.com → 203.0.113.10
PTR:
203.0.113.10 → mail.example.com
SMTP HELO/EHLO:
mail.example.com
Plesk/Systemhostname:
mail.example.comIn Plesk lässt sich der Serverhostname unter:
Tools & Einstellungen → Servereinstellungen → Vollständiger Hostname
ändern.
Dort trägt man beispielsweise ein:
mail.example.comAnschließend kann man per SSH prüfen:
hostname -fund:
postconf myhostnameBeide sollten idealerweise zurückgeben:
mail.example.com5. Ein PTR reicht auch für mehrere Domains
Ein häufiges Missverständnis ist, dass jede Maildomain einen eigenen PTR benötigen würde.
Das ist nicht der Fall.
Angenommen, derselbe Server verwaltet:
example.com
example.net
example.orgDann können alle drei Domains denselben Mailserver verwenden:
example.com. MX 10 mail.example.com.
example.net. MX 10 mail.example.com.
example.org. MX 10 mail.example.com.Der PTR bleibt trotzdem:
203.0.113.10 → mail.example.comDer PTR gehört zur IP-Adresse des Mailservers, nicht zur Absenderdomain.
6. MX-Record richtig setzen
Für die Hauptdomain könnte der MX-Eintrag beispielsweise so aussehen:
example.com. MX 10 mail.example.com.Bei Cloudflare entspricht das ungefähr:
Typ: MX
Name: @
Ziel: mail.example.com
Priorität: 10Wichtig:
Ein MX-Record sollte auf einen Hostname zeigen, nicht direkt auf eine IP-Adresse.
Also:
MX 10 mail.example.comund nicht:
MX 10 203.0.113.107. SPF sauber konfigurieren
SPF legt fest, welche Server berechtigt sind, E-Mails für eine Domain zu versenden.
Wenn ausschließlich ein Server versendet, kann ein SPF beispielsweise so aussehen:
v=spf1 ip4:203.0.113.10 ip6:2001:db8:100::10 -allBei zwei Mailservern:
v=spf1 ip4:203.0.113.10 ip6:2001:db8:100::10 ip4:198.51.100.20 ip6:2001:db8:200::20 -allDas ist oftmals übersichtlicher als eine lange Mischung aus:
a
mx
a:mail.example.com
ip4:...
ip6:...Mit expliziten IP-Adressen ist sofort ersichtlich, welche Systeme tatsächlich E-Mails versenden dürfen.
8. Achtung bei IPv6
IPv6 ist bei Mailservern ein Punkt, der leicht übersehen wird.
Ist IPv6 auf dem Server aktiviert, kann Postfix auch über IPv6 ausgehend zustellen.
Dann sollte für diese IPv6-Adresse ebenfalls alles stimmen:
SPF
PTR
AAAA
HostnameAlso zum Beispiel:
SPF:
ip6:2001:db8:100::10
AAAA:
mail.example.com → 2001:db8:100::10
PTR:
2001:db8:100::10 → mail.example.comFehlt insbesondere der PTR für IPv6, kann IPv4 perfekt konfiguriert sein und die Zustellung trotzdem scheitern, sobald Postfix für eine Verbindung IPv6 verwendet.
Wer IPv6 für SMTP nicht sauber konfigurieren kann oder möchte, sollte deshalb prüfen, ob der Mailserver überhaupt ausgehend über IPv6 versenden soll.
9. DKIM nicht vergessen
SPF alleine reicht heute nicht mehr.
Zusätzlich sollte jede Maildomain über einen eigenen DKIM-Schlüssel verfügen.
Bei Plesk lässt sich DKIM normalerweise pro Domain aktivieren.
Ein Eintrag sieht beispielsweise so aus:
default._domainkey.example.commit einem TXT-Wert ähnlich:
v=DKIM1; k=rsa; p=...Der tatsächliche öffentliche Schlüssel wird von Plesk erzeugt und muss exakt in die DNS-Zone übernommen werden.
Mehrere Domains auf demselben Mailserver können und sollten jeweils ihren eigenen DKIM-Schlüssel besitzen.
10. DMARC ergänzen
Nach SPF und DKIM sollte auch DMARC eingerichtet werden.
Ein vorsichtiger Einstieg ist beispielsweise:
_dmarc.example.commit:
v=DMARC1; p=noneDamit werden zunächst noch keine Nachrichten aufgrund der DMARC-Policy abgelehnt.
Später kann man die Richtlinie verschärfen, etwa auf:
v=DMARC1; p=quarantineoder:
v=DMARC1; p=rejectBevor reject verwendet wird, sollte allerdings sichergestellt sein, dass wirklich alle legitimen Versandwege korrekt über SPF beziehungsweise DKIM authentifiziert werden.
11. SRV-Records für Mailclients
Optional können SRV-Records hinterlegt werden, damit Mailprogramme die richtigen Server und Ports leichter finden.
Für IMAPS:
_imaps._tcp.example.com
SRV 0 0 993 mail.example.com.Für POP3S:
_pop3s._tcp.example.com
SRV 0 0 995 mail.example.com.Für SMTP Submission mit STARTTLS:
_submission._tcp.example.com
SRV 0 0 587 mail.example.com.Für Submission mit implizitem TLS auf Port 465:
_submissions._tcp.example.com
SRV 0 0 465 mail.example.com.Damit ergibt sich beispielsweise:
| Dienst | Port | Ziel |
|---|---|---|
| IMAPS | 993 | mail.example.com |
| POP3S | 995 | mail.example.com |
| SMTP Submission | 587 | mail.example.com |
| SMTP Submission TLS | 465 | mail.example.com |
Der Mailhost sollte dafür natürlich ein gültiges TLS-Zertifikat für mail.example.com besitzen.
12. Plesk-Webzugriff und Mailhostname müssen nicht identisch sein
Nur weil der Serverhostname
mail.example.comlautet, muss die Plesk-Oberfläche nicht zwingend unter derselben Adresse öffentlich zugänglich sein.
Plesk kann beispielsweise weiterhin laufen unter:
https://mail.example.com:8443während davor ein Reverse Proxy oder eine Zero-Trust-Lösung verwendet wird:
https://plesk.admin-example.com
↓
Reverse Proxy
↓
https://mail.example.com:8443Damit lassen sich die Rollen sauber trennen:
mail.example.com
→ SMTP-/IMAP- und Serverhostname
plesk.admin-example.com
→ Verwaltungsoberfläche13. DNS-Konfiguration prüfen
Nach den Änderungen sollte man die Auflösung kontrollieren.
IPv4
dig mail.example.com AErwartet:
203.0.113.10IPv6
dig mail.example.com AAAAErwartet:
2001:db8:100::10Reverse DNS IPv4
dig -x 203.0.113.10Erwartet:
mail.example.com.Reverse DNS IPv6
dig -x 2001:db8:100::10Erwartet ebenfalls:
mail.example.com.MX
dig example.com MXSPF
dig example.com TXTDMARC
dig _dmarc.example.com TXT14. Die ideale DNS-Kette
Am Ende sollte die Konfiguration ungefähr so aussehen:
example.com
│
│ MX
▼
mail.example.com
│ │
A │ │ AAAA
▼ ▼
203.0.113.10 2001:db8:100::10
│ │
PTR │ │ PTR
└─────┬─────┘
▼
mail.example.comZusätzlich:
SMTP HELO/EHLO:
mail.example.com
Systemhostname:
mail.example.com
TLS-Zertifikat:
mail.example.comDamit ist die Identität des Mailservers in sich konsistent.
Fazit
Die interessanteste Erkenntnis bei diesem Problem war für mich, dass Gmail und Microsoft 365 meine Nachrichten bereits problemlos akzeptiert hatten.
Deshalb hatte ich zunächst gar nicht mit einem grundsätzlichen DNS-Problem gerechnet.
Erst die deutlich strengere Fehlermeldung eines anderen Providers machte sichtbar, dass beim Reverse DNS noch etwas nicht sauber konfiguriert war:
554 Invalid DNS PTR resource recordDas zeigt sehr schön, warum man die Funktionsfähigkeit eines eigenen Mailservers nicht nur daran messen sollte, ob eine Testmail bei Gmail ankommt.
Ein eigener Mailserver kann problemlos mehrere Domains verwalten. Man benötigt dafür auch nicht pro Domain einen eigenen PTR oder einen eigenen Serverhostname.
Entscheidend ist eine konsistente Identität des eigentlichen Mailservers:
A/AAAA
↕
PTR
↕
Serverhostname
↕
SMTP HELO/EHLOAlle sollten auf denselben Hostnamen verweisen, beispielsweise:
mail.example.comDie einzelnen Maildomains erhalten anschließend jeweils ihre eigenen MX-, SPF-, DKIM- und DMARC-Einträge.
Besonders IPv6 sollte dabei nicht vergessen werden. Sobald der Mailserver darüber Nachrichten verschickt, muss auch diese Adresse sauber in die Mailserver-Konfiguration eingebunden sein.
Und vielleicht die wichtigste Lektion aus der ganzen Sache:
„Meine Mails kommen bei Google und Microsoft an“ und „mein Mailserver ist vollständig korrekt konfiguriert“ sind nicht zwangsläufig dasselbe.