PTR-Record (Reverse DNS) für den Mailserver prüfen, setzen

$ dig +short -x 192.0.2.25
mail.beispiel.at.
$ dig +short A mail.beispiel.at
192.0.2.25

Zwei Abfragen, und beide müssen zusammenpassen. Die erste fragt: Welcher Name gehört zur IP-Adresse 192.0.2.25? Die Antwort steht im PTR-Record. Die zweite fragt umgekehrt: Auf welche Adresse zeigt dieser Name? Kommt dieselbe Adresse heraus, ist der Rückwärts-Eintrag „vorwärts bestätigt“, Forward-confirmed reverse DNS oder kurz FCrDNS. Genau das verlangt Gmail von jedem Server, der Mails einliefert. Adresse und Domain hier sind Beispiele.

Den PTR setzt, wem die IP-Adresse gehört, nicht wem die Domain gehört. Die Rückwärtszone für 192.0.2.25 heißt 25.2.0.192.in-addr.arpa und liegt beim Netzbetreiber der Adresse. Ein PTR-Eintrag in der eigenen Zone beispiel.at hat keine Wirkung, egal was die Oberfläche des Domain-Anbieters anbietet.

Wer sich darum kümmern muss#

Nur wer selbst einen Server betreibt, der Mails direkt an fremde Mailserver übergibt. Das sind:

• ein eigener Mailserver auf einem gemieteten Server oder VPS,
• ein Webserver, der Formular- oder Shop-Mails direkt verschickt statt über das Postfach beim Hoster,
• ein Exchange-Server im eigenen Haus oder eine Firewall mit eigenem Mailversand,
• ein Gerät mit fester IP-Adresse, das Berichte per Mail schickt.

Wer Postfächer bei Microsoft 365, Google Workspace oder einem Webhoster nutzt und darüber sendet, braucht nichts zu tun. Die Ausgangsserver gehören dem Anbieter, und der pflegt die Einträge. Wer nicht weiß, welche Server für die eigene Domain senden, sieht es in den DMARC-Berichten, beschrieben in DMARC-Report lesen.

Wichtig ist die Absender-Adresse. Der Eingangsserver aus dem MX-Eintrag ist oft ein anderer Rechner. Bei kleinen Installationen ist es derselbe, aber verlassen sollte man sich darauf nicht. Welche Adresse eine Mail tatsächlich eingeliefert hat, steht in der obersten Received-Zeile beim Empfänger, siehe E-Mail-Header lesen.

Was die großen Empfänger verlangen#

Google schreibt in den Regeln für Absender an Gmail-Konten, gültig seit 01.02.2024 für alle Absender, nicht nur für Massenversender: Die öffentliche IP-Adresse des sendenden Servers muss einen PTR-Record haben, der auf einen Hostnamen zeigt. Derselbe Hostname muss einen A-Eintrag für IPv4 oder einen AAAA-Eintrag für IPv6 haben, der auf dieselbe Adresse zeigt.

Fehlt das, antwortet Gmail mit einem dieser beiden Codes:

Microsoft verwendet den PTR in der zusammengefassten Prüfung compauth, die im Header jeder Mail an Microsoft 365 steht. Mehrere Begründungscodes beziehen sich darauf, etwa wenn der PTR der einliefernden Adresse zur Domain im From: passt oder der MX der Absenderdomain zum PTR. Ein passender PTR hilft dort also auch Mails, deren SPF oder DKIM schwach ist.

Die Regel ist alt. RFC 1912 von 1996 schreibt schon: „Make sure your PTR and A records match.“ Für jede IP-Adresse soll es einen passenden PTR geben, und er soll auf einen echten Namen zeigen, nicht auf einen Alias per CNAME.

Prüfen#

Unter Linux und macOS mit dig, unter Windows mit nslookup:

dig +short -x 192.0.2.25
dig +short A mail.beispiel.at
dig +short -x 2001:db8::25
dig +short AAAA mail.beispiel.at

