Reverse DNS Lookup: What PTR Records Are and How to Check Yours

The short answer

A reverse DNS lookup takes an IP address and returns the hostname assigned to it — the opposite of the normal lookup that turns example.com into an IP. It works by querying a PTR record, and the fastest way to run one is dig -x 8.8.8.8 on macOS or Linux, or nslookup 8.8.8.8 on Windows.

The reason anyone cares is email. Nearly every large mail provider checks that the IP connecting to it has a PTR record, and rejects or heavily penalises mail from IPs that don't. A missing PTR is one of the few deliverability problems that produces an outright refusal rather than a slow slide into the spam folder.

Forward and reverse are two separate databases

This is the part that trips people up. A forward lookup — name to IP — is answered by the nameservers for your domain, which you control through your registrar or DNS host. A reverse lookup is answered by the nameservers for a completely different zone, one derived from the IP address itself, and those are controlled by whoever owns the IP block.

Reverse DNS for IPv4 lives under the special domain in-addr.arpa, with the four octets written backwards. A lookup on 8.8.4.4 is really a PTR query for 4.4.8.8.in-addr.arpa. The reversal exists because DNS delegates from right to left, while IP addresses get more specific from left to right — flipping them lets a registry hand 8.8.8.in-addr.arpa to the organisation that holds that block. IPv6 uses ip6.arpa and the same idea taken further: every hex digit of the fully expanded address becomes its own label, in reverse, which is why an IPv6 PTR name is 32 labels long.

The practical consequence: you cannot set your own PTR record at your DNS host. Adding a PTR to your domain's zone file does nothing at all. The record has to be created by the entity that controls the IP — your hosting provider, cloud platform, or ISP.

Why mail servers insist on it

Receiving mail servers run a check called forward-confirmed reverse DNS, and it has three steps: look up the PTR for the connecting IP, take the hostname that comes back, then look that hostname up forward again and confirm it resolves to the same IP. Only a round trip that closes counts as a pass.

The logic is simple — anyone can claim any hostname in a mail greeting, but only the IP's actual owner can publish its PTR. A matching pair proves whoever runs the mail server also legitimately controls the address it's sending from. Consumer broadband IPs almost always have generic PTRs like 203-0-113-45.dsl.example-isp.net, and many receivers reject mail from those patterns on sight, which is why sending mail from a home connection rarely works regardless of how well SPF, DKIM and DMARC are configured.

Reading the output

dig -x 8.8.8.8 +short returns dns.google. — one line, trailing dot included, because that is the fully qualified name. Drop +short and you get the full response, where the ANSWER SECTION shows the query rewritten as 8.8.8.8.in-addr.arpa. 86399 IN PTR dns.google. That middle number is the remaining TTL in seconds.

An empty answer with status NXDOMAIN means no PTR exists for that IP. A status of SERVFAIL usually means the reverse zone is delegated to nameservers that aren't answering — a provider-side problem, not yours. And an answer that returns a hostname which thendoesn't resolve forward to the same IP is worse than nothing: it looks like a misconfiguration or a spoof attempt to the receiving server.

How to get a PTR record set

What reverse DNS is not useful for

Two common misreadings are worth naming. First, a PTR record tells you nothing about who is browsing your site — a visitor's IP usually resolves to their ISP's generic pool name, which identifies the network, not a person or a company. Reverse lookups on visitor traffic are a poor identification method and a worse analytics one.

Second, reverse DNS is not shared hosting discovery. Finding every domain hosted on one IP is a reverse IP lookup, which searches a crawled database of forward records. It sounds similar and returns completely different data — an IP has one PTR record no matter how many hundreds of sites it serves. Reverse DNS also has no effect on search rankings; Google's crawler does use it to verify its own bots, but nothing about your PTR feeds into how your pages rank. If you are auditing a domain's wider technical footprint, the site health checks that do move rankings sit somewhere else entirely.

Check the forward side of the record

CheckSEO's DNS Lookup resolves a hostname's A, AAAA, MX, NS and TXT records in one query — the check to run right after your provider sets a PTR, to confirm the hostname it returns really does point back to the same address.