Reverse DNS (PTR) und IPv6 für Mailserver korrekt einrichten – Zustellbarkeit sichern

Wer einen eigenen Mailserver betreibt, braucht einen korrekten Reverse-DNS-Eintrag (PTR-Record). Ohne ihn landen E-Mails bei Google, Microsoft oder GMX im Spam oder werden abgewiesen. Diese Anleitung zeigt, wie Sie den PTR-Record für IPv4 und IPv6 setzen und mit FCrDNS (Forward-Confirmed Reverse DNS) die Zustellbarkeit absichern. Sie richtet sich an Administratoren, die einen Mailserver auf einem Root-Server oder VPS mit fester IP betreiben.

Was ist Reverse DNS (PTR) und warum ist es für Mailserver so wichtig?

Beim normalen (Forward-)DNS lautet die Frage: „Welche IP gehört zum Namen mail.example.com?“ Die Antwort liefert der A-Record (IPv4) bzw. AAAA-Record (IPv6). Reverse DNS dreht das um: „Welcher Hostname gehört zu dieser IP?“ Diese Auflösung liefert der PTR-Record (Pointer Record).

Empfangende Mailserver prüfen bei jeder eingehenden Verbindung, ob die sendende IP überhaupt einen PTR-Eintrag besitzt und ob dieser plausibel ist. Fehlt der PTR oder zeigt er auf einen generischen Provider-Namen wie p5dxxxxxx.dip0.t-ipconnect.de, stuft der Empfänger die Mail als verdächtig ein. Große Anbieter bremsen oder blockieren Mails von IPs ohne gültigen PTR. Gmail antwortet etwa mit 421 4.7.23 (temporär gedrosselt) oder 550 5.7.25 (abgewiesen).

Wie ist ein PTR-Record technisch aufgebaut?

PTR-Records leben in speziellen DNS-Zonen, die aus der IP-Adresse abgeleitet werden:

1. IPv4: Die vier Oktette werden umgedreht und mit der Domain .in-addr.arpa ergänzt. Aus der IP 203.0.113.25 wird die PTR-Abfrage 25.113.0.203.in-addr.arpa.
2. IPv6: Jedes Nibble (Hex-Ziffer) der voll ausgeschriebenen Adresse wird umgedreht und mit .ip6.arpa ergänzt. Aus 2001:db8::25 (ausgeschrieben 2001:0db8:0000:...:0025) entsteht eine lange Punkt-getrennte Nibble-Kette plus .ip6.arpa.

Was bedeutet FCrDNS?

FCrDNS steht für Forward-Confirmed reverse DNS. Das heißt: Der PTR der IP zeigt auf einen Hostnamen, und der A- bzw. AAAA-Record dieses Hostnamens zeigt wieder zurück auf genau dieselbe IP. Erst dieser geschlossene Kreis macht den Eintrag aus Sicht der Empfänger glaubwürdig. Ein PTR allein reicht nicht – ohne passenden Forward-Record bleibt die Zustellbarkeit schlecht.

Voraussetzungen

1. Eine statische, Ihnen zugeordnete IPv4-Adresse (und optional ein IPv6-Block) auf einem Root-Server, VPS oder dedizierten Server.
2. Zugriff auf das Hoster-/Provider-Panel, in dem Sie die Reverse-DNS-Zone der IP bearbeiten können (z. B. Hetzner Robot/Cloud Console, netcup SCP, IONOS, OVH).
3. Eine eigene Domain mit Zugriff auf den Forward-DNS (A-, AAAA- und MX-Records).
4. Ein laufender Mailserver (Postfix, Exim, Mailcow, mailu o. ä.) mit einem klar definierten FQDN als HELO/EHLO-Name.
5. Ein Linux-System mit dig (Paket dnsutils bzw. bind-utils) oder ein Windows-PC mit nslookup zum Testen.

Ein Mailserver auf einem Anschluss mit dynamischer IP (DSL, Kabel) scheitert an dieser Stelle: Den PTR solcher Adressen setzt nur der Provider, und viele Empfänger lehnen Einwahl-Adressbereiche grundsätzlich ab.

Schritt 1: FQDN und Forward-Records (A/AAAA) festlegen

Vor dem PTR braucht es einen sauberen Forward-Eintrag, auf den der PTR später zeigt. Wählen Sie einen eigenen Hostnamen für den Mailserver, üblich ist mail.example.com.