nslookup 192.0.2.25
nslookup mail.beispiel.at

Vier Ergebnisse sind möglich:

1. Name kommt, Name zeigt zurück auf die IP. Alles in Ordnung.
2. Keine Antwort auf -x. Es gibt keinen PTR. Gmail lehnt ab.
3. Name kommt, zeigt aber auf eine andere Adresse oder gar nicht. Häufig, wenn ein Server umgezogen ist und der alte Name stehen blieb, oder wenn der PTR auf den Namen der Website zeigt, die längst bei einem anderen Anbieter liegt.
4. Ein Name wie static-192-0-2-25.provider.example. Das ist ein automatisch vergebener Eintrag des Netzbetreibers. Passt er in beide Richtungen, erfüllt er Gmails Regel. Ein Name aus der eigenen Domain sagt im Header aber sofort, wer sendet, und lässt sich zum HELO des Servers passend wählen.

IPv6 nicht vergessen. Hat der Server eine IPv6-Adresse, kann er die Zustellung über IPv6 versuchen. Dann zählt der PTR der IPv6-Adresse, und Gmails Regel gilt für AAAA genauso wie für A.

Ob die Adresse auf einer Sperrliste steht, ist eine andere Frage mit eigenem Werkzeug: Blacklist-Check.

Beim Hoster setzen#

Der Eintrag wird dort gesetzt, wo die IP-Adresse gemietet ist. Bei den meisten Server-Anbietern sitzt das Feld im Kundenbereich direkt neben der IP-Adresse und heißt „Reverse DNS“, „rDNS“ oder „PTR“.

Hetzner Cloud als Beispiel, laut Hetzner-Dokumentation: in der Hetzner Console den Server auswählen, auf „Networking“ gehen, rechts neben der IP-Adresse den rDNS-Eintrag bearbeiten. Hetzner definiert einen gültigen Eintrag ausdrücklich als einen, der in beide Richtungen auflöst. Für IPv6 wird nur der hintere Teil der Adresse eingetragen, der Netzanteil ist schon hinterlegt. Hetzner rät, dabei auf die zwei Doppelpunkte zu achten.

Bei einem Internetanschluss mit fester IP-Adresse liegt die Rückwärtszone beim Provider. Ändern kann sie nur er, meist auf Anfrage über den Geschäftskunden-Support.

Die Reihenfolge ist immer dieselbe:

1. Namen wählen, etwa mail.beispiel.at.
2. In der eigenen Zone einen A-Eintrag (und für IPv6 einen AAAA-Eintrag) für diesen Namen auf die Server-IP setzen.
3. Erst dann beim Hoster den PTR auf mail.beispiel.at setzen. So stimmt die Vorwärtsrichtung schon, wenn der PTR gilt.
4. Mit den Befehlen oben prüfen, nach Ablauf der TTL.

Typische Fehler#

Der PTR steht in der eigenen DNS-Zone. Manche Oberflächen von Domain-Anbietern bieten den Typ PTR an. In der Zone beispiel.at ist er wirkungslos, gefragt wird die Zone unter in-addr.arpa.

Der Name hat keinen A-Eintrag. Der PTR zeigt auf mail.beispiel.at, aber den Namen gibt es in der Zone nicht. Dann ist die Rückwärtsrichtung da, die Vorwärtsrichtung nicht, und Gmail lehnt trotzdem ab.

Der Name zeigt auf eine andere Adresse. Nach einem Serverumzug hat der neue Server die neue Adresse, der Name aber noch die alte. Oder der PTR zeigt auf www.beispiel.at, und die Website liegt woanders.

Ein Punkt fehlt. In einer Zonendatei muss ein vollständiger Name mit Punkt enden. Fehlt er, hängt die Software die Zone an, und aus mail.beispiel.at wird mail.beispiel.at.25.2.0.192.in-addr.arpa. In der Messung unten kommt genau das vor.

