Reverse-DNS (rDNS/PTR) für IPv4 und IPv6 im netcup SCP setzen
Wer einen Mailserver betreibt, kommt um den PTR-Record nicht herum. Diese Anleitung zeigt, wie du im netcup Server Control Panel für jede IPv4- und IPv6-Adresse den Reverse-DNS-Eintrag setzt – inklusive FCrDNS-Prüfung und den häufigsten Fallstricken.
Wenn dein Server E-Mails versenden soll, ist ein korrekt gesetzter Reverse-DNS-Eintrag (PTR-Record) keine Kür, sondern Pflicht. Ohne ihn lehnen Gmail, GMX, web.de und viele andere Mailprovider eingehende Verbindungen direkt ab oder sortieren sie zuverlässig in den Spam-Ordner. Aber auch abseits des Mailbetriebs sorgt ein sauberer PTR-Record dafür, dass dein Server bei Netzwerkdiagnosen, Logauswertungen und Sicherheitsscans mit einem lesbaren Hostnamen statt einer nackten IP-Adresse auftaucht. Diese Anleitung erklärt, was Reverse-DNS technisch bedeutet, wo du den Eintrag im netcup SCP setzt und worauf du bei IPv6 besonders achten musst.
Voraussetzungen
- Aktiver netcup-Account mit einem laufenden vServer oder Root-Server
- Zugangsdaten für das SCP unter servercontrolpanel.de (nicht das CCP – dort lässt sich kein PTR setzen)
- Vollqualifizierter Domainname (FQDN) für den PTR, z. B.
mail.example.com - Vorhandener A-Record (IPv4) und/oder AAAA-Record (IPv6) für diesen Hostnamen, der bereits auf die jeweilige IP zeigt
- Bei IPv6: Kenntnis der konkreten IPv6-Adresse aus dem zugewiesenen /64-Subnetz, die dein Server tatsächlich verwendet (z. B. per
ip -6 addr showermitteln) - 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.
Für den Mailserver-Betrieb ist der PTR aus einem einfachen Grund unverzichtbar: RFC 5321, der SMTP-Standard, empfiehlt die Überprüfung des PTR-Records bei eingehenden Verbindungen. In der Praxis ist diese „Empfehlung" bei vielen großen Mailprovidern längst zur harten Ablehnung geworden. Fehlt der PTR oder stimmt er nicht mit dem HELO/EHLO-Namen des Mailservers überein, landet die E-Mail im besten Fall im Spam, im schlechtesten Fall erhältst du einen 5xy Bad DNS PTR resource record-Fehler und die Mail wird gar nicht erst angenommen.
Seit 2024 verlangen Google und Yahoo für Bulk-Sender zwingend korrekte DNS-Authentifizierung – PTR-Records sind dabei ein expliziter Bestandteil. 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 du PTR-Records für netcup-IPs konfigurieren kannst. Das Customer Control Panel (CCP) bietet diese Funktion nicht.
- Melde dich unter servercontrolpanel.de an.
- Wähle links den gewünschten Server aus der Liste aus.
- Klicke auf den Tab Network (Netzwerk).
- Suche den Abschnitt IPv4 Addresses. Dort siehst du eine Tabelle mit deinen IPv4-Adressen.
- In der Tabellenzeile deiner IP-Adresse findest du das Textfeld Reverse DNS.
- Trag den gewünschten FQDN ein, z. B.
mail.example.com. Wichtig: Kein führender oder abschließender Punkt, keine IP-Adresse, kein Wildcard. - Klicke den Button Save (rechts neben dem Feld).
- Zum Löschen eines bestehenden Eintrags nutze den Button Delete.
Verifizieren: Warte nach dem Speichern mindestens einige Minuten, dann prüfe den Eintrag ü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.comLiefert die Abfrage noch den alten Wert oder keinen Eintrag, ist die TTL von 7200 Sekunden noch nicht abgelaufen – das ist normal. Für einen Soforttest nutze einen externen DNS-Resolver wie 8.8.8.8 oder das MXToolbox SuperTool.
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 kannst du 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.
- Öffne im SCP den Tab Network deines Servers.
- Suche den Abschnitt IPv6 Addresses.
- Wähle die gewünschte IPv6-Adresse aus dem /64-Subnetz – sie muss bereits als konkrete Adresse eingetragen sein, z. B.
2a03:4000:xx:yy::1. - Fülle das Feld Reverse DNS mit dem FQDN aus, z. B.
mail.example.com. - Klicke Save.
Verifizieren:
# 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 PTRWichtig: Stelle sicher, dass du die PTR-Konfiguration für die IPv6-Adresse vornimmst, die dein Server beim Versenden tatsächlich als Quelladresse nutzt. Prüfe das vorab auf dem Server selbst:
# Welche IPv6-Adressen hat der Server?
ip -6 addr show
# Die „sendende" Adresse beim Mailversand ermitteln:
curl -s -6 https://api6.ipify.orgSchritt 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ückgebenStimmen 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 – wird dein PTR von vielen Mailservern trotzdem als ungültig gewertet.
DNS-Records für die eigene Domain (A, AAAA) verwaltest du nicht im SCP, sondern entweder im netcup CCP oder beim DNS-Anbieter deiner Domain. Eine detaillierte Anleitung dazu findest du unter DNS-Records bei netcup im CCP verwalten.
Übersicht: PTR-Konfiguration bei netcup im Vergleich
| Merkmal | IPv4 | IPv6 (/64-Subnetz) |
|---|---|---|
| Anzahl IPs pro Server | 1 (weitere kostenpflichtig) | 1 Subnetz mit 264 Adressen |
| SCP-Pfad | Network → IPv4 Addresses | Network → IPv6 Addresses |
| Feld | Reverse DNS | Reverse DNS |
| PTR pro Adresse | Ja, individuell | Ja, pro genutzter IPv6-Adresse |
| Speichern | Button „Save" | Button „Save" |
| Löschen | Button „Delete" | Nicht explizit dokumentiert |
| TTL | 7200 Sekunden | 7200 Sekunden |
| Reverse-Zone | in-addr.arpa | ip6.arpa |
| Verwaltung | netcup (nicht delegierbar) | netcup (nicht delegierbar per Standard) |
Mailserver-Anforderungen an den PTR-Record
| Anforderung | Benötigt | Begründung |
|---|---|---|
| PTR-Record vorhanden | Ja | Fehlt er, lehnen viele Provider ab oder stufen als Spam ein |
| FQDN (kein Generic-PTR) | Ja | Generische PTRs wie static.x.x.x.example.com sind ein Spam-Signal |
| A/AAAA matcht PTR (FCrDNS) | Ja | Pflicht für Zustellbarkeit bei Gmail, Yahoo, GMX, web.de |
| PTR = HELO/EHLO-Name | Empfohlen | RFC 5321 Best Practice |
| PTR = Mailserver-Hostname | Empfohlen | Hostname = PTR = MX = HELO, alle vier identisch |
| SPF, DKIM, DMARC | Zusätzlich | PTR ersetzt diese nicht, ergänzt sie aber |
Wenn du einen kompletten Mailserver-Stack aufsetzen möchtest, hilft dir 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üfe 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 setzt du nicht im SCP, sondern in der DNS-Verwaltung deiner Domain.
Fehler „5xy Bad DNS PTR resource record" von web.de oder GMX
Dieser SMTP-Fehlercode bedeutet: Entweder fehlt der PTR-Record vollständig, oder er besteht den FCrDNS-Test nicht. Setze im SCP einen korrekten PTR und stelle 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 dein Server mehrere IPv6-Adressen nutzen. Prüfe mit ip -6 addr show oder curl -s -6 https://api6.ipify.org, welche Adresse der Server beim ausgehenden Mailversand tatsächlich verwendet – und setze den PTR genau für diese Adresse.
TTL-Verzögerung: Test schlägt direkt nach Änderung fehl
PTR-Records bei netcup haben eine TTL von 7200 Sekunden (2 Stunden). Unmittelbar nach dem Speichern können Resolver noch den alten Wert ausliefern. Nutze 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. Verwende einen sprechenden Hostnamen wie mail.example.com oder smtp.example.com.
IPv6-PTR vergessen
Viele Admins konfigurieren nur IPv4 und vergessen IPv6. Moderne Mailserver bevorzugen IPv6 – ein fehlender IPv6-PTR führt dann zu Zustellproblemen bei allen IPv6-fähigen Empfängern. Setze daher immer beide PTR-Records.
Mehrere PTR-Records für eine IP
Technisch sind mehrere PTR-Records möglich, aber Mailserver prüfen in der Regel nur den ersten. Mehrere PTRs können zu unvorhersehbarem Verhalten führen. Verwende 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. Im netcup SCP kannst du für jede einzelne, explizit eingetragene IPv6-Adresse aus dem /64-Subnetz einen eigenen PTR setzen. Wildcard-PTR oder die Delegation des gesamten /64-Subnetzes an einen eigenen Nameserver sind im Standard-SCP nicht vorgesehen.
Wie lange dauert es, bis der PTR-Record wirksam ist?
netcup setzt eine TTL von 7200 Sekunden (2 Stunden). In dieser Zeit können gecachte alte Werte noch ausgeliefert werden. 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. Alle vier zusammen bilden den Mindeststandard für saubere E-Mail-Zustellung – seit 2024 von Google und Yahoo für Bulk-Sender explizit verlangt. Der PTR ist die Grundlage, auf der die anderen Verfahren aufbauen.
Was ist, wenn ich nur eine Domain bei netcup habe, aber keinen Server?
Dann kannst du keinen PTR setzen. PTR-Records erfordern die Kontrolle über den IP-Adressblock – und die liegt beim Serverinhaber, nicht beim Domain-Inhaber. Ohne eigene IP-Adresse ist kein PTR möglich.
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.
Fazit
Den Reverse-DNS-Eintrag im netcup SCP zu setzen ist in wenigen Minuten erledigt – aber er hat große Wirkung. Für den Mailserver-Betrieb ist ein korrekt gesetzter PTR-Record, der den FCrDNS-Test besteht und mit dem HELO/EHLO-Namen übereinstimmt, die wichtigste Einzelmaßnahme für zuverlässige Zustellbarkeit. Vergiss dabei nicht den IPv6-PTR: Wer nur IPv4 absichert, riskiert Zustellprobleme bei allen IPv6-fähigen Empfängern. Nach dem Setzen unbedingt mit dig -x oder dem MXToolbox SuperTool prüfen – und die zwei Stunden TTL einkalkulieren.
Weiterführende Anleitungen und Quellen
- Das netcup Server Control Panel (SCP) erklärt: Alle Funktionen im Überblick
- DNS-Records bei netcup im CCP verwalten: A, AAAA, CNAME, MX und TXT richtig setzen
- Reverse DNS (PTR) und IPv6 für Mailserver korrekt einrichten – Zustellbarkeit sichern
- OpenDKIM mit Postfix einrichten: DKIM-Signatur korrekt konfigurieren
- Mailcow komplett aufsetzen – eigener Mailserver mit Docker
- DNS-Records erklärt: A, AAAA, CNAME, MX und TXT
- netcup Helpcenter: Network Server (offizielle Dokumentation)
- netcup Helpcenter: Adding IP Addresses (offizielle Dokumentation)
- RFC 5321 – Simple Mail Transfer Protocol (IETF)
- MXToolbox SuperTool – Reverse DNS Lookup und Mail-Diagnose
