PTR-Record im DNS verständlich erklärt: Reverse-IP-Auflösung

Der PTR-Record (kurz für Pointer Record) ist das direkte Gegenstück zum A-Record. Während ein A-Record einen Namen in eine IP-Adresse übersetzt (Vorwärtsauflösung), macht der PTR-Record das Gegenteil: Er löst eine IP-Adresse in einen Hostnamen auf (Rückwärtsauflösung oder Reverse DNS). Dieses Verfahren ist vor allem für den sicheren Betrieb von E-Mail-Servern von elementarer Bedeutung.

Während die meisten DNS-Einträge in der normalen, vorwärts gerichteten Zone Ihrer Domain liegen, wird der PTR-Record in einer eigenen Reverse-Zone unter in-addr.arpa (IPv4) bzw. ip6.arpa (IPv6) verwaltet. Diese Zone gehört nicht Ihnen, sondern dem Betreiber des IP-Adressblocks – ein entscheidender Unterschied, der in der Praxis für viel Verwirrung sorgt.

Die Syntax und die reverse IP-Notation

PTR-Records werden in speziellen, rückwärts gerichteten DNS-Zonen verwaltet. Die IP-Adressen werden dabei in umgekehrter Reihenfolge notiert und mit einer speziellen Endung versehen:

IPv4-Beispiel:

Für die IP-Adresse 192.0.2.10 lautet der entsprechende PTR-Eintrag:

10.2.0.192.in-addr.arpa.      86400    IN    PTR    mail.example.com.

• 10.2.0.192: Die IP-Adresse in umgekehrter Byte-Reihenfolge.
• in-addr.arpa.: Die standardisierte Root-Zone für das IPv4-Reverse-Mapping.
• mail.example.com.: Der Hostname, auf den die IP-Adresse verweist.

IPv6-Beispiel:

Bei IPv6 wird die Adresse in ihre einzelnen Halbbytes (Nibles) zerlegt, ebenfalls umgedreht und unter der Endung .ip6.arpa. abgefragt. Dies führt zu sehr langen Einträgen mit vielen Punkten.

---

PTR-Record im Vergleich zum A-Record

A-Record und PTR-Record bilden ein Paar, das in entgegengesetzte Richtungen zeigt. Die folgende Tabelle stellt die wichtigsten Unterschiede gegenüber:

Eigenschaft	A-Record	PTR-Record
Richtung	Name → IP (Forward)	IP → Name (Reverse)
Zone	normale Domain-Zone	in-addr.arpa / ip6.arpa
Verwaltet von	Domain-Inhaber	IP-Block-Betreiber (ISP/Hoster)
Typischer Zweck	Website, Dienste erreichbar machen	Mailserver-Reputation, Logging
Pflicht für Mailserver	ja	ja (sonst Spam-Einstufung)

Für einen vertrauenswürdigen Mailserver müssen beide Richtungen konsistent sein: Der A-Record mail.example.com → 192.0.2.10 und der PTR-Record 192.0.2.10 → mail.example.com müssen exakt aufeinander zeigen. Genau diese Übereinstimmung prüft die unten beschriebene FCrDNS-Kontrolle.

---

Warum Mailserver einen passenden PTR-Record fordern

Das primäre Einsatzgebiet von PTR-Records ist der Spam-Schutz. Wenn ein Mailserver eine E-Mail versendet, sieht der Empfänger-Mailserver (z. B. Google Mail oder Microsoft Outlook) zunächst nur die IP-Adresse des Absenders.

Um Spam-Netzwerke auszuschliessen, führt der Empfänger eine Prüfung namens FCrDNS (Forward-Confirmed Reverse DNS) durch:

               1. Senden der Mail von IP [192.0.2.10]
             ┌─────────────────────────────────────┐
             │                                     │
             ▼                                     │
     [Sender-Server]                         [Empfänger]
             ▲                                     │
             │ 3. A-Record Check                   │ 2. PTR-Record Check
             │    mail.example.com?                │    192.0.2.10?
             │    -> [192.0.2.10] (Match!)         │    -> mail.example.com
             └─────────────────────────────────────┴──────────────────┘

