About this tool
Enter an IPv4 or IPv6 address to resolve its PTR record — the reverse DNS name assigned to that IP. Useful for mail server audits, abuse tracing, CDN identification, and understanding which hostname the IP owner publishes.
How to do a reverse DNS lookup
- Enter an IPv4 or IPv6 address.
- The tool queries the PTR record for that IP and returns the hostname it points to.
- Review the result — ISPs typically expose generic reverse names; dedicated servers show their real hostname.
- Use the hostname to identify the operator of an IP when auditing traffic or logs.
Common use cases
- Identifying whether a suspicious IP in your server logs belongs to a known cloud provider or a residential ISP.
- Verifying that a mail server has matching forward and reverse DNS, which many receivers require to accept mail.
- Spotting abuse traffic by seeing that many IPs share the same reverse-DNS pattern.
- Debugging hostname-based firewall rules that depend on a valid PTR record.
Frequently asked questions
What is a PTR record?
The DNS record that maps an IP address back to a hostname — the opposite direction of an A or AAAA record. PTRs live in the in-addr.arpa (IPv4) or ip6.arpa (IPv6) zone.
Why do many IPs have no PTR?
Setting up PTRs requires control of the reverse zone, which is delegated by the IP block owner (usually the ISP). Not every IP has one, especially on consumer ranges.
Do mail servers require PTR?
Most major mail receivers (Gmail, Outlook, Yahoo) reject connections from IPs with no PTR or where PTR and HELO do not match. If you run your own mail server, set up PTR with your hoster.
Is my query logged?
No. Lookups run through the browser and results are not stored server-side.
Why reverse DNS matters
PTR records map an IP back to a hostname. Mail servers check PTR for spam filtering — missing or mismatched PTR is a strong negative signal for deliverability. Reverse DNS is also useful for identifying what lives behind a given IP when auditing a network or investigating an incident.
- IPv4 and IPv6 support
- Full RFC-compliant in-addr.arpa and ip6.arpa construction
- Powered by Cloudflare DoH
- No signup, no logging
- Clear "no PTR" state for IPs without reverse DNS
Free. No signup. Browser tools (subnet, JWT, password strength) run locally; lookup tools query public APIs (Cloudflare DoH, RDAP, certificate logs). Full per-tool breakdown at /methodology/.
Sources (2)
- Mockapetris, P. (1987). Domain Names — Implementation and Specification (in-addr.arpa zone). RFC 1035, IETF.
- Thomson, S., Huitema, C., Ksinant, V., & Souissi, M. (2003). DNS Extensions to Support IP Version 6 (ip6.arpa zone). RFC 3596, IETF.
These are the IETF RFCs, NIST publications, and W3C standards the tool implements or queries. Locate them on the IETF Datatracker (datatracker.ietf.org) or the official standards body.
Related guides
- DNS Propagation — Why "Wait 48 Hours" Is Mostly WrongDNS changes do not propagate — caches expire. Here is how TTL, negative caching, and public resolvers actually work during a migration.
- Email Authentication — SPF, DKIM, and DMARC Explained ProperlyHow SPF, DKIM and DMARC actually work together to authenticate email, with the gotchas that break deliverability in production.
By Marco B. ·