Reverse IP Lookup

Reverse IP Lookup is a free tool that finds the domain or host associated with an IP address.

How does an IP address point back to a hostname?

An IP address can point back to a hostname through reverse Domain Name System records, commonly called reverse DNS or rDNS. A normal DNS lookup starts with a name such as mail.example.com and requests its IP address. A reverse lookup starts with the IP address and asks whether the organization controlling the reverse-DNS delegation has assigned a hostname to it.

Reverse DNS commonly uses a PTR record. For IPv4, DNS reverses the address octets and places them under the in-addr.arpa domain. A query for 192.0.2.25 therefore uses a reverse-DNS name based on 25.2.0.192.in-addr.arpa. IPv6 uses a longer reversed representation under ip6.arpa.

The organization that controls the IP address normally controls its reverse-DNS delegation. Changing a domain's DNS records at a registrar does not necessarily give you control over its PTR record. A hosting company, cloud provider, internet service provider, or network administrator may need to make that change.

Choosing and checking the input

Enter the IP address itself, without a protocol, path, port, or subnet suffix. For example, use 192.0.2.25, not https://192.0.2.25/login, 192.0.2.25:443, or 192.0.2.0/24.

IPv4 addresses use decimal numbers separated by periods. IPv6 addresses usually use hexadecimal characters and colons, and compressed forms may contain a double colon. The colons in an IPv6 address are part of the address rather than punctuation to remove.

• Do not enter a domain name when the intended operation starts with an IP address.

The lookup is performed on the server. Your input travels to the server over HTTPS and is not stored.

What does each part of the response tell you?

The IP address is the input being checked, while the returned domain or host is the name associated with that address. Read the two together and compare the hostname with the service you expected to find.

For a worked example, suppose you enter 192.0.2.25 and the response names mail.example.com. That result means the address has a reverse association with that hostname. It does not prove that every service at the address uses that name, or that forward DNS currently maps mail.example.com back to the same address.

If no associated hostname is available, the address may have no PTR record, its reverse zone may be misconfigured, or the relevant DNS response may be unavailable. A missing reverse result does not mean the IP address is unused.

Which problems can reverse IP evidence help diagnose?

Reverse IP evidence can help diagnose mail delivery, server identity, and hostname consistency problems. It is one piece of the investigation, so compare it with forward DNS, application settings, and service logs.

1. Email is rejected or delayed. Check the sending server's public IP address. If its reverse name is missing, generic, or unrelated to the configured mail identity, ask the IP provider about the PTR record. Some receiving mail systems also compare the reverse hostname with its forward A or AAAA records, although acceptance policies vary.
2. A certificate warning names an unexpected host. Run the reverse check on the destination IP to see which hostname is associated with it. A provider hostname can suggest that traffic reached the wrong server, but reverse DNS does not determine whether a TLS certificate is valid. Use SSL Lookup to inspect the certificate itself.
3. A site resolves to an unfamiliar server. Look up the IP returned by forward DNS and compare the reverse hostname with the expected hosting environment. Shared platforms may return a general infrastructure name. DNS Lookup can then confirm the site's A and AAAA records, while IP Lookup can provide broader information about the address.

No, this check cannot produce a complete list of websites hosted on an IP address. Many unrelated domains can share one address, and a PTR response generally supplies a reverse hostname rather than a virtual-host inventory.

How long can cached reverse DNS hide a change?

Cached reverse DNS can hide a recent PTR change until existing cache entries expire. DNS resolvers store answers for the record's time to live, or TTL, so two networks can temporarily receive different answers during a change.

Negative answers may also be cached. If a resolver previously learned that no PTR record existed, adding the record might not become visible through that resolver until its negative cache expires. People often call this propagation delay, though much of the apparent delay comes from cached data rather than records physically moving between every DNS server.

Confirm that the IP provider changed the correct reverse zone, wait for the applicable cache period, and retry from another resolver if available. Repeated checks against the same cached resolver do not force an authoritative DNS server to refresh the result.

Frequently asked questions

Does a PTR hostname prove who operates an IP address?

No. A PTR hostname is a domain name selected by the party controlling the reverse zone, and it is not proof of legal ownership or operational control. Provider records, routing data, and direct confirmation from the host are better sources for attribution.

Why does forward DNS point somewhere different?

Forward and reverse records are maintained separately, so they can disagree after a migration or configuration change. Check the returned hostname's A and AAAA records and verify that the PTR was updated by the organization controlling the IP block.

Can reverse DNS identify the person who sent an email?

No. It may identify a hostname associated with an IP recorded in the message headers, but it does not identify an individual sender. Email can pass through relays, forwarding services, gateways, and shared mail infrastructure before reaching the recipient.

Is an IP address confidential when I submit it?

The address is sent to the server over HTTPS so the server can perform the lookup, and it is not stored. Avoid submitting internal details beyond the IP address required for the check, especially when working from security incident notes.

Final checks

Copy the address directly from the relevant DNS response, mail header, server log, or certificate connection details. Confirm that you selected the destination or sending IP rather than a local router address, compare the returned hostname with forward DNS, and account for cached answers before requesting another PTR change.