Reverse DNS: PTR-Record beim Hoster richtig setzen

Beim ersten eigenen Mailserver ist das hier der Schritt, bei dem viele hängen bleiben. Alle Einträge in der eigenen Zone stimmen, SPF und DKIM sind sauber, und trotzdem lehnt Gmail jede Mail ab. Die Fehlermeldung erwähnt dann meist „PTR“ oder „reverse DNS“, und der Eintrag dafür ist an einer Stelle, an der man ihn nicht vermutet.

Was ein Reverse-DNS-PTR-Record ist

Normales DNS übersetzt Namen in IPs. Reverse DNS geht den umgekehrten Weg: Zu einer IP liefert es einen Namen. Dafür gibt es eigene Zonen, in-addr.arpa für IPv4 und ip6.arpa für IPv6, in denen die IP rückwärts geschrieben steht:

Unter diesem Namen steht ein PTR-Record mit dem Hostnamen:

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

dig -x nimmt dir das Umdrehen ab:

dig -x 192.0.2.25 +short
dig -x 2001:db8:10::25 +short

Wo du den PTR-Record setzt

Nicht beim Registrar deiner Domain. Die Reverse-Zone gehört dem Inhaber des IP-Netzes, und das ist bei einem VServer dein Hoster. Die meisten Anbieter haben im Kundenpanel bei der IP-Adresse ein Feld „Reverse DNS“ oder „rDNS“. Dort trägst du mail.example.com ein.

Manche Panels prüfen vor dem Speichern, ob der Name per A- oder AAAA-Record auf genau diese IP zeigt, und lehnen sonst ab. Darum zuerst den Forward-Eintrag setzen. Den A-Record für mail legst du bei deinem DNS-Anbieter an, bei betadomain im Kundenbereich der Domain. Erst danach den PTR beim Hoster.

Gibt es im Panel kein Feld dafür, frag den Support. Bei Anbietern, die IPs nur über NAT vergeben, ist ein eigener PTR oft gar nicht möglich, und für einen Mailserver ist so ein Server dann ungeeignet.

Bei IPv6 musst du meist jede Adresse einzeln eintragen, weil du ein ganzes /64 bekommst. Trag genau die Adresse ein, von der Postfix sendet.

Forward-Confirmed Reverse DNS

Ein PTR allein reicht vielen Empfängern nicht. Geprüft wird die Runde hin und zurück, Forward-Confirmed Reverse DNS (FCrDNS):

1. IP des einliefernden Servers per PTR in einen Namen auflösen.
2. Diesen Namen per A oder AAAA wieder auflösen.
3. Kommt die ursprüngliche IP heraus, passt es.

IP=192.0.2.25
NAME=$(dig -x "$IP" +short)
echo "$NAME"
dig "$NAME" A +short

mail.example.com.
192.0.2.25

Zeigt der A-Record auf eine andere IP, oder ist der PTR noch der generische Name des Hosters (static.25.2.0.192.clients.hoster.example), gilt die Prüfung als nicht bestanden. Google nennt einen gültigen PTR mit passendem Forward-Eintrag in seinen Richtlinien für Absender ausdrücklich als Anforderung, bei IPv6 wird das streng durchgesetzt.

PTR, HELO und myhostname zusammenbringen

Drei Stellen sollten denselben Namen tragen:

postconf myhostname smtp_helo_name

smtp_helo_name übernimmt standardmäßig $myhostname. Der Name muss nicht zur Absenderdomain passen. Ein Server mail.example.com kann problemlos Mails für beispiel.de verschicken, solange SPF und DKIM für beispiel.de stimmen. Wichtig ist nur, dass PTR, A-Record und HELO untereinander konsistent sind. Wie die übrigen Mail-Einträge aussehen, steht unter MX-Record einrichten.

IPv6: der häufigste Stolperstein

Hat mail.example.com einen AAAA-Record und Postfix inet_protocols = all, stellt Postfix an Gmail bevorzugt über IPv6 zu. Fehlt für die IPv6-Adresse der PTR, kommt eine Ablehnung wie diese zurück:

550-5.7.25 [2001:db8:10::25] The IP address sending this message does not have a
550-5.7.25 PTR record setup, or the corresponding forward DNS entry does not
550 5.7.25 point to the sending IP.

Zwei Auswege: PTR für die IPv6-Adresse setzen, oder Postfix vorübergehend auf IPv4 beschränken:

postconf -e 'inet_protocols = ipv4'
systemctl restart postfix

Die bessere Lösung ist der PTR. Hintergründe zum AAAA-Eintrag stehen im Artikel zum AAAA-Record.

Generische Namen und Spamfilter

Lässt du den Standard-PTR des Hosters stehen, ist die Prüfung formal oft sogar bestanden: Der generische Name löst meist wieder auf die IP auf. Trotzdem schneiden solche Server schlechter ab. Spamfilter werten Hostnamen aus, die die IP-Adresse in Ziffern enthalten oder Wörter wie dynamic, dsl oder pool, als Hinweis auf einen Endkundenanschluss. SpamAssassin hat dafür eigene Regeln wie RDNS_DYNAMIC, und für fehlenden Reverse-DNS RDNS_NONE.

Ein eigener, sprechender Name wie mail.example.com vermeidet das. Betreibst du auf einem Server Mail für mehrere Domains, reicht trotzdem ein einziger PTR. Die IP hat einen Namen, und der muss nicht zu jeder Absenderdomain passen.

Wie lange ein neuer PTR braucht

Reverse-Zonen haben oft hohe TTLs, manchmal 86400 Sekunden. Der alte, generische Eintrag des Hosters kann deshalb bei Empfängern noch einen Tag lang gecacht sein. Prüfe direkt beim zuständigen Nameserver:

dig -x 192.0.2.25 +trace | tail -n 4

Liefert der autoritative Server schon den neuen Namen, bleibt nur Warten. Das Prinzip ist dasselbe wie bei jeder anderen Änderung, beschrieben unter DNS-Propagation.

Wann ein PTR egal ist

Für Webserver, SSH und APIs ist Reverse DNS ohne Bedeutung. Let’s Encrypt fragt keinen PTR ab, Browser auch nicht. In SSH ist UseDNS auf aktuellen Debian- und Ubuntu-Systemen standardmäßig aus, der Login wartet also nicht mehr auf Reverse-Lookups. Den Aufwand brauchst du nur, wenn der Server Mail verschickt, auch wenn das nur Systemmeldungen oder Formular-Mails einer Website sind.

Nächster Schritt

Setz den A-Record für mail, dann den PTR beim Hoster, und prüf die Runde mit dig -x. Planst du eine eigene Domain nur für den Mailserver, kannst du Domains bei betadomain vergleichen und den Namen direkt in der Suche eingeben. Eine .net-Domain kostet 16,99 € im Jahr, auch bei der Verlängerung.

Schritt für Schritt

1. Mail-Hostnamen festlegenEinen festen Namen wie mail.example.com wählen, der auch in Postfix als myhostname eingetragen ist.
2. A- und AAAA-Record setzenmail.example.com in der eigenen DNS-Zone auf die IPv4- und gegebenenfalls IPv6-Adresse des Servers zeigen lassen.
3. PTR im Hoster-Panel eintragenIm Panel des VServer-Anbieters beim Reverse-DNS der IP den Namen mail.example.com eintragen, für IPv6 die konkrete Adresse aus dem Netz.
4. Forward-Confirmed rDNS prüfenMit dig -x IP +short den Namen abfragen und mit dig Name A +short prüfen, dass wieder dieselbe IP herauskommt.