Free Reverse IP Lookup

Two different things get called "reverse IP lookup"

Worth settling before you read a result, because the two answer different questions and only one of them is a DNS query:

The second one cannot be done with DNS at all. An A record maps a name to an address and the mapping only runs in that direction; there is no record type that lists every name pointing at a given IP. Tools that answer it are querying a scraped database, which is why two of them give you different answers for the same address. If what you actually want is the hostnames under a domain rather than under an IP, the subdomain finder reads certificate transparency and will be both faster and more accurate.

What the PTR lookup actually queries

Reverse DNS is ordinary DNS with the address rewritten as a name. For IPv4 the octets are reversed and suffixed with in-addr.arpa, so 8.8.8.8 becomes a lookup for 8.8.8.8.in-addr.arpa. For IPv6 every single nibble is reversed and suffixed with ip6.arpa, which is why an IPv6 reverse query name is 32 labels long and unreadable by eye.

The zone that answers it is delegated to whoever owns the address block, not to whoever owns the domain. That is the fact behind most confusion about PTR records: you can point any name you like at an IP with an A record, but only the IP's owner can make the IP point back.

Why your server has no PTR, or has the wrong one

Three cases cover almost everything:

• No PTR at all. Common on residential connections and cheaper VPS ranges. The provider never delegated or populated the reverse zone.
• A generic provider PTR. Cloud instances usually ship with something like ec2-203-0-113-10.compute-1.amazonaws.com. It resolves, it just says "this is a cloud VM" rather than anything about your service.
• A stale PTR. The reverse zone still names a host that has since moved. Because reverse records are edited far less often than forward ones, they rot quietly.

Changing it is a request to the provider, not a DNS edit you make. Most clouds gate it behind a form or a support ticket on the specific elastic address, and some will only grant it once the forward record already resolves to that IP.

Forward-confirmed reverse DNS, the one place PTR is load-bearing

If you send email, this is the reason to care. FCrDNS is a two-step check the receiving mail server runs on the connecting IP:

1. Look up the PTR for the connecting IP to get a hostname.
2. Resolve that hostname's A or AAAA record and check it comes back to the same IP.

Both halves have to agree. A PTR pointing at a hostname that does not resolve back is worse than no PTR at all for reputation purposes, because it reads as misconfiguration. Google's sender guidelines require sending IPs to have valid forward and reverse DNS, and large receivers routinely defer or reject connections that fail it outright.

Debugging is mechanical:

Where this fits if you run a multi-tenant app

A common wrong turn: teams shipping custom domains sometimes try to set a PTR per customer domain. There is nothing to set. The PTR belongs to the sending IP, and one IP has one hostname regardless of how many tenants send through it. Tying a customer's domain to your infrastructure is SPF and DKIM's job, not reverse DNS's.

Domainee is a custom domains API for SaaS with a native MCP server, 50 domains and 100 GB free. The web and mail sides are separate problems, and this is the web one.

From the command line

Keyless, no signup, no API key:

curl -s "https://api.domainee.dev/v1/tools/reverse-ip-lookup?ip=8.8.8.8" | jq

Returns hostnames as an array, because more than one PTR per address is legal even though it is rare and generally a bad idea. Private and reserved ranges are rejected. Rate limits are per IP and there is no uptime commitment, so use it for scripts and audits rather than as a production dependency.