Reverse DNS Lookup

About this tool

Reverse DNS Lookup is meant to find the hostname stored in an IP address's PTR record — the opposite of a normal lookup, which resolves a hostname to an IP. For an IPv4 address the tool builds the reverse name (8.8.8.8 becomes 8.8.8.8.in-addr.arpa, octets reversed) and asks the UtilityKit server for its PTR record; an IPv6 address is sent unchanged, without an ip6.arpa conversion. At the moment the server only answers A, AAAA, MX, TXT, NS and CNAME queries, so every PTR lookup ends with the error “Record type not supported”. When it works, the result shows the IP address, the first PTR hostname, any further PTR records and the name queried. The tool does not run a forward-confirmed (FCrDNS) check or show TTLs; use dig -x or nslookup on your computer in the meantime.

Why use it

• Builds the in-addr.arpa query name for IPv4 addresses so you do not have to reverse the octets yourself.

• Lists every PTR record returned, not just the first.

• Shows the exact name it queried, which helps when learning how reverse DNS works.

How to use

1. Enter an IPv4 address such as 8.8.8.8.
2. Click Lookup PTR or press Enter; the tool converts the address to its in-addr.arpa name and sends it to the server.
3. If a record comes back, read the Hostname (PTR) card and any additional PTR records listed below it.
4. If you see “Record type not supported”, the server is not answering PTR queries; run dig -x <ip> or nslookup <ip> locally instead.

When it helps

• Verifying an email server's PTR record matches its A record (Forward-Confirmed reverse DNS).
• Identifying the hostname of an IP address found in web server access logs.
• Diagnosing email delivery failures caused by missing PTR records.
• Security investigations to identify the operator of a suspicious IP.

Examples

8.8.8.8

Record type not supported (error; the query name 8.8.8.8.in-addr.arpa was rejected by the server)

93.184.216.34

Query name: 34.216.184.93.in-addr.arpa — the lookup then fails with “Record type not supported”.

Tips

• Always set rDNS for outbound mail servers — Gmail, Outlook, and Yahoo will reject mail from IPs without PTR records.
• Set the PTR to match the HELO/EHLO hostname exactly for the strongest sender reputation signal.
• FCrDNS verification means PTR → hostname AND hostname A record → original IP both must succeed — partial setup fails strict mail servers.
• Cloud providers (AWS EC2, GCP, Azure) require you to manually request a custom PTR record — defaults look like ec2-1-2-3-4.compute-1.amazonaws.com.
• If the PTR is missing on a critical IP, contact your hosting provider's support — most allow custom rDNS for free.
• When debugging mail issues, also check IP reputation (Spamhaus, SURBL) — rDNS alone is not enough for inbox placement.
• Multiple PTR records on one IP are technically allowed but often cause issues — most operators stick to one PTR per IP.

Frequently Asked Questions

Glossary

PTR record

Pointer record — a DNS record type that maps an IP address to a hostname. The reverse of an A or AAAA record. Stored in special reverse zones.

in-addr.arpa

The special DNS domain used for IPv4 reverse lookups. The IP's octets are reversed and appended (e.g. 93.184.216.34 → 34.216.184.93.in-addr.arpa).

ip6.arpa

The special DNS domain used for IPv6 reverse lookups. Each hex nibble of the IPv6 address is reversed and dot-separated under ip6.arpa.

FCrDNS

Forward-Confirmed reverse DNS — a verification method where the PTR hostname must resolve back to the original IP via an A/AAAA record. Required by most strict mail servers.

HELO/EHLO

The SMTP commands a mail client uses to identify itself to a mail server. Best practice: HELO hostname should match the PTR record on the sending IP.

SMTP banner

The greeting an SMTP server sends on connection (e.g. '220 mail.example.com ESMTP'). Some receivers compare the banner hostname to the PTR for additional verification.

Reverse zone delegation

The process where an ISP delegates control of an in-addr.arpa or ip6.arpa subzone to a customer so the customer can manage their own PTR records.

Authoritative answer

A DNS response from the server that holds the original record — as opposed to a cached response from a recursive resolver. The 'aa' flag in DNS messages.