codynet

DNS

Reverse DNS (PTR) Lookup

Free online PTR lookup tool. Run a reverse DNS PTR query on any IPv4 or IPv6 address and check the PTR record in seconds.

Query PTR

Enter an IPv4 or IPv6 address to look up its PTR records.

Results come from deterministic DNS APIs or HTTPS RDAP endpoints.

Results

Run a lookup to see structured results here.

Practical guide

How to use the Reverse DNS (PTR) tool

PTR records map an IP back to a hostname. They are used by mail servers for sender reputation, by network operators for human-readable traceroutes, and by anyone investigating who an IP claims to belong to.

What this tool checks

The tool takes an IPv4 or IPv6 address, converts it into the appropriate reverse-zone name (under in-addr.arpa or ip6.arpa), and queries that name for PTR records via a public resolver. The response is the hostname the operator of the IP block has published for this address — or NXDOMAIN if none exists.

When to use it

Use this to debug mail deliverability (most receiving servers reject senders with no PTR), to confirm that your cloud instance has the reverse DNS you expect, to investigate the apparent owner of an IP from logs or firewall events, and to spot-check whether forward-confirmed reverse DNS round-trips correctly. Reverse DNS is also useful in incident response for quickly humanizing an IP list.

How to read the result

A successful answer is one or more PTR records — typically just one. The hostname returned is whatever the IP-block holder published; it is not authoritative for anything else, but it is a strong hint about the network operator. For full validation, take that hostname and look up its A / AAAA record using the DNS tool — if it points back to the original IP, the FCrDNS round-trip succeeds.

Common errors and what they mean

NXDOMAIN means no PTR exists for the address. For private IPs and unallocated space this is normal. For a public production server, NXDOMAIN is usually a misconfiguration — talk to whoever holds the IP block (cloud provider, ISP) to set or delegate the reverse zone. SERVFAIL on a reverse query is unusual and typically points to a broken delegation in the reverse zone (the parent says "ask this server" but the server does not answer).

Example PTR lookup

Example input
8.8.8.8
Example result
8.8.8.8.in-addr.arpa.   86400   IN   PTR   dns.google.

The PTR resolves to dns.google. Looking up dns.google forward returns 8.8.8.8 and 8.8.4.4 — so FCrDNS round-trips and this is a well-configured production address.

Related tools

DNS Lookup

Forward-resolve the hostname PTR returned to confirm FCrDNS round-trips.

Open tool

IP Registration Lookup

Find out which organization actually holds the block the PTR comes from.

Open tool

DIG Lookup

Run the same reverse query with full packet detail when PTR behaves strangely.

Open tool

Related guides

DNS Records Explained

Where PTR fits in alongside the other DNS record types and why reverse lookups exist.

Read guide

NXDOMAIN vs SERVFAIL

Reverse lookups commonly return NXDOMAIN — here's when that's expected versus a real configuration problem.

Read guide

MX Records And Email Routing

Why missing or generic PTR is one of the biggest reasons outbound mail gets rejected at the destination.

Read guide

FAQ

What is a PTR record and how is it different from an A record?
An A or AAAA record maps a hostname to an IP address — the 'forward' direction. A PTR record does the opposite: it maps an IP address back to a hostname. PTR records live in special reverse-DNS zones (in-addr.arpa for IPv4 and ip6.arpa for IPv6) and are typically managed by whoever holds the IP block, not by the owner of the hostname.
Why does my server's IP have no PTR or the wrong PTR?
Reverse DNS for an IP is controlled by the holder of the address block, not by you. On a cloud provider you set PTR through the provider's console; on a dedicated IP you ask the ISP to delegate the reverse zone. If the PTR points to a generic hostname like a cloud-provider default, the reverse zone is delegated to the provider and you have not set a custom value yet.
Why does mail get rejected when PTR is missing?
Receiving mail servers commonly check that a connecting SMTP server's IP has a PTR record and that the PTR's hostname forward-resolves back to the same IP (a 'forward-confirmed reverse DNS' check). If PTR is missing, generic, or does not round-trip, the sending server looks like a residential or compromised host and the mail is rejected or sent to spam. This is one of the most common deliverability failures.
Why does this tool return NXDOMAIN for a private IP?
Private ranges (10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16) and link-local ranges have no public reverse zone, so the public DNS hierarchy will return NXDOMAIN. PTR for those ranges only exists on internal DNS, which a public tool cannot see. NXDOMAIN here is the expected answer for non-routable addresses.
Does an IPv6 PTR work the same way?
Yes, but the reverse zone is laid out in nibbles under ip6.arpa instead of octets under in-addr.arpa. The tool handles the nibble expansion for you — you submit a normal IPv6 address and it queries the right reverse name automatically. PTR coverage for IPv6 is still patchy on the public internet, so missing PTR is much more common than for IPv4.

Last reviewed: 2026-05-20.