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

Wenn du einen eigenen Mailserver betreibst, ist ein korrekter Reverse DNS PTR Record Pflicht – ohne ihn landen deine E-Mails bei großen Anbietern wie Google, Microsoft oder GMX oft im Spam oder werden komplett abgewiesen. In dieser Anleitung zeigen wir dir Schritt für Schritt, wie du den Reverse DNS PTR Record für deinen Mailserver einrichten kannst – sowohl für IPv4 als auch für IPv6 – und wie du mit sauberem FCrDNS (Forward-Confirmed Reverse DNS) deine Mail-Zustellbarkeit absicherst. Die Anleitung richtet sich an Admins, Selfhoster und alle, die einen Mailserver auf einem Root-Server, VPS oder Homeserver mit fester IP betreiben.

Kurzfassung: Der PTR-Record muss auf deinen FQDN (z. B. mail.example.com) zeigen, und der zugehörige A- bzw. AAAA-Record muss zurück auf dieselbe IP auflösen (FCrDNS). Den PTR setzt du nicht in deiner normalen DNS-Zone, sondern in der Reverse-Zone beim IP-Owner – also meist im Hoster-Panel. Verifizieren tust du mit dig -x IP oder nslookup IP.

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

Beim normalen (Forward-)DNS fragst du: „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. Viele große Provider weisen Mails von IPs ohne gültigen PTR sogar direkt mit einem 550 5.7.1-Fehler ab.

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, dir 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 du die Reverse-DNS-Zone der IP bearbeiten kannst (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.

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

Bevor du den PTR setzt, brauchst du einen sauberen Forward-Eintrag, auf den der PTR später zeigt. Wähle einen dedizierten Hostnamen für den Mailserver, klassischerweise mail.example.com.

1. Lege in deiner DNS-Zone einen A-Record für die IPv4-Adresse an.
2. Lege – falls du IPv6 nutzt – zusätzlich einen AAAA-Record für die IPv6-Adresse an.
3. Stelle sicher, dass dieser FQDN auch als HELO/EHLO-Name deines Mailservers genutzt wird.

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 gibst du stattdessen einfach Typ, Name und Wert ein – etwa Typ A, Name mail, Wert 203.0.113.25.

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

Der PTR-Record wird nicht in deiner normalen Domain-Zone gesetzt, sondern in der Reverse-Zone der IP – und die kontrolliert der IP-Owner, also dein Hoster. Bei den meisten Anbietern findest du dafür im Panel ein Feld „Reverse DNS", „rDNS" oder „PTR".

1. Öffne im Hoster-Panel die Verwaltung deiner IP-Adresse (Server- oder IP-Übersicht).
2. Suche die Option Reverse DNS / PTR für die betreffende IPv4-Adresse.
3. Trage als Wert deinen 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. Die Änderung wird beim IP-Owner in die Zone in-addr.arpa geschrieben.

Falls dein Provider dir eine eigene Reverse-Zone delegiert hat und du sie selbst per BIND verwaltest, sieht der Eintrag so aus:

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

Best Practice: Setze pro IP genau einen PTR-Record. Mehrere PTR-Einträge auf einer IP führen zu unzuverlässigen Ergebnissen und können von Empfängern als unsauber bewertet werden.

Schritt 3: PTR-Record für IPv6 einrichten

Wenn dein Mailserver auch über IPv6 sendet, brauchst du zwingend ebenfalls einen PTR für die IPv6-Adresse. Viele Provider (allen voran Google) prüfen IPv6 sogar strenger als IPv4 und verlangen einen gültigen PTR plus passenden AAAA-Record.

1. Wichtig: Konfiguriere deinen Mailserver so, dass er für ausgehende Verbindungen genau die eine IPv6-Adresse nutzt, für die du einen AAAA- und PTR-Eintrag pflegst. Bei einem /64-Block solltest du nicht zufällige Adressen verwenden.
2. Öffne im Hoster-Panel den Reverse-DNS-Eintrag für die gewählte IPv6-Adresse.
3. Trage als Wert wieder denselben FQDN ein: mail.example.com.
4. Speichern. Der Eintrag landet in der Zone ip6.arpa.

Bei einem Postfix-Server stellst du die feste Quell-IPv6 z. B. so ein, 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 du PTR und AAAA gepflegt hast – die Basis für sauberes FCrDNS über IPv6.

Schritt 4: FCrDNS herstellen – Forward und Reverse abgleichen

Jetzt schließt du den Kreis. 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)

Prüfe, dass Vorwärts- und Rückwärtsauflösung exakt dieselben IPs ergeben. Tippfehler (etwa .24 statt .25) brechen das FCrDNS und damit die Zustellbarkeit. Achte außerdem darauf, dass dein Mailserver im SMTP-Dialog genau diesen FQDN als HELO/EHLO meldet – sonst passen Banner, PTR und Forward nicht zusammen.

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üfst du den PTR mit Standard-Tools.

