Reverse-DNS und PTR-Eintrag: vom Namen zur IP und zurück

Normalerweise fragst du im DNS nach einem Namen und bekommst eine IP-Adresse: www.beispiel.de führt über einen A-Eintrag zu einer IPv4-Adresse. Reverse-DNS geht den umgekehrten Weg. Ausgangspunkt ist eine IP-Adresse, gesucht ist der Hostname, der zu ihr gehört. Die Antwort liefert ein PTR-Eintrag, wobei PTR für Pointer steht. Für Webseiten spielt das kaum eine Rolle. Für Mailserver ist es Pflicht: Gmail verlangt von allen Absendern einen passenden PTR-Eintrag für die sendende IP-Adresse ^[4].

Wie die Rückwärtsauflösung technisch funktioniert

Damit eine IP-Adresse im DNS nachgeschlagen werden kann, wird sie in einen Namen unter der besonderen Domain in-addr.arpa umgewandelt. Die vier Zahlenblöcke einer IPv4-Adresse stehen dabei in umgekehrter Reihenfolge. RFC 1035 nennt als Beispiel die Adresse 10.2.0.52, deren Daten unter 52.0.2.10.in-addr.arpa liegen ^[1]. Die Umkehrung wirkt umständlich, hat aber einen Zweck: So lassen sich Zonen genau entlang der Netzgrenzen vergeben, und ein Netzbetreiber bekommt die Zone für seinen Adressbereich ^[1].

Für IPv6 gibt es die Domain ip6.arpa. Dort wird die Adresse in einzelne Hexadezimalziffern zerlegt, wieder in umgekehrter Reihenfolge und durch Punkte getrennt ^[2]. Aus einer IPv6-Adresse wird so ein Name mit 32 Ziffern vor ip6.arpa.

Beispiel: ein Mailserver mit IPv4 und IPv6

Ein Mailserver, der über beide Protokolle Mails verschickt, braucht vier zusammenpassende Einträge: zwei Adresseinträge in der Zone deiner Domain und zwei PTR-Einträge in den Reverse-Zonen des Hosters. Die IPv6-Adresse im Beispiel ist die aus RFC 3596, dort steht auch der zugehörige Name unter ip6.arpa ^[2]. Die IPv4-Adresse stammt aus dem Beispiel in RFC 1035 ^[1].

An der IPv6-Zeile sieht man, warum niemand diese Namen von Hand tippt. Die Verwaltungsoberflächen der Hoster nehmen die normale Adresse entgegen und bauen den Namen unter ip6.arpa selbst. Wichtig ist nur, dass alle vier Einträge auf denselben Hostnamen hinauslaufen. Fehlt einer, scheitert die Prüfung in beide Richtungen für das betroffene Protokoll, und Mails, die der Server über diesen Weg verschickt, fallen bei strengen Empfängern durch.

Wer den PTR-Eintrag setzen darf

Hier liegt der wichtigste Unterschied zu allen anderen DNS-Einträgen: Der PTR-Eintrag steht in der Reverse-Zone des Adressbereichs und damit außerhalb der Zone deiner Domain. Diese verwaltet in der Regel der Inhaber der IP-Adresse, also dein Hoster oder Internetanbieter ^[3]. Du kannst den Eintrag deshalb nicht in der DNS-Verwaltung deiner Domain anlegen, auch wenn dort ein Eintragstyp PTR auswählbar ist.

Bei Servern mit eigener IP-Adresse bieten die meisten Anbieter ein Feld in der Verwaltungsoberfläche an. Bei Hetzner zum Beispiel ersetzt du in der Console unter "Networking" den Standardwert durch deinen eigenen Hostnamen. Für viele Einträge gibt es dort auch eine Programmierschnittstelle ^[3]. Bei einfachem Webhosting, bei dem sich viele Kunden eine IP-Adresse teilen, hast du dagegen meist keinen Einfluss auf den PTR-Eintrag.

Warum Mailserver Reverse-DNS brauchen

