Reverse IP Lookup

What this reverse IP lookup does

You type an IP address (IPv4 or IPv6) and the tool returns its reverse DNS name: the hostname stored in the IP’s PTR record. It is the query that answers “what name does this address carry?” when you are reading a log, checking a suspicious connection or diagnosing email delivery.

One thing up front, because “reverse IP lookup” means two different things online:

• Reverse DNS (PTR) — IP in, hostname out. This is what this tool does.
• Reverse IP / “domains on this IP” — IP in, a list of every website hosted on it out. This tool does not do that, and plain DNS cannot do it (see below).

It does not return geolocation or the network owner either; the result is the PTR name and nothing else. The lookup runs on the tool’s server, not in your browser, and no history of the IPs you check is stored.

How to use it

1. Type the IP address, for example 8.8.8.8.
2. Run the lookup.
3. Read the result: the PTR hostname, or the message that the IP publishes none.

No result is not an error. Most addresses have no PTR configured.

How to read the result

A PTR name usually tells you who runs the address block, not what is hosted on it:

Two details: a PTR is a claim by the IP owner, so a hostname that looks like a famous company proves nothing unless the name also resolves forward to the same IP (that is the FCrDNS check below). And an IP can have several PTR names; if so, they are all listed.

Why reverse IP shows hundreds of domains elsewhere, and only one name here

Sites that list “all domains on an IP” are not querying the PTR. They keep their own databases, built from passive DNS (observed A/AAAA answers), certificate transparency logs, zone files and crawling. That explains the limits of any “domains on this IP” list:

• Shared hosting and CDNs. One IP can serve thousands of unrelated sites. Behind Cloudflare, Fastly or Akamai the IP belongs to the network and the list is huge and mostly meaningless for finding the real server.
• Incomplete and dated. A list only knows what its crawler saw. Domains that moved away may still appear; new ones may be missing.
• Not proof of ownership. Two domains on one IP are not necessarily the same owner.

Reverse DNS, by contrast, returns what the IP owner published: normally one hostname, set by the hosting provider or ISP, and not by whoever registered the domain.

Why many IPs return nothing

The PTR record is optional, and only the owner of the address block can create it (it lives in the in-addr.arpa zone for IPv4 and ip6.arpa for IPv6, delegated to that owner). So:

• Residential connections rarely have a useful PTR.
• Freshly assigned servers have none until somebody sets it.
• Shared hosting points the PTR at the provider, not at any of its customers’ domains.

What this lookup can and cannot tell you

• It does not give the site’s owner. For the registrant of a domain, use WHOIS.
• It does not list the domains on the IP, as explained above.
• It does not locate the IP. For that you need a geolocation service, and even then it only gets the country right and the city approximately.
• It is not proof of identity: anyone who controls the block can publish any name.

Honest use cases

• Reading logs. Turn the IPs hitting your server into names to spot crawlers (crawl-66-249-...googlebot.com) or a cloud provider scanning you. Confirm a claimed bot by checking the name resolves forward to the same IP.
• Email deliverability. Receiving servers distrust sending IPs with no PTR, or whose PTR does not match the name the server announces. The check that the reverse name exists and resolves back to the same IP is called Forward-Confirmed reverse DNS (FCrDNS). If you run your own mail server, a coherent PTR is one of the first steps; you set it at your provider, not in your domain’s DNS.
• Identifying your own infrastructure. Check which hostname the provider assigned to a server and whether it matches what you intended.
• Quick triage of an unknown address, as a first clue before deeper checks.

Forward DNS versus reverse DNS

Everyday DNS goes one way: give it ortamarco.me, get an IP. Reverse DNS goes the other way: give it an IP, get a name. The two mappings are stored separately and managed by different people, which is why they often do not match.

Related checks

Reverse lookup is one piece of the picture. Combine it with a forward DNS lookup (A, MX, TXT), WHOIS for ownership, and the email checks (SPF, DKIM and DMARC) when the problem is deliverability. The domain health report runs those checks together.