Reverse DNS Explained: What PTR Records Are and Why They Matter

Most people are familiar with forward DNS, the process of converting a domain name like "example.com" into an IP address like 93.184.216.34. Reverse DNS does the opposite: given an IP address, it returns the associated domain name. While forward DNS is essential for web browsing, reverse DNS plays a critical but often overlooked role in email delivery, security, logging, and troubleshooting.

This guide explains how reverse DNS works at a technical level, why it matters, and how to configure and troubleshoot PTR records. You can test reverse DNS for any IP address using our Reverse DNS tool.

How Reverse DNS Works

The in-addr.arpa Domain

Reverse DNS for IPv4 uses a special domain: in-addr.arpa. The IP address is reversed and appended to this domain to form the query. For example, to look up the reverse DNS for 93.184.216.34:

1. Reverse the octets: 34.216.184.93
2. Append in-addr.arpa: 34.216.184.93.in-addr.arpa
3. Query for the PTR record of this domain

The octets are reversed because DNS is hierarchical from right to left. The arpa zone delegates to 93, which delegates to 93.184, which delegates to 93.184.216, and finally 93.184.216.34 has the PTR record.

For IPv6

IPv6 reverse DNS uses ip6.arpa and works with individual nibbles (4-bit hex digits) rather than full octets. For the IPv6 address 2001:0db8:85a3::8a2e:0370:7334, the reverse DNS name would be:

4.3.3.7.0.7.3.0.e.2.a.8.0.0.0.0.0.0.0.0.3.a.5.8.8.b.d.0.1.0.0.2.ip6.arpa

Each hex digit is separated by a dot and the entire address is reversed. This format is considerably longer than IPv4 reverse DNS, but the principle is identical.

PTR Records

The DNS record type used for reverse DNS is the PTR (Pointer) record. A PTR record maps an IP address (in the in-addr.arpa or ip6.arpa format) to a hostname:

34.216.184.93.in-addr.arpa.    IN    PTR    server1.example.com.

This tells anyone querying that the IP address 93.184.216.34 is associated with server1.example.com.

How to Perform a Reverse DNS Lookup

Using command line tools:

# Using dig
dig -x 93.184.216.34

# Using nslookup
nslookup 93.184.216.34

# Using host
host 93.184.216.34

Using online tools:

The fastest way is our Reverse DNS tool, which performs the lookup instantly from your browser. You can also use our IP Lookup tool, which includes reverse DNS information alongside geolocation and ISP data.

Why Reverse DNS Matters

Email Delivery

Reverse DNS is arguably most important for email. Many mail servers perform reverse DNS lookups on incoming connections and will reject or flag messages if the sending server does not have a valid PTR record.

Here is what typically happens when your mail server sends an email:

1. Your server connects to the recipient's mail server from IP address 93.184.216.34.
2. The recipient's server performs a reverse DNS lookup on 93.184.216.34.
3. The lookup returns "mail.example.com."
4. The recipient's server then performs a forward DNS lookup on "mail.example.com."
5. If the forward lookup returns 93.184.216.34, the reverse DNS is "forward-confirmed" (FCrDNS), and the connection is trusted.
6. If there is no PTR record, or the forward lookup does not match, the connection may be rejected or the message marked as spam.

Forward-Confirmed Reverse DNS (FCrDNS)

FCrDNS is the gold standard for mail server identification. It requires that:

1. The IP address has a PTR record pointing to a hostname
2. That hostname has an A (or AAAA) record pointing back to the same IP address

This bidirectional verification prevents IP addresses from claiming association with domains they do not control. Major email providers including Gmail, Outlook, and Yahoo all check FCrDNS as part of their spam filtering.

If your email is being rejected or landing in spam, check your reverse DNS with our Reverse DNS tool and verify your mail server IP is not on any blacklists using our Blacklist Check tool.

Security and Logging

Server logs become readable. Without reverse DNS, server logs show only IP addresses, which are difficult to interpret at a glance. With reverse DNS, logs can show hostnames, making it immediately apparent whether traffic is coming from a known source.

Intrusion detection benefits. Security systems use reverse DNS to categorize traffic sources. A connection from "mail.google.com" is treated differently from one with no reverse DNS or a hostname like "host-192-168-1-100.residential.isp.com."

Audit trails improve. When investigating security incidents, reverse DNS provides additional context that helps identify the source and nature of traffic.

Network Troubleshooting

Reverse DNS makes traceroute output readable. Compare these two traceroute outputs:

Without reverse DNS:

1  192.168.1.1     1.2 ms
2  10.45.2.1       5.8 ms
3  72.14.215.68    12.3 ms
4  108.170.241.97  15.1 ms

With reverse DNS:

1  router.local                    1.2 ms
2  gw-core.isp.net                 5.8 ms
3  chi-b21-link.isp.net            12.3 ms
4  108.170.241.97.google.com       15.1 ms

The second output immediately tells you the traffic path: your local router, your ISP's core gateway, an ISP link in Chicago, and a Google server. You can try this yourself with our Traceroute tool.

How to Set Up Reverse DNS

Who Controls PTR Records?

Unlike forward DNS, which is managed by the domain owner, reverse DNS is managed by whoever controls the IP address block. This is typically:

• Your ISP for residential and small business connections
• Your hosting provider for hosted servers (e.g., AWS, DigitalOcean, Hetzner)
• Your organization's IP team if you own your own IP address space

For Hosted Servers

Most hosting providers offer a control panel option to set PTR records:

• AWS EC2: Use an Elastic IP and request a reverse DNS record through the AWS support portal or Route 53.
• DigitalOcean: The PTR record is automatically set to the droplet's name. Rename your droplet to the desired hostname.
• Hetzner: Set the PTR record through the Cloud Console or Robot panel under the IP management section.
• Vultr: Set via the control panel under the Server Settings > IPv4 section.

For ISP-Provided IPs

If you run a mail server on a business internet connection, contact your ISP and request that they set a PTR record for your static IP. Some ISPs offer self-service portals for this. Note that PTR records generally require a static IP; most ISPs will not set PTR records for dynamic IPs.

Verification

After setting up your PTR record, verify it using our Reverse DNS tool. Also confirm FCrDNS by:

1. Looking up the PTR for your IP (should return your hostname)
2. Looking up the A record for that hostname (should return your IP) using our DNS Lookup tool

Both lookups should form a matching pair.

Common Reverse DNS Problems

No PTR Record Found

Symptoms: Reverse DNS lookup returns NXDOMAIN or no result.

Impact: Email delivery will be severely impacted. Many mail servers reject connections from IPs without PTR records.

Solution: Contact your ISP or hosting provider to have a PTR record created.

PTR Does Not Match Forward DNS

Symptoms: PTR returns "mail.example.com" but the A record for "mail.example.com" points to a different IP.

Impact: FCrDNS fails. Some mail servers will reject connections; others will add negative scoring to spam filters.

Solution: Ensure the A record for your hostname points to the same IP that has the PTR record.

Generic ISP Hostname

Symptoms: PTR returns something like "host-93-184-216-34.residential.isp.net."

Impact: While this is better than no PTR, many spam filters penalize generic residential-looking hostnames for mail servers.

Solution: Request a custom PTR from your ISP or use a hosting provider that allows PTR customization.

Slow Reverse DNS Resolution

Symptoms: Connections to your server are slow to establish. Services hang for several seconds when clients connect.

Impact: Many services (including SSH and some web servers) perform reverse DNS lookups on incoming connections. If the lookup is slow, the connection is delayed.

Solution: Ensure your PTR record is properly configured and the authoritative DNS server for your reverse zone is responsive. You can also disable reverse DNS lookups in services where it is not needed (e.g., UseDNS no in SSH config).

Multiple PTR Records

Symptoms: Multiple PTR records exist for a single IP address.

Impact: While technically allowed by DNS, multiple PTR records can cause unpredictable behavior. Different resolvers may return different results.

Solution: Best practice is to have exactly one PTR record per IP address. Use the one that represents the primary purpose of that IP.

Reverse DNS and Privacy

Reverse DNS can reveal information about the owner and purpose of an IP address. For example, a reverse DNS lookup might reveal:

• The hosting provider or ISP
• The organization operating the server
• Geographic hints (hostnames like "nyc-web01" or "lon-db-primary")
• The server's role (hostnames like "mail.example.com" or "ns1.example.com")

If privacy is a concern, you can set PTR records to reveal minimal information (e.g., "host1.example.com" instead of "production-database-nyc.example.com"). Check what your IP currently reveals using our IP Lookup tool and Reverse DNS tool.

Key Takeaways

• Reverse DNS maps IP addresses to hostnames using PTR records in the in-addr.arpa (IPv4) or ip6.arpa (IPv6) zones
• Forward-Confirmed Reverse DNS (FCrDNS) requires the PTR and A records to form a matching pair
• Reverse DNS is critical for email delivery; servers without valid PTR records often have mail rejected
• PTR records are managed by whoever controls the IP address block, not the domain owner
• Reverse DNS makes server logs, traceroutes, and security audits more readable
• Use our Reverse DNS tool to check any IP and our Blacklist Check to verify email reputation

Related Articles:

• DNS Records Explained: A Complete Guide to A, AAAA, MX, NS, TXT, and CNAME
• SSL/TLS Certificates Explained: How HTTPS Keeps You Safe Online
• ASN and BGP Basics: How Internet Routing Actually Works