ptr im SPF-Eintrag. Der Mechanismus ptr im SPF-Eintrag ist etwas anderes als der PTR-Record und soll laut RFC 7208 nicht mehr verwendet werden. Wie man SPF stattdessen aufbaut, steht in SPF-Eintrag erstellen.

Messung: die Absender-Adressen Tiroler Domains#

In eigener Sache: Am 05.10.2026 habe ich für dieselben 149 Tiroler Domains wie in meinen bisherigen Messungen, 34 Tourismusverbände und 115 Betriebe aus meiner Akquise-Liste, nachgesehen, welche Absender-Adressen sie selbst nennen, nämlich als einzelne ip4:- oder ip6:-Adressen im SPF-Eintrag. Für jede Adresse habe ich den PTR abgefragt und den Namen vorwärts zurückverfolgt. include: habe ich nicht verfolgt, dahinter stehen die Netze großer Anbieter, die ihre Einträge selbst pflegen. Alles passiv per DNS-over-HTTPS bei Cloudflare, ohne Verbindung zu einem Mailserver. Drei Domains gibt es nicht mehr, bleiben 146.

• 57 Domains nennen zusammen 156 einzelne Absender-Adressen.
• 106 Adressen haben einen PTR, der in beide Richtungen passt. 16 davon mit einem automatisch vergebenen Namen des Netzbetreibers.
• 20 Adressen haben einen PTR, dessen Name nicht auf die Adresse zurückzeigt. Darunter Namen von Websites, Namen wie mail.<domain>, die vorwärts auf eine andere oder gar keine Adresse zeigen, und ein Name, der auf .in-addr.arpa endet, der fehlende Punkt aus dem Abschnitt oben.
• 30 Adressen haben gar keinen PTR.
• 25 der 57 Domains nennen mindestens eine Adresse, die Gmails Regel nicht erfüllt.

Was diese Zählung nicht zeigt: ob über diese Adressen heute noch Mails gehen. Eine Adresse im SPF-Eintrag kann ein Überbleibsel sein, ein alter Server oder ein Gerät, das längst über das Postfach beim Anbieter versendet. Dann ist der fehlende PTR harmlos, aber der Eintrag selbst überflüssig, und er erlaubt einer Adresse, die vielleicht inzwischen jemand anderem gehört, im Namen der Domain zu senden.

Zum Vergleich: Die 681 Adressen der Eingangsserver aus den MX-Einträgen derselben Domains haben bis auf eine alle einen PTR. Bei den Adressen, die Betriebe selbst als Absender eintragen, fehlt er bei fast jeder fünften, und bei knapp jeder dritten passt er nicht in beide Richtungen. Namen veröffentliche ich nicht.

Was nicht hilft#

Den PTR in der eigenen Zone anlegen. Siehe oben, die Rückwärtszone gehört dem Netzbetreiber.

Nur den PTR setzen und den A-Eintrag vergessen. Gmail verlangt beide Richtungen.

Den Mailserver im HELO einen anderen Namen sagen lassen, um den PTR zu umgehen. Gmails Regel prüft die IP-Adresse, nicht den HELO.

Auf den Rückläufer warten. Ein 421 4.7.0 ist vorübergehend, der eigene Server versucht es weiter, und die Mail hängt tagelang in der Warteschlange. Was das für den Empfänger heißt, steht in E-Mail kommt nicht an.

Häufige Fragen#

Wenn du es nicht selbst machen willst#

In eigener Sache: cyberscale bin ich, Stefan Haun aus Tirol. Der Sicherheits-Check sieht sich die DNS-Einträge der Domain und der Server von außen an und sortiert, was fehlt, nach Dringlichkeit. Ob SPF, DKIM und DMARC stimmen, zeigt kostenlos der E-Mail-Check, ob die Server-Adresse gesperrt ist, der Blacklist-Check. Wie die Transportverschlüsselung zu den eigenen Eingangsservern abgesichert wird, steht in MTA-STS und TLS-RPT.

Stand 05.10.2026. Quellen an diesem Tag abgerufen, DNS-Messung am 05.10.2026.