↩️ Reverse IP Lookup ☆

Overview

Reverse IP Lookup performs reverse DNS lookups for any IPv4 or IPv6 address using DNS-over-HTTPS, then goes one step further than most tools: it forward-confirms the result. First the PTR record in the in-addr.arpa or ip6.arpa zone reveals the hostname; then the tool resolves that hostname forward and checks whether it points back to the IP you entered. That forward-confirmed reverse DNS (FCrDNS) check is exactly what mail servers verify before accepting messages, which makes this tool useful for diagnosing email deliverability, checking server configuration, verifying that a crawler or monitoring bot is legitimate, and investigating suspicious log entries. Queries go from your browser to Cloudflare or Google DoH resolvers; nothing is stored.

Why forward confirmation matters

A PTR record alone proves very little, anyone who controls reverse DNS for an address block can point a PTR at any hostname. Forward-confirmed reverse DNS closes that gap by resolving the returned hostname and checking that it maps back to the same IP. Mail servers rely on this exact check during greeting: a mismatch is a common reason legitimate email is rejected or marked as spam. The tool performs both directions and reports each step, so you can see whether the failure is in the PTR record, the forward A/AAAA record, or the handshake between them.

Technical specifications

Property	Reverse IP lookup behavior
Input	Any IPv4 or IPv6 address
Lookups	PTR record, then forward A/AAAA confirmation
Transport	DNS-over-HTTPS via Cloudflare or Google resolvers
Verdict	Forward-confirmed (FCrDNS) or mismatched
Stored by 0Appz	Nothing
Cost	Free, no account, unlimited lookups

Privacy: queries go directly to the resolvers

The lookups leave your browser for the DoH resolver, which sees the queried addresses as any resolver would. 0Appz does not proxy or store them; treat the addresses you check as ordinary connection metadata.

Diagnosing with reverse DNS

• Missing PTR on a mail server IP usually breaks deliverability.
• A PTR that does not forward-confirm is worse than none for spam scoring.
• Cloud and hosting providers often let you set PTR records in their control panel.
• Verify crawler claims by checking both PTR and forward records.
• Remember shared IPs can carry unrelated history, check before blocking ranges.

Related: browse the developer tools for DNS, IP, SSL and header checks.

Reverse DNS, PTR records and hostname resolution

A normal DNS query turns a name into an address; reverse DNS does the opposite, asking which hostname is associated with an address. It works through PTR records stored in a special zone built from the reversed octets of the address, and the answer is controlled by whoever owns the IP block, usually the ISP, hosting provider or cloud platform, not the website owner. That ownership explains the results: a residential address often resolves to a generic ISP hostname such as a pool identifier, while a server address may resolve to a meaningful name. For mail servers, reverse DNS matters a lot: most receiving systems check that the PTR record exists and that it matches the forward lookup for the same hostname, a check known as forward-confirmed reverse DNS. Missing or mismatched records are a common reason legitimate mail is rejected or marked as spam. Shared hosting and cloud instances frequently return a provider hostname that has nothing to do with the hosted website, and addresses behind carrier-grade NAT may have no PTR record at all. For diagnostics, reverse DNS helps identify which provider owns an address and whether it is residential, mobile or data centre. It cannot reveal a person, and an absent record is not an error. The lookup runs from your browser and stores nothing.