Reverse-DNS (rDNS/PTR) für IPv4 und IPv6 im netcup SCP setzen

Soll Ihr Server E-Mails versenden, ist ein korrekt gesetzter Reverse-DNS-Eintrag (PTR-Record) Pflicht. Ohne ihn lehnen Gmail, GMX, web.de und viele andere Mailprovider Verbindungen ab oder sortieren die Mails in den Spam-Ordner. Mit PTR erscheint der Server auch in Logs, Netzwerkdiagnosen und Sicherheitsscans unter einem lesbaren Hostnamen. Diese Anleitung zeigt, wo Sie den Eintrag im netcup SCP (Server Control Panel) setzen, wie Sie ihn prüfen und worauf Sie bei IPv6 achten.

Voraussetzungen

1. Aktiver netcup-Account mit einem laufenden vServer oder Root-Server
2. Zugangsdaten für das SCP unter servercontrolpanel.de (nicht das CCP – dort lässt sich kein PTR setzen)
3. Vollqualifizierter Domainname (FQDN) für den PTR, z. B. mail.example.com
4. Vorhandener A-Record (IPv4) und/oder AAAA-Record (IPv6) für diesen Hostnamen, der bereits auf die jeweilige IP zeigt
5. Bei IPv6: Kenntnis der konkreten IPv6-Adresse aus dem zugewiesenen /64-Subnetz, die Ihr Server tatsächlich verwendet (z. B. per ip -6 addr show ermitteln)
6. Für Failover-IPs: Die zusätzliche IP muss im SCP dem Server bereits zugewiesen sein, bevor der PTR gesetzt werden kann

Was ist Reverse-DNS und warum ist es wichtig?

Normale DNS-Abfragen lösen einen Hostnamen in eine IP-Adresse auf – ein A-Record oder AAAA-Record liefert z. B. zu mail.example.com die IP 185.x.x.x. Reverse-DNS dreht diesen Prozess um: Ein PTR-Record (Pointer Record) ordnet einer IP-Adresse einen Hostnamen zu. Die zuständigen Reverse-DNS-Zonen heißen in-addr.arpa für IPv4 und ip6.arpa für IPv6 – sie werden nicht vom Domain-Inhaber, sondern vom IP-Inhaber verwaltet, in diesem Fall also von netcup.

RFC 5321, der SMTP-Standard, erlaubt empfangenden Servern, den EHLO-Namen gegen die IP-Adresse zu prüfen, verbietet aber eine Ablehnung allein aus diesem Grund. Große Mailprovider setzen strengere eigene Regeln. Fehlt der PTR oder stimmt er nicht mit dem HELO/EHLO-Namen überein, landet die E-Mail im Spam oder wird mit einem 5xy Bad DNS PTR resource record-Fehler abgelehnt.

Seit 2024 verlangt Google von allen Absendern an Gmail-Konten gültige Forward- und Reverse-DNS-Einträge, zusätzlich SPF oder DKIM; DMARC ist Pflicht ab 5.000 Mails pro Tag. Wer einen eigenen Mailserver mit Mailcow oder einem anderen MTA betreibt, muss den PTR-Record also von Anfang an richtig setzen.

Schritt 1: PTR-Record für IPv4 im SCP setzen

Das SCP ist die einzige Stelle, an der Sie PTR-Records für netcup-IPs konfigurieren können. Das CCP bietet diese Funktion nicht.

1. Melden Sie sich unter servercontrolpanel.de an.
2. Wählen Sie links den gewünschten Server aus der Liste aus.
3. Klicken Sie auf den Tab Network (Netzwerk).
4. Im Abschnitt IPv4 Addresses sehen Sie Ihre IPv4-Adressen.
5. Unter der jeweiligen IP-Adresse finden Sie das Textfeld Reverse DNS.
6. Tragen Sie den gewünschten FQDN ein, z. B. mail.example.com. Wichtig: Kein führender oder abschließender Punkt, keine IP-Adresse, kein Wildcard.
7. Klicken Sie auf Save (rechts neben dem Feld).
8. Zum Löschen eines bestehenden Eintrags nutzen Sie Delete.

