What this tool does
Reverse DNS answers the opposite question to an ordinary lookup: given an IP address, what hostname does it claim? This tool takes a batch of up to 100 IPv4 or IPv6 addresses, fires a PTR query for each one in parallel, and returns the resulting hostname, the resolution status, and the exact reverse name that was queried. The results table can be copied as CSV or as a tab-separated list of just the addresses that resolved, which is handy when you are annotating a server log or a firewall report.
How reverse DNS works under the hood
DNS is not only used to turn names into addresses — there is a parallel zone tree under in-addr.arpa (IPv4) and ip6.arpa (IPv6) that maps addresses back to names. To look up 8.8.8.8, the resolver issues a PTR query for 8.8.8.8.in-addr.arpa — the octets are reversed because DNS names are read most-specific label first. IPv6 takes this further: the address is expanded to its full 32 hex digits and each nibble becomes its own label, so 2606:4700::1111 becomes 1.1.1.1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.7.4.6.0.6.2.ip6.arpa. The reverse zone for any block is delegated to the party that controls the block, which is why setting a PTR usually means asking your hosting provider, not editing your own domain's zone file.
Reading the results
A green OK row means a PTR was found and we show the hostname it points to. A grey No PTR row means the query returned NXDOMAIN — there is simply no reverse record for that address, which is common for residential, mobile, and many cloud IPs. An Invalid IP badge means the input did not parse as a valid v4 or v6 address; check for stray characters, a port number, or CIDR notation, none of which belong in a bare IP. Anything else is reported with the raw resolver status so you can tell a genuine failure apart from an empty answer.
A subtle but important point: a PTR record is a claim, not proof. Because the reverse zone is controlled by whoever holds the IP, an operator can make an address say almost anything. The trustworthy check is forward confirmation — take the hostname from the PTR, resolve its A/AAAA record, and verify it points back to the original IP. Mail servers do exactly this before accepting connections, which is why a mismatched or missing PTR is a frequent cause of mail being greylisted or rejected.
Common use cases
- Log enrichment — turning a column of raw IPs from access logs or a SIEM into readable hostnames to spot which provider or network a request came from.
- Mail troubleshooting — confirming that a sending IP has a PTR that matches its HELO name, a precondition for good deliverability.
- Network inventory — sweeping a range you operate to see which hosts have reverse records configured and which were missed.
Frequently asked questions
Why does an IP have no PTR record?
PTR records live in the reverse zone, which is delegated to whoever controls the IP block — usually the hosting provider or ISP, not you. Many residential and cloud IPs have no PTR configured, so the lookup returns NXDOMAIN. That is expected behaviour, not an error.
Is reverse DNS the exact inverse of forward DNS?
Not necessarily. Forward (A/AAAA) and reverse (PTR) records are configured independently, often by different parties, so they can disagree. A forward-confirmed pair — where the PTR name resolves back to the original address — is a far stronger signal than a PTR on its own.
Can one IP return more than one hostname?
Yes, the reverse zone can hold several PTR records for a single address, although it is uncommon and discouraged: many clients read only the first answer, and mail and logging systems generally expect one canonical PTR per IP.
JSON API
POST /api/reverse-dns with body { "ips": ["8.8.8.8", "1.1.1.1"] }. It is CORS-enabled, needs no auth, and honours the same 100-IP cap as the form.
Related tools
Pair this with the forward DNS lookup to forward-confirm a PTR, the WHOIS lookup to see who owns the address block, and IPv4-to-IPv6 conversion when you need the expanded v6 form. The how DNS works explainer covers the delegation model in more depth.