1. Legen Sie in Ihrer DNS-Zone einen A-Record für die IPv4-Adresse an.
2. Nutzen Sie IPv6, legen Sie zusätzlich einen AAAA-Record für die IPv6-Adresse an.
3. Stellen Sie sicher, dass der Mailserver diesen FQDN auch als HELO/EHLO-Namen verwendet.

Beispiel für die Forward-Zone (BIND-Notation):

mail.example.com.   IN  A      203.0.113.25
mail.example.com.   IN  AAAA   2001:db8::25
example.com.        IN  MX  10  mail.example.com.

In den meisten Webpanels geben Sie stattdessen Typ, Name und Wert ein, etwa Typ A, Name mail, Wert 203.0.113.25.

Verifizieren: dig A mail.example.com +short liefert 203.0.113.25, dig AAAA mail.example.com +short liefert 2001:db8::25.

Schritt 2: PTR-Record für IPv4 in der Reverse-Zone setzen

Der PTR-Record steht nicht in Ihrer normalen Domain-Zone, sondern in der Reverse-Zone der IP. Diese verwaltet der Inhaber der IP, also Ihr Hoster. Im Panel heißt das Feld meist „Reverse DNS“, „rDNS“ oder „PTR“.

1. Öffnen Sie im Hoster-Panel die Verwaltung Ihrer IP-Adresse (Server- oder IP-Übersicht).
2. Wählen Sie die Option Reverse DNS / PTR für die betreffende IPv4-Adresse.
3. Tragen Sie als Wert den FQDN ein, exakt wie im A-Record: mail.example.com (ohne http://, ohne Slash, idealerweise mit abschließendem Punkt, falls das Panel das verlangt).
4. Speichern. Der Hoster schreibt die Änderung in die Zone in-addr.arpa geschrieben.

Hat Ihnen der Provider eine eigene Reverse-Zone delegiert und verwalten Sie diese selbst per BIND, sieht der Eintrag so aus:

; Reverse-Zone 113.0.203.in-addr.arpa
25   IN   PTR   mail.example.com.

Empfehlung: Setzen Sie pro IP genau einen PTR-Record. Mehrere PTR-Einträge auf einer IP liefern unzuverlässige Ergebnisse und können von Empfängern als unsauber bewertet werden.

Verifizieren: dig -x 203.0.113.25 +short gibt mail.example.com. aus. Steht dort noch der Standardname des Hosters, ist die Änderung noch nicht aktiv oder bei der falschen IP gespeichert.

Schritt 3: PTR-Record für IPv6 einrichten

Sendet der Mailserver auch über IPv6, braucht auch die IPv6-Adresse einen PTR. Google stellt für IPv6 eigene, strengere Anforderungen (PTR plus passender AAAA-Record, zusätzlich SPF oder DKIM) und weist Verstöße mit 550 5.7.1 ab.

1. Konfigurieren Sie den Mailserver so, dass er für ausgehende Verbindungen genau die eine IPv6-Adresse nutzt, für die AAAA und PTR gepflegt sind. Bei einem /64-Block darf er keine zufälligen Adressen (Privacy Extensions) verwenden.
2. Öffnen Sie im Hoster-Panel den Reverse-DNS-Eintrag für diese IPv6-Adresse.
3. Tragen Sie als Wert wieder denselben FQDN ein: mail.example.com.
4. Speichern. Der Eintrag landet in der Zone ip6.arpa.

Bei Postfix legen Sie die feste Quell-IPv6 so fest, damit HELO und PTR zusammenpassen:

postconf -e "smtp_bind_address6 = 2001:db8::25"
postconf -e "myhostname = mail.example.com"
systemctl restart postfix

So sendet Postfix immer von der Adresse, für die PTR und AAAA gepflegt sind. Voraussetzung ist, dass diese Adresse auf dem Server konfiguriert ist, sonst schlagen ausgehende IPv6-Verbindungen fehl.

Verifizieren: dig -x 2001:db8::25 +short gibt mail.example.com. aus, postconf smtp_bind_address6 myhostname zeigt die gesetzten Werte.

Schritt 4: FCrDNS herstellen – Forward und Reverse abgleichen

Damit FCrDNS erfüllt ist, muss Folgendes gelten:

1. PTR von 203.0.113.25 → mail.example.com
2. A von mail.example.com → 203.0.113.25 (identische IP)
3. PTR von 2001:db8::25 → mail.example.com
4. AAAA von mail.example.com → 2001:db8::25 (identische IP)

Vorwärts- und Rückwärtsauflösung müssen exakt dieselben IPs ergeben. Ein Tippfehler (etwa .24 statt .25) bricht FCrDNS und damit die Zustellbarkeit. Der Mailserver muss im SMTP-Dialog genau diesen FQDN als HELO/EHLO melden, sonst passen Banner, PTR und Forward nicht zusammen.

Verifizieren: Alle vier Zeilen der Liste stimmen mit den Ausgaben von dig -x und dig A/AAAA überein (Befehle in Schritt 5).

Schritt 5: Verifikation – PTR und FCrDNS testen

DNS-Änderungen brauchen je nach TTL und Provider einige Minuten bis Stunden, bis sie sichtbar sind. Danach prüfen Sie den PTR mit Standardwerkzeugen.

Verifikation unter Linux mit dig

Die Reverse-Auflösung (PTR) testen Sie mit dig -x:

# IPv4-PTR prüfen
dig -x 203.0.113.25 +short

# IPv6-PTR prüfen
dig -x 2001:db8::25 +short

# Forward gegenprüfen (FCrDNS)
dig A mail.example.com +short
dig AAAA mail.example.com +short

Der erste Befehl sollte mail.example.com. ausgeben, die Forward-Abfragen wieder 203.0.113.25 bzw. 2001:db8::25. Stimmen beide Richtungen überein, ist FCrDNS erfüllt.

Verifikation unter Windows mit nslookup

nslookup 203.0.113.25
nslookup 2001:db8::25
nslookup mail.example.com

Unter „Name:“ erscheint bei der IP-Abfrage Ihr FQDN. Alternativ liefern Onlinedienste wie MXToolbox oder die Google Admin Toolbox eine schnelle Sichtprüfung von PTR, MX und SMTP-Banner.

SMTP-Banner und HELO gegenprüfen

Ein kurzer manueller Test zeigt, ob sich der Server mit dem richtigen Namen meldet. openssl s_client -starttls smtp eignet sich dafür nicht, weil OpenSSL den Begrüßungstext selbst verarbeitet und nicht anzeigt. Verwenden Sie eine einfache TCP-Verbindung und beenden Sie sie mit QUIT:

nc mail.example.com 25

Verifizieren: Im Banner (220 mail.example.com ESMTP) steht derselbe FQDN wie im PTR, und dig -x liefert für IPv4 und IPv6 diesen Namen.

Updates & Wartung

Reverse DNS muss nach Änderungen am Server nachgezogen werden:

1. IP-Wechsel: Ziehen Sie den Server um oder erhalten Sie eine neue IP, setzen Sie A/AAAA und die PTR-Records neu. Planen Sie den Umzug so, dass alte und neue IP kurzzeitig beide sauber aufgelöst werden.
2. FQDN-Änderung: Benennen Sie den Mailhost um, passen Sie Forward-Record, PTR und den HELO-/myhostname-Wert gemeinsam an.
3. Monitoring: Überwachen Sie PTR und Blacklist-Status regelmäßig, etwa über MXToolbox-Monitoring oder ein eigenes Skript mit dig -x, das bei Abweichung alarmiert.
4. Mailserver-Patches: Halten Sie den MTA aktuell. Sicherheitslücken in Mailservern werden aktiv ausgenutzt, ein Beispiel ist der Exim-4.99.3-Patch gegen die GnuTLS-RCE CVE-2026-45185.

Backup-Hinweis

Exportieren Sie die Forward-Zone (Zonefile bzw. Panel-Export) und dokumentieren Sie die gesetzten PTR-Werte je IP. Reverse-Zonen lassen sich bei vielen Hostern nicht exportieren. Die Dokumentation zeigt nach einem Hoster-Wechsel sofort, welcher PTR zu welcher IP gehört.

Troubleshooting

1. PTR existiert nicht (NXDOMAIN bei dig -x): Der Eintrag wurde noch nicht delegiert oder die TTL ist noch nicht abgelaufen. Prüfen Sie im Hoster-Panel, ob gespeichert wurde, und warten Sie die TTL ab.
2. PTR zeigt auf Hoster-Default (z. B. static.xxx.provider.net): Der eigene PTR fehlt oder steht bei der falschen IP. Tragen Sie den FQDN im rDNS-Feld der korrekten IP ein.
3. FCrDNS schlägt fehl: PTR und Forward zeigen auf unterschiedliche IPs. Vergleichen Sie dig -x IP mit dig A/AAAA FQDN und korrigieren Sie den abweichenden Eintrag.
4. Mails von IPv6 werden abgewiesen, von IPv4 nicht: Es fehlt der IPv6-PTR oder AAAA. Setzen Sie beide oder beschränken Sie Postfix ausgehend auf IPv4 (smtp_address_preference = ipv4 oder inet_protocols = ipv4), bis der IPv6-PTR steht.
5. Google/Microsoft lehnen weiter ab (550 5.7.x): Neben PTR fehlen oft SPF, DKIM und DMARC, oder die IP steht auf einer Blacklist. PTR ist notwendig, aber nicht allein hinreichend für gute Zustellbarkeit.
6. HELO passt nicht zum PTR: Setzen Sie myhostname (Postfix) bzw. primary_hostname (Exim) auf denselben FQDN wie im PTR.

Häufige Fragen

Wo trage ich den PTR-Record ein, in meiner DNS-Zone oder beim Hoster?

Den PTR-Record setzt der Inhaber der IP, also Ihr Hoster bzw. Provider. In Ihrer Domain-Zone pflegen Sie nur die Forward-Records (A, AAAA, MX). Den PTR finden Sie im Server- oder IP-Panel des Hosters unter „Reverse DNS“ oder „rDNS“. Für netcup zeigt das die Anleitung Reverse-DNS im netcup SCP setzen.

Brauche ich für IPv6 wirklich einen eigenen PTR-Record?

Ja. Sobald der Mailserver über IPv6 versendet, verlangen große Anbieter wie Google einen gültigen PTR und einen passenden AAAA-Record für die sendende IPv6-Adresse. Fehlt der IPv6-PTR, werden Mails abgewiesen, auch wenn der IPv4-PTR korrekt ist.

Wie lange dauert es, bis ein PTR-Record aktiv ist?

Das hängt von der TTL der Reverse-Zone und vom Caching der abfragenden Resolver ab. In der Praxis sind PTR-Änderungen meist nach wenigen Minuten bis zu einigen Stunden sichtbar. Mit dig -x IP @1.1.1.1 fragen Sie gezielt einen externen Resolver und umgehen den Cache Ihres lokalen Resolvers.

Reicht ein korrekter PTR-Record für gute Zustellbarkeit?

Nein. Ein gültiger PTR mit FCrDNS ist die Basis, für zuverlässige Zustellung braucht es zusätzlich SPF, DKIM und DMARC sowie eine nicht gelistete IP. Die DKIM-Signatur beschreibt die Anleitung OpenDKIM mit Postfix einrichten.

Kann ich mehrere PTR-Records pro IP setzen?

Technisch ist es möglich, aber als Best Practice gilt genau ein PTR pro IP. Mehrere PTR-Einträge liefern bei Reverse-Lookups uneindeutige Ergebnisse und können von empfangenden Mailservern als unsauber bewertet werden.

Fazit

Der PTR-Record ist ein kleiner Eintrag mit großer Wirkung auf die Zustellbarkeit. Entscheidend ist das Zusammenspiel: PTR auf den FQDN, passender A/AAAA-Record zurück auf die IP (FCrDNS) und ein passender HELO-Name, für IPv4 und bei Nutzung auch für IPv6. Darauf bauen SPF, DKIM und DMARC auf.

Weiterführende Anleitungen & Quellen

Zum sicheren Mailbetrieb: Mailserver nativ mit Postfix, Dovecot und Rspamd aufsetzen und der Beitrag zum Exim 4.99.3 GnuTLS-RCE-Patch (CVE-2026-45185). Weitere Anleitungen finden Sie in der Kategorie E-Mail sowie unter Netzwerk.

Quellen: RFC 1912 (Common DNS Operational Errors), RFC 3596 (DNS Extensions for IPv6, ip6.arpa), die Google-Richtlinien für E-Mail-Absender und die Gmail-SMTP-Fehlercodes.