How to Perform a Reverse DNS Lookup

Standard DNS translates domain names to IP addresses. Reverse DNS does the opposite: it takes an IP address and returns the associated domain name. This process relies on PTR (Pointer) records and is essential for email deliverability, security investigations, and network troubleshooting.

This guide explains how reverse DNS works, how to perform lookups, why it matters for your infrastructure, and how to set up PTR records correctly.

How Reverse DNS Works

Forward DNS uses A records to map example.com to 93.184.216.34. Reverse DNS uses PTR records to map 93.184.216.34 back to example.com.

Reverse DNS queries use a special domain: in-addr.arpa for IPv4 and ip6.arpa for IPv6. The IP address is reversed and appended to this domain. For example, looking up 93.184.216.34 actually queries 34.216.184.93.in-addr.arpa for a PTR record.

This reversal exists because DNS is hierarchical, organized from right to left. Reversing the IP address aligns the most significant octets with the DNS hierarchy, allowing delegation to work correctly.

How to Perform a Reverse DNS Lookup

Using dig

The dig -x command is the simplest way to perform a reverse DNS lookup:

# Reverse lookup for an IPv4 address
dig -x 93.184.216.34

# Short output
dig -x 93.184.216.34 +short

# Reverse lookup for an IPv6 address
dig -x 2606:2800:220:1:248:1893:25c8:1946 +short

# Manual PTR query (equivalent to dig -x)
dig 34.216.184.93.in-addr.arpa PTR +short

The -x flag automatically handles the IP reversal and in-addr.arpa suffix, making it the preferred approach.

Using nslookup

# Reverse lookup
nslookup 93.184.216.34

# Specify a DNS server
nslookup 93.184.216.34 8.8.8.8

nslookup automatically detects that the input is an IP address and performs a reverse query.

Using host

On Linux and macOS, the host command provides a clean interface for reverse lookups:

host 93.184.216.34

Output: 34.216.184.93.in-addr.arpa domain name pointer example.com.

Using Web-Based Tools

Online reverse DNS lookup tools accept an IP address and return the associated PTR record. These are convenient when you do not have access to a command line or need to share results. MXToolbox, DNSChecker, and ViewDNS.info all offer reverse DNS lookup functionality.

Why Reverse DNS Matters

Email Deliverability

This is the most common reason to care about reverse DNS. Mail servers routinely check the reverse DNS of the sending IP address. If the PTR record does not exist, or if it does not match the sending domain, the email is more likely to be flagged as spam or rejected outright.

Many major email providers, including Gmail and Microsoft, explicitly recommend or require valid reverse DNS for sending mail servers.

Security and Investigations

Reverse DNS helps identify who operates a given IP address. During security investigations, analysts use rDNS to:

• Identify the organization behind an IP address in server logs
• Determine if an IP belongs to a known hosting provider, ISP, or cloud platform
• Detect spoofed source addresses (if rDNS does not resolve, the source may be suspicious)

Network Troubleshooting

When reviewing traceroute output, reverse DNS provides human-readable hostnames for each hop instead of raw IP addresses. This makes it far easier to identify where in a network path a problem occurs.

Setting Up PTR Records

Forward-Confirmed Reverse DNS (FCrDNS)

The gold standard for reverse DNS validation is forward-confirmed reverse DNS. This means:

1. The IP address 93.184.216.34 has a PTR record pointing to mail.example.com
2. The hostname mail.example.com has an A record pointing back to 93.184.216.34

Both directions confirm each other. This is what email receivers check for, and it is what you should aim for with every PTR record you configure.

# Step 1: Check reverse DNS
dig -x 93.184.216.34 +short
# Returns: mail.example.com.

# Step 2: Check forward DNS
dig mail.example.com A +short
# Returns: 93.184.216.34

# Both match — FCrDNS is valid

Common Reverse DNS Issues

No PTR Record

The most common issue. Many hosting providers do not create PTR records by default. You need to request or configure them explicitly. This is especially critical for mail servers.

Generic ISP Hostname

Default PTR records from ISPs often look like host-93-184-216-34.dynamic.isp.net. These generic hostnames signal that the IP is a residential or dynamic address, which many mail servers block. If you are running a mail server, you need a custom PTR record with your own domain name.

PTR Points to Wrong Hostname

After migrating services to a new domain, the PTR record may still point to the old hostname. Update the PTR record at your hosting provider and verify the forward DNS matches.

IPv6 Reverse DNS

IPv6 reverse DNS works the same way conceptually, but the addresses are longer and use ip6.arpa instead of in-addr.arpa. Each hexadecimal digit becomes a separate label in the reverse name, making IPv6 PTR records extremely long. Most providers handle this automatically when you configure reverse DNS through their control panel.

Reverse DNS for Cloud and CDN Services

If you use a cloud provider or CDN that assigns shared IP addresses, you may not be able to set PTR records because you do not own the IP. In these cases:

• Use the cloud provider's built-in email sending service, which has proper rDNS configured
• Use a dedicated IP address if your provider offers one, and configure the PTR record for it
• Use a third-party email service (like SendGrid, Postmark, or Amazon SES) that manages rDNS for their sending IPs

Reverse DNS is a small detail with outsized impact. For email deliverability, it can be the difference between inbox and spam folder. For security, it provides essential context during investigations. Setting up and verifying PTR records is a one-time task that pays ongoing dividends.