Empfangende Mailserver prüfen bei jeder eingehenden Verbindung, von welcher IP-Adresse sie kommt. Viele Mailserver nehmen eingehende Mails nur an, wenn die IP-Adresse des Absenders einen gültigen Reverse-DNS-Eintrag hat ^[3]. Google schreibt deshalb in seinen Richtlinien für Absender an Gmail für alle Absender vor, dass die sendenden IP-Adressen gültige Vorwärts- und Rückwärtseinträge haben ^[4]. Im Einzelnen gilt:

• Die öffentliche IP-Adresse des sendenden SMTP-Servers muss einen PTR-Eintrag haben ^[4].
• Der Hostname aus dem PTR-Eintrag muss einen A-Eintrag (IPv4) oder AAAA-Eintrag (IPv6) haben ^[4].
• Die sendende IP-Adresse muss mit der IP-Adresse dieses Hostnamens übereinstimmen ^[4].

Diese Prüfung in beide Richtungen heißt Forward-confirmed reverse DNS, kurz FCrDNS. Hetzner beschreibt sie als Abgleich, ob PTR- und A-Eintrag zusammenpassen ^[3]. Die Vorgabe steht bei Google unter den Anforderungen für alle Absender. Wer mehr als 5.000 Nachrichten am Tag an Gmail-Konten schickt, muss seit dem 01.02.2024 zusätzlich strengere Regeln erfüllen, darunter DMARC und bei Werbe- und Abonnementmails eine Abmeldung mit einem Klick ^[4]. Wie Reverse-DNS mit SPF, DKIM und DMARC zusammenspielt, erklärt Eigene E-Mails landen im Spam.

Hetzner empfiehlt außerdem, dass der Name, mit dem sich der Mailserver beim Verbindungsaufbau meldet (HELO oder EHLO), mit dem PTR-Eintrag übereinstimmt. Ein automatisch erzeugter Name des Hosters ist als PTR-Eintrag ungeeignet ^[3].

Reverse-DNS einrichten in vier Schritten

1. Einen Hostnamen für den Mailserver festlegen, etwa mail.beispiel.de, und in der Zone der Domain einen A-Eintrag (und bei IPv6 einen AAAA-Eintrag) auf die IP-Adresse des Servers setzen.
2. In der Verwaltung des Hosters den PTR-Eintrag der IP-Adresse auf genau diesen Hostnamen setzen. Bei IPv6 gilt das für jede Adresse, von der aus der Server Mails verschickt.
3. Den Mailserver so einstellen, dass er sich mit demselben Namen meldet. Bei Postfix steht der Name in der Einstellung myhostname, die er standardmäßig auch im HELO- oder EHLO-Befehl verwendet ^[7].
4. Prüfen: Die Rückwärtsabfrage der IP-Adresse muss mail.beispiel.de liefern, und die Vorwärtsabfrage von mail.beispiel.de muss wieder dieselbe IP-Adresse liefern. Den A-Eintrag kannst du mit dem DNS-Check abfragen.

Der Tipp folgt einer Empfehlung von Hetzner, wo je IP-Adresse nur ein PTR-Eintrag möglich ist ^[3]. Technisch erlaubt das DNS durchaus mehrere PTR-Einträge für eine Adresse. RFC 2181 stellt klar, dass es keine Beschränkung auf einen gibt ^[5]. In der Praxis setzen die meisten Anbieter aber nur einen.

Eine Besonderheit gibt es bei kleinen Adressblöcken. Weil die Reverse-Zonen entlang der Zahlenblöcke der Adresse geschnitten sind ^[1], lässt sich ein Block von wenigen Adressen nicht ohne Weiteres als eigene Zone abgeben. Manche Netzbetreiber setzen deshalb in ihrer Zone Verweise per CNAME, die auf eine Zone beim Kunden zeigen (klassenlose Delegation nach RFC 2317) ^[8]. RFC 2181 erlaubt ausdrücklich, dass beim Nachschlagen eines PTR-Eintrags unterwegs ein CNAME liegt. Nur der Wert des PTR-Eintrags selbst, also der Hostname am Ende, darf kein Alias sein ^[5].

Regeln für einen sauberen PTR-Eintrag