Prüfen Sie den Eintrag nach einigen Minuten über die Kommandozeile oder ein Online-Tool:

# Linux / macOS – Reverse-Lookup mit dig:
dig -x 185.x.x.x +short
# Erwartete Ausgabe: mail.example.com.

# Alternativ mit host:
host 185.x.x.x
# Erwartete Ausgabe: x.x.x.185.in-addr.arpa domain name pointer mail.example.com.
# Windows PowerShell:
Resolve-DnsName -Name 185.x.x.x -Type PTR
# Erwartete Ausgabe: NameHost = mail.example.com

Liefert die Abfrage noch den alten Wert oder keinen Eintrag, ist die TTL von 7200 Sekunden noch nicht abgelaufen. Für einen Soforttest fragen Sie einen anderen Resolver ab (dig -x 185.x.x.x @8.8.8.8 +short) oder nutzen das MXToolbox SuperTool.

Verifizieren: dig -x auf Ihre IPv4-Adresse liefert genau Ihren FQDN mit abschließendem Punkt, z. B. mail.example.com.

Schritt 2: PTR-Record für IPv6 im SCP setzen

Jeder netcup-Server erhält ein vollständiges /64-Subnetz, das über 1,8 × 10¹⁹ IPv6-Adressen umfasst. Im SCP können Sie für jede einzelne, explizit eingetragene IPv6-Adresse aus diesem Subnetz einen separaten PTR-Record vergeben. Wildcard-PTR oder die vollständige Delegation des /64-Subnetzes an einen eigenen Nameserver sind im Standard-SCP nicht vorgesehen.

1. Öffnen Sie im SCP den Tab Network Ihres Servers.
2. Gehen Sie zum Abschnitt IPv6 Addresses.
3. Wählen Sie die gewünschte IPv6-Adresse aus dem /64-Subnetz – sie muss bereits als konkrete Adresse eingetragen sein, z. B. 2a03:4000:xx:yy::1.
4. Füllen Sie das Feld Reverse DNS mit dem FQDN aus, z. B. mail.example.com.
5. Klicken Sie auf Save.

Prüfen Sie den Eintrag:

# IPv6 PTR prüfen:
dig -x 2a03:4000:xx:yy::1 +short
# Erwartete Ausgabe: mail.example.com.

host 2a03:4000:xx:yy::1
# Windows PowerShell:
Resolve-DnsName -Name 2a03:4000:xx:yy::1 -Type PTR

Setzen Sie den PTR für die IPv6-Adresse, die Ihr Server beim Versenden tatsächlich als Quelladresse nutzt. Prüfen Sie das auf dem Server:

# Welche IPv6-Adressen hat der Server?
ip -6 addr show
# Die „sendende" Adresse beim Mailversand ermitteln:
curl -s -6 https://api6.ipify.org

Verifizieren: dig -x auf die sendende IPv6-Adresse liefert Ihren FQDN, und diese Adresse stimmt mit der Ausgabe von curl -s -6 https://api6.ipify.org überein.

Schritt 3: Forward-Confirmed rDNS (FCrDNS) sicherstellen

Ein PTR-Record allein reicht nicht – er muss den Test der Forward-Confirmed Reverse DNS (FCrDNS) bestehen. Das bedeutet: Der Hostname im PTR muss per A-Record (IPv4) bzw. AAAA-Record (IPv6) wieder auf exakt dieselbe IP-Adresse zeigen. Nur dann gilt die Validierung bei empfangenden Mailservern als bestanden.

# Schritt 1: Reverse-Lookup (IP → Hostname)
dig -x 185.x.x.x +short
# Ergebnis z. B.: mail.example.com.

# Schritt 2: Forward-Lookup (Hostname → IP)
dig mail.example.com A +short
# Muss exakt dieselbe IP zurückgeben: 185.x.x.x