Verifikation unter Linux mit dig

Die Reverse-Auflösung (PTR) testest du 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:" sollte bei der IP-Abfrage dein FQDN erscheinen. 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 dein Server sich mit dem richtigen Namen meldet:

openssl s_client -connect mail.example.com:25 -starttls smtp -quiet

Im Banner (220 mail.example.com ESMTP) sollte derselbe FQDN stehen wie im PTR.

Updates & Wartung

Reverse DNS ist keine „einmal einrichten und vergessen"-Sache. Achte langfristig auf folgende Punkte:

1. IP-Wechsel: Wenn du den Server umziehst oder eine neue IP bekommst, musst du A/AAAA und die PTR-Records neu setzen. Plane den Umzug so, dass alte und neue IP kurzzeitig beide sauber aufgelöst werden.
2. FQDN-Änderung: Benennst du den Mailhost um, passe Forward-Record, PTR und den HELO-/myhostname-Wert gemeinsam an.
3. Monitoring: Überwache PTR und Blacklist-Status regelmäßig – etwa über MXToolbox-Monitoring oder ein eigenes Skript mit dig -x, das bei Abweichung alarmiert.
4. Mailserver-Patches: Halte deinen 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, der zeigt, wie wichtig zeitnahe Updates für den MTA sind.

Backup-Hinweis

Sichere deine DNS-Konfiguration regelmäßig. Exportiere deine Forward-Zone (Zonefile bzw. Panel-Export) und dokumentiere die gesetzten PTR-Werte pro IP in einer Textdatei oder einem Passwort-/Konfig-Tresor. Reverse-Zonen lassen sich bei vielen Hostern nicht als Datei exportieren – deshalb ist die manuelle Dokumentation hier besonders wichtig, damit du nach einem Hoster-Wechsel sofort weißt, welcher PTR auf welche 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üfe im Hoster-Panel, ob gespeichert wurde, und warte die TTL ab.
2. PTR zeigt auf Hoster-Default (z. B. static.xxx.provider.net): Du hast den eigenen PTR noch nicht gesetzt oder bei der falschen IP. Trage deinen FQDN im rDNS-Feld der korrekten IP ein.
3. FCrDNS schlägt fehl: PTR und Forward zeigen auf unterschiedliche IPs. Vergleiche dig -x IP mit dig A/AAAA FQDN und korrigiere den abweichenden Eintrag.
4. Mails von IPv6 werden abgewiesen, von IPv4 nicht: Es fehlt der IPv6-PTR oder AAAA. Setze beide oder binde ausgehend testweise auf IPv4 (smtp_bind_address), bis der IPv6-PTR steht.
5. Google/Microsoft lehnen weiter ab (550 5.7.1): 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: Setze 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 immer der IP-Owner, also dein Hoster bzw. Provider. In deiner eigenen Domain-Zone kannst du nur die Forward-Records (A, AAAA, MX) pflegen. Den PTR findest du im Server- oder IP-Panel deines Hosters unter „Reverse DNS" oder „rDNS".

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

Ja. Sobald dein Mailserver über IPv6 versendet, verlangen große Provider wie Google einen gültigen PTR und einen passenden AAAA-Record für die sendende IPv6-Adresse. Fehlt der IPv6-PTR, werden Mails häufig abgewiesen – auch wenn dein 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 kannst du gezielt einen externen Resolver befragen, um Caching-Effekte deines lokalen Resolvers zu umgehen.

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

Nein. Ein gültiger PTR mit FCrDNS ist die Basis, aber für zuverlässige Zustellung brauchst du zusätzlich SPF, DKIM und DMARC sowie eine saubere, nicht gelistete IP. PTR ist eine notwendige Voraussetzung, kein Allheilmittel.

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

Einen Reverse DNS PTR Record für deinen Mailserver einrichten ist einer der wirkungsvollsten und gleichzeitig einfachsten Schritte für gute Zustellbarkeit. Wichtig ist das Zusammenspiel: PTR auf den FQDN, passender A/AAAA-Record zurück auf die IP (FCrDNS), und ein HELO-Name, der dazu passt – für IPv4 und, falls genutzt, zwingend auch für IPv6. Setzt du pro IP einen sauberen PTR und verifizierst das Ergebnis mit dig -x oder nslookup, hast du eine solide Grundlage geschaffen, auf der SPF, DKIM und DMARC dann aufbauen.

Weiterführende Anleitungen & Quellen

Mehr zum Thema sicherer Mailbetrieb findest du in unserem Beitrag zum Exim 4.99.3 GnuTLS-RCE-Patch (CVE-2026-45185). Weitere Tutorials rund um Selfhosting und Server findest du in der Kategorie E-Mail sowie unter Netzwerk.

Quellen: RFC 1912 (Common DNS Operational Errors), RFC 3596 (DNS Extensions for IPv6, ip6.arpa) und die Google Workspace Guidelines für E-Mail-Sender.