1. Reverse DNS Query: Der Empfänger fragt den PTR-Record der Sender-IP 192.0.2.10 ab. Der Nameserver liefert mail.example.com zurück.
2. Forward DNS Query: Der Empfänger fragt den A-Record des Hostnamens mail.example.com ab. Der Nameserver liefert 192.0.2.10 zurück.
3. Der Abgleich: Da die IP-Adresse aus Schritt 1 mit der IP aus Schritt 2 übereinstimmt, gilt das System als legitim. Besitzt der Sender-Server keinen PTR-Record oder zeigt dieser auf einen generischen Namen des Providers (z. B. dsl-10-2-0-192.provider.com), stuft der Empfänger die E-Mail mit hoher Wahrscheinlichkeit als Spam ein oder verweigert die Annahme komplett.

---

Typische PTR-Fehler und ihre Folgen

Probleme mit PTR-Records äussern sich fast immer in Form von Zustellproblemen bei E-Mails. Diese Tabelle zeigt die häufigsten Ursachen:

Fehler	Symptom	Lösung
Kein PTR-Record	Mails landen im Spam oder werden abgewiesen	PTR beim Hoster/ISP setzen lassen
Generischer Provider-Hostname	niedrige Reputation, Greylisting	PTR auf eigenen Mail-Hostnamen ändern
PTR ≠ HELO/EHLO-Name	FCrDNS schlägt fehl	PTR, A-Record und HELO angleichen
Fehlender A-Record für PTR-Ziel	Forward-Check scheitert	A-/AAAA-Record für den Hostnamen anlegen
Falsche Reverse-Notation	PTR wird nicht gefunden	IP in korrekter in-addr.arpa-Schreibweise notieren

Gerade die Diskrepanz zwischen PTR-Name und dem im SMTP-Dialog gesendeten HELO-Namen ist eine häufig übersehene Fehlerquelle. Sie hängt eng mit der SPF-Konfiguration zusammen, die ebenfalls die Absender-Identität absichert.

---

Praxisbeispiel: Eigener Mailserver auf einem VPS

Ein Unternehmen betreibt einen eigenen Mailserver auf einem gemieteten Server (VPS) mit der IP 192.0.2.10:

• Vorher (ohne PTR): Der Hoster hat die IP mit dem generischen PTR static.192.0.2.10.provider.net vorbelegt. Gmail und Outlook stufen ausgehende Mails als verdächtig ein – ein Teil landet im Spam, einige werden komplett abgewiesen. Der A-Record mail.example.com zeigt zwar korrekt auf die IP, doch die Rückrichtung passt nicht.
• Nachher (mit korrektem PTR): Im Server-Panel des Hosters wird der PTR auf mail.example.com gesetzt. Nun stimmen Forward- und Reverse-Auflösung überein, der HELO-Name lautet ebenfalls mail.example.com, und SPF, DKIM sowie DMARC sind sauber konfiguriert. Die FCrDNS-Prüfung ist erfolgreich, die Reputation steigt und die Mails werden zuverlässig zugestellt.

Die Lehre: Der PTR-Record ist kein optionales Detail, sondern Teil eines Vertrauensverbunds aus A-Record, HELO-Name und E-Mail-Authentifizierung. Erst das Zusammenspiel aller Bausteine ergibt einen vertrauenswürdigen Mailserver.

[!IMPORTANT] Ohne einen gültigen PTR-Record ist der Betrieb eines eigenen Mailservers im B2B-Umfeld unmöglich. Prüfen Sie die Mailserver-Konfiguration und die DNS-Verlässlichkeit Ihrer IP-Adresse mit der Mail Deliverability Suite auf balou.tools.