# IPv6 – analoges Vorgehen:
dig -x 2a03:4000:xx:yy::1 +short
# Ergebnis z. B.: mail.example.com.
dig mail.example.com AAAA +short
# Muss exakt dieselbe IPv6-Adresse zurückgeben

Stimmen PTR und Forward-Lookup überein, ist FCrDNS erfüllt. Weichen sie ab – z. B. weil der A-Record noch auf eine alte IP zeigt oder überhaupt nicht existiert – werten viele Mailserver Ihren PTR als ungültig.

A- und AAAA-Records der eigenen Domain verwalten Sie nicht im SCP, sondern im netcup CCP (Customer Control Panel) oder beim DNS-Anbieter Ihrer Domain, siehe DNS-Records bei netcup im CCP verwalten.

Verifizieren: Für IPv4 und IPv6 liefert der Reverse-Lookup Ihren FQDN, und der Forward-Lookup dieses FQDN liefert exakt dieselbe IP-Adresse.

Übersicht: PTR-Konfiguration bei netcup im Vergleich

Mailserver-Anforderungen an den PTR-Record

Für den kompletten Mailserver-Stack hilft die Anleitung Reverse DNS (PTR) und IPv6 für Mailserver korrekt einrichten beim Gesamtbild. Den DKIM-Part deckt OpenDKIM mit Postfix einrichten ab.

Troubleshooting / Typische Fehler

PTR gesetzt, aber FCrDNS schlägt fehl

Der häufigste Fehler: Der Hostname im PTR-Record existiert nicht als A- bzw. AAAA-Record oder zeigt auf eine andere IP. Prüfen Sie beide Richtungen mit dig -x IP +short und dig HOSTNAME A +short. Erst wenn beide denselben Wert liefern, ist FCrDNS erfüllt. Den A/AAAA-Record setzen Sie in der DNS-Verwaltung Ihrer Domain, nicht im SCP.

Fehler „5xy Bad DNS PTR resource record“ von web.de oder GMX

Der PTR-Record fehlt oder besteht den FCrDNS-Test nicht. Setzen Sie im SCP einen korrekten PTR und stellen Sie sicher, dass der Hostname per A/AAAA-Record auf dieselbe IP zeigt. Nach dem Setzen 7200 Sekunden warten und erneut testen.

IPv6-Adresse im PTR stimmt nicht mit der sendenden Adresse überein

Bei einem /64-Subnetz kann Ihr Server mehrere IPv6-Adressen nutzen. Prüfen Sie mit ip -6 addr show oder curl -s -6 https://api6.ipify.org, welche Adresse der Server beim ausgehenden Mailversand tatsächlich verwendet, und setzen Sie den PTR genau für diese Adresse.

TTL-Verzögerung: Test schlägt direkt nach Änderung fehl

netcup setzt eine TTL von 7200 Sekunden, Resolver liefern bis dahin eventuell den alten Wert. Nutzen Sie für Soforttests externe DNS-Resolver (8.8.8.8, 1.1.1.1) oder das MXToolbox SuperTool, das kein lokales Caching hat.

Generischer PTR statt FQDN

Einträge wie 85-12-34-56.static.example.com (IP im Hostnamen) gelten bei Spamfiltern als verdächtig. Verwenden Sie einen sprechenden Hostnamen wie mail.example.com oder smtp.example.com.

IPv6-PTR vergessen

Viele Admins konfigurieren nur IPv4. Versendet der Mailserver über IPv6, lehnt Gmail ohne IPv6-PTR mit 550-5.7.1 … IPv6 sending guidelines regarding PTR records ab. Setzen Sie daher immer beide PTR-Records oder deaktivieren Sie den IPv6-Versand im MTA.

Mehrere PTR-Records für eine IP

Technisch sind mehrere PTR-Records möglich, aber Mailserver prüfen in der Regel nur den ersten. Verwenden Sie pro IP nur einen PTR-Record.

PTR-Record veraltet nach Domain-Umzug