Einige Regeln stammen direkt aus den Standards. RFC 1912, eine Sammlung typischer DNS-Fehler von 1996, hält schon im ersten Abschnitt fest, dass jeder aus dem Internet erreichbare Rechner einen Namen haben sollte. Viele Dienste verweigern sonst die Zusammenarbeit ^[6]. Das Dokument verlangt außerdem, dass PTR- und A-Einträge zusammenpassen. Hat ein Server mehrere IP-Adressen, braucht jede davon einen PTR-Eintrag, nicht nur die erste. Und der PTR-Eintrag muss auf einen Namen mit echtem A-Eintrag zeigen, nicht auf einen Alias, der per CNAME definiert ist ^[6]. Auch RFC 2181 sagt, dass der Wert eines PTR-Eintrags kein Alias sein darf ^[5].

• Der Hostname im PTR-Eintrag ist ein vollständiger Name, der wirklich auflöst.
• Er zeigt auf einen Namen mit A- oder AAAA-Eintrag, nicht auf einen CNAME.
• Jede IP-Adresse, von der aus Mails verschickt werden, hat einen eigenen PTR-Eintrag, auch IPv6-Adressen.
• Der Name ist erkennbar dein eigener und kein generischer Name aus dem Adressbereich des Hosters.

Wann du Reverse-DNS nicht selbst brauchst

Einen reinen Webserver, der keine Mails verschickt, betrifft das alles kaum. Besucher rufen die Website über den Namen auf, den Rückweg prüft dabei niemand.

Verschickst du Mails über einen Dienst wie Google Workspace, Microsoft 365 oder einen Versanddienst für Newsletter, verlassen die Mails das Netz über die IP-Adressen dieses Anbieters. Für deren PTR-Einträge sorgt der Anbieter selbst. Du kümmerst dich in diesem Fall um SPF, DKIM und DMARC für deine Domain, siehe SPF, DKIM und DMARC im Zusammenspiel, und um den richtigen MX-Eintrag.

Schwierig wird es, wenn du von einem Shared-Hosting-Server aus Mails verschickst. Dann teilst du dir die IP-Adresse und ihren PTR-Eintrag mit anderen Kunden. Passt der Name nicht oder hat ein Nachbar die Adresse durch Spam in Verruf gebracht, kannst du daran nichts ändern. Ein Versand über den Mailserver des Hosters oder einen eigenen Dienst mit sauberem PTR-Eintrag ist dann die bessere Wahl. Wie Spam auf Empfängerseite aussieht und was dagegen hilft, steht auf Spam-Mails: woher sie kommen und was dagegen hilft.

1. Gesetz RFC 1035: Domain Names, Implementation and Specification, Abschnitt 3.5. IETF. Stand November 1987. abgerufen am 29.10.2026
2. Gesetz RFC 3596: DNS Extensions to Support IP Version 6, Abschnitt 2.5. IETF. Stand Oktober 2003. abgerufen am 29.10.2026
3. Organisation Architektur, Abschnitt reverse DNS (rDNS). Hetzner Online. Stand ohne Datum. abgerufen am 29.10.2026
4. Organisation Richtlinien für E-Mail-Absender. Google (Gmail-Hilfe). Stand ohne Datum. abgerufen am 29.10.2026
5. Gesetz RFC 2181: Clarifications to the DNS Specification, Abschnitt 10.2. IETF. Stand Juli 1997. abgerufen am 29.10.2026
6. Gesetz RFC 1912: Common DNS Operational and Configuration Errors, Abschnitt 2.1. IETF. Stand Februar 1996. abgerufen am 29.10.2026
7. Organisation Postfix Configuration Parameters (postconf.5), myhostname und smtp_helo_name. Postfix. Stand ohne Datum. abgerufen am 29.10.2026
8. Gesetz RFC 2317: Classless IN-ADDR.ARPA delegation. IETF. Stand März 1998. abgerufen am 29.10.2026

Zuletzt geprüft am 29.10.2026, nächste Prüfung spätestens im Oktober 2027. Fehler entdeckt? Schreib uns.