rDNS-Check

Ein A-Record ordnet einen Hostnamen einer IP-Adresse zu. Ein PTR-Record macht das Gegenteil: Er ordnet eine IP-Adresse einem Hostnamen zu und liegt in der in-addr.arpa (IPv4)- oder ip6.arpa (IPv6)-DNS-Zone. Die beiden Records sind voneinander unabhängig. Ein PTR-Record kann auf einen beliebigen Hostnamen zeigen, und dieser Hostname muss keinen A-Record haben, der auf dieselbe IP zurückzeigt, obwohl Forward-Confirmed Reverse DNS diese Übereinstimmung erfordert.

PTR-Records werden von demjenigen verwaltet, der den IP-Adressblock kontrolliert, also in der Regel dein Internetanbieter oder Hosting-Anbieter. Anders als A- oder MX-Records kannst du einen PTR-Record nicht über deinen Domain-Registrar oder DNS-Host setzen. Du musst den Anbieter kontaktieren, der die IP vergeben hat, und einen benutzerdefinierten Reverse-DNS-Eintrag anfordern. Die meisten verwalteten Hosting-Anbieter bieten dafür ein Self-Service-Feld in ihrem Control Panel an.

Viele IP-Adressen haben überhaupt keinen PTR-Record. Cloud-Anbieter, private Internetanbieter und Shared-Hosting-Umgebungen überspringen die Reverse-DNS-Konfiguration häufig, es sei denn, sie wird ausdrücklich angefordert. Das Fehlen eines PTR-Records ist kein Fehler im DNS-System selbst. Es bedeutet lediglich, dass der IP-Inhaber keinen veröffentlicht hat. Bei Mailservern ist dieser fehlende Record ein Problem, da empfangende Server ihn oft als grundlegende Spam-Prüfung verlangen.

FCrDNS bedeutet, dass der PTR-Hostname einer IP beim Forward-DNS-Lookup auf genau diese IP zurückzeigt. Wenn zum Beispiel 203.0.113.5 einen PTR-Record hat, der auf mail.example.com zeigt, und eine DNS-Abfrage für mail.example.com den Wert 203.0.113.5 zurückgibt, ist die Konfiguration forward-confirmed. Viele Mailserver und Spam-Filter behandeln FCrDNS als Vertrauenssignal. Ein PTR-Record, der nicht forward-auflöst oder auf eine andere IP zeigt, besteht diese Prüfung nicht und kann die E-Mail-Zustellbarkeit beeinträchtigen.

Ein normaler DNS-Lookup nimmt einen Domainnamen und gibt seine IP-Adresse zurück, indem er A- oder AAAA-Records abfragt. Ein Reverse-DNS-Lookup nimmt eine IP-Adresse und gibt einen Hostnamen zurück, indem er PTR-Records in den in-addr.arpa - oder ip6.arpa -Zonen abfragt. Die beiden Lookups sind voneinander unabhängig und verwenden völlig getrennte DNS-Zonen. Ein gültiger A-Record erstellt nicht automatisch einen PTR-Record und umgekehrt.

Ja. Bei IPv6 erweitert das Tool die Adresse auf ihre vollständige 32-Nibble-Form, kehrt die Nibbles um und hängt .ip6.arpa an, um die Reverse-Lookup-Domain zu konstruieren. Das ist der in RFC 3596 definierte Standardmechanismus. IPv6-PTR-Records werden noch seltener konfiguriert als IPv4-Records, daher ist ein fehlendes Ergebnis bei einer IPv6-Adresse in vielen Fällen zu erwarten.

Technisch gesehen ja, DNS erlaubt mehrere PTR-Records für eine einzelne IP. In der Praxis ist das jedoch selten und kann bei Mailservern, die genau einen PTR-Record erwarten, zu Problemen führen. Einige Spam-Filter behandeln mehrere PTR-Records als Fehlkonfiguration. Wenn das Tool mehr als einen Hostnamen für deine IP zurückgibt, überprüfe deine Reverse-DNS-Einstellungen mit deinem Hosting-Anbieter und konsolidiere sie auf einen einzigen, korrekten Record.

Reverse DNS ist eine Ebene der E-Mail-Authentifizierung. Ein gültiger PTR-Record ist eine grundlegende Voraussetzung für viele empfangende Mailserver. Für eine vollständige Zustellbarkeits-Prüfung solltest du außerdem deine DKIM-Signatur mit dem DKIM-Checker prüfen und bestätigen, dass deine DMARC-Richtlinie korrekt veröffentlicht ist. Jede dieser Prüfungen deckt einen anderen Teil der E-Mail-Authentifizierungskette ab. PTR deckt die Absender-IP ab; DKIM und DMARC decken die Domain-Identität ab.

Pingie speichert die von dir zur Abfrage eingegebenen IP-Adressen nicht über das hinaus, was zur Verarbeitung der Anfrage erforderlich ist. Vollständige Details zur Datenverarbeitung findest du in der Datenschutzerklärung . Der Lookup selbst fragt die öffentliche DNS-Infrastruktur ab, sodass die PTR-Anfrage wie jede normale DNS-Anfrage durch DNS-Resolver geleitet wird.

PTR-Records propagieren sich entsprechend ihrem TTL-Wert (Time to Live), genau wie jeder andere DNS-Record. Die meisten Anbieter setzen TTLs zwischen 300 und 3600 Sekunden. Nachdem dein Hosting-Anbieter den Record aktualisiert hat, cachen Resolver weltweit den alten Wert, bis der TTL abläuft. In der Praxis dauert die vollständige globale Propagierung je nach TTL und Caching-Verhalten des Resolvers zwischen wenigen Minuten und einigen Stunden.

Manchmal ja. Viele große Anbieter konfigurieren PTR-Records, die ihren Markennamen oder Infrastruktur-Bezeichner enthalten, zum Beispiel ec2-54-12-34-56.compute-1.amazonaws.com . Das gibt einen Hinweis auf den IP-Inhaber. Für mehr Details darüber, wer einen IP-Block kontrolliert, verwende das ASN-Lookup Tool, das das autonome System und die registrierte Organisation hinter jeder IP-Adresse ermittelt.

Nein. Ein gültiger PTR-Record ist eine grundlegende Voraussetzung für viele Mailserver, reicht aber allein nicht aus. Empfangende Server bewerten außerdem DKIM-Signaturen, DMARC-Richtlinien, SPF-Übereinstimmung, den Ruf des Absenders und ob die IP auf Sperrlisten steht. Ein korrekter PTR-Record beseitigt einen häufigen Ablehnungsgrund. Er überschreibt jedoch keinen schlechten Absender-Ruf oder eine fehlende DKIM-Signatur.