Wenn die Domain im PTR ihre A/AAAA-Records ändert oder die Domain umzieht, schlägt FCrDNS fehl. Nach jedem DNS-Umbau die PTR-Konsistenz neu prüfen.

Häufige Fragen

Wo genau im netcup SCP setze ich den PTR-Record?

Im SCP (servercontrolpanel.de): Server auswählen → Tab „Network“ → Abschnitt „IPv4 Addresses“ oder „IPv6 Addresses“ → Feld „Reverse DNS“ ausfüllen → „Save“ klicken. Das ist die einzige Stelle; im CCP (customercontrolpanel.de) lässt sich der PTR nicht setzen.

Welchen Wert trage ich im Feld „Reverse DNS“ ein?

Den vollqualifizierten Domainnamen (FQDN) des Servers bzw. Mailservers, z. B. mail.example.com. Dieser muss per A-Record (IPv4) bzw. AAAA-Record (IPv6) wieder auf dieselbe IP zeigen (FCrDNS). Keine IP-Adresse, kein Platzhalter, kein abschließender Punkt.

Kann ich bei IPv6 alle Adressen des /64-Subnetzes auf einmal mit einem PTR versehen?

Nein, siehe Schritt 2: nur je einzelner, explizit eingetragener IPv6-Adresse. Wildcard-PTR oder Delegation des /64-Subnetzes sieht das Standard-SCP nicht vor.

Wie lange dauert es, bis der PTR-Record wirksam ist?

Bis zu zwei Stunden (TTL 7200 Sekunden). Für Soforttests den lokalen DNS-Cache leeren oder einen externen DNS-Resolver wie das MXToolbox SuperTool verwenden.

Reicht ein korrekter PTR-Record für zuverlässige E-Mail-Zustellung?

Nein. PTR ist Pflichtvoraussetzung, ersetzt aber nicht SPF, DKIM und DMARC. Google verlangt seit 2024 von allen Absendern PTR sowie SPF oder DKIM, von Absendern ab 5.000 Mails pro Tag zusätzlich SPF, DKIM und DMARC.

Was ist, wenn ich nur eine Domain bei netcup habe, aber keinen Server?

Dann können Sie keinen PTR setzen. PTR-Records erfordern die Kontrolle über den IP-Adressblock, und die liegt beim Serverinhaber, nicht beim Domain-Inhaber.

Kann ich auch Failover-IPs mit einem PTR versehen?

Ja. Failover-IPs und zusätzliche IPv4-Adressen können ebenfalls PTR-Records erhalten. Sie müssen aber zuerst im SCP dem Server zugewiesen sein, bevor das Feld „Reverse DNS“ dafür erscheint (Helpcenter: Abschnitt „IP Management“ im Tab „Network“).

Fazit

Der Reverse-DNS-Eintrag im netcup SCP ist in wenigen Minuten gesetzt. Für den Mailserver zählt, dass der PTR den FCrDNS-Test besteht und zum HELO/EHLO-Namen passt, für IPv4 und IPv6. Prüfen Sie nach dem Setzen mit dig -x und rechnen Sie mit bis zu zwei Stunden TTL.

Weiterführende Anleitungen und Quellen

1. Das netcup Server Control Panel (SCP) erklärt: Alle Funktionen im Überblick
2. DNS-Records bei netcup im CCP verwalten: A, AAAA, CNAME, MX und TXT richtig setzen
3. Reverse DNS (PTR) und IPv6 für Mailserver korrekt einrichten – Zustellbarkeit sichern
4. OpenDKIM mit Postfix einrichten: DKIM-Signatur korrekt konfigurieren
5. Mailcow komplett aufsetzen – eigener Mailserver mit Docker
6. DNS-Records erklärt: A, AAAA, CNAME, MX und TXT
7. netcup Helpcenter: Network Server (offizielle Dokumentation)
8. netcup Helpcenter: Adding IP Addresses (offizielle Dokumentation)
9. RFC 5321 – Simple Mail Transfer Protocol (IETF)
10. MXToolbox SuperTool – Reverse DNS Lookup und Mail-Diagnose