Reverse DNS Lookup: What It Is, How It Works, and Why It Matters

Forward DNS is what most people think of when they hear "DNS" — you type google.com and it returns 142.250.80.46. Reverse DNS is the opposite: you start with an IP address and ask what domain name is associated with it.

The technical name for reverse DNS is a PTR record lookup (Pointer Record). It's a quiet but essential piece of internet infrastructure that affects email deliverability, server identity verification, and log readability in ways that aren't obvious until something breaks.

How Reverse DNS Works

Forward DNS lives in zones organised by domain name: google.com, mail.google.com, and so on.

Reverse DNS lives in a special zone called in-addr.arpa for IPv4 (and ip6.arpa for IPv6). To look up the PTR record for 203.0.113.42, the DNS system queries:

42.113.0.203.in-addr.arpa

Notice the IP is reversed. This reversal is how DNS delegation works — the IP address hierarchy goes from general (leftmost octet) to specific (rightmost), while in-addr.arpa zones are delegated in that order.

If a PTR record exists for that IP, it returns a hostname. If it doesn't exist, the lookup returns NXDOMAIN.

Who Controls PTR Records?

This is the key point that trips people up: PTR records are controlled by whoever owns the IP address block, not whoever owns the domain.

If your server is hosted at AWS, AWS controls the PTR record for your server's IP — you set it through the AWS console (under EC2 → Elastic IPs → Actions → Update reverse DNS), not through your domain registrar.

If you're on a VPS provider, they give you a panel setting to set your PTR record. If you're on shared hosting, you typically can't control the PTR record at all — it's whatever the host configured.

This matters because:

• Setting a PTR record requires write access to the IP owner's reverse DNS zone
• Your hosting provider must actually configure it based on what you request
• No amount of DNS changes at your registrar will affect a PTR record

How to Do a Reverse DNS Lookup

Online: Use the Reverse DNS Lookup tool. Enter any IP address and it returns the PTR record (hostname) if one exists.

Command line:

# Linux / macOS
dig -x 8.8.8.8
host 8.8.8.8
nslookup 8.8.8.8

# Windows
nslookup 8.8.8.8

Output from dig -x 8.8.8.8:

;; ANSWER SECTION:
8.8.8.8.in-addr.arpa.    21599   IN  PTR  dns.google.

So 8.8.8.8 reverse-resolves to dns.google — which makes sense, it's Google's DNS server.

Why Reverse DNS Matters

Email Deliverability

This is the most immediate practical reason to care about PTR records. When your mail server sends email, receiving mail servers perform a reverse DNS lookup on your sending IP. They check two things:

1. Does a PTR record exist for this IP?
2. Does the hostname in the PTR record forward-resolve back to the same IP? (Forward-confirmed Reverse DNS, or FCrDNS)

If either check fails, the email is more likely to be flagged as spam or rejected outright. Major providers including Gmail, Microsoft, and Yahoo all factor PTR records into spam scoring.

A properly configured mail server has:

• PTR record: 203.0.113.42 → mail.example.com
• A record: mail.example.com → 203.0.113.42

These two records confirm each other. Without this, you're sending email from an IP that can't identify itself, which looks exactly like spam infrastructure.

Log Readability

Server logs record IP addresses. When you're reviewing access logs, error logs, or security logs, a long list of IP addresses is hard to read. Many log analysis tools can be configured to resolve IPs to hostnames — turning 203.0.113.42 into mail.example.com makes the logs significantly easier to parse.

This also applies to tools like netstat, ss, and packet captures — seeing hostnames instead of raw IPs is much more useful in practice.

Network Troubleshooting

When you're tracing a network path with traceroute, each hop shows an IP address. Hops with PTR records resolve to hostnames, which often reveals the network operator and sometimes the physical location:

3   ae-10.r03.amstnl07.us.bb.gin.ntt.net (129.250.3.242)  8.123 ms
4   ae-5.r00.amstnl07.us.bb.gin.ntt.net (129.250.3.64)    8.456 ms

Without PTR records, traceroute just shows raw IPs — much less useful for identifying which provider is experiencing latency.

Security Investigation

When you find an unknown IP connecting to your server or appearing in your firewall logs, a reverse DNS lookup is one of the first steps in figuring out what it is.

An IP that reverse-resolves to mail.google.com is very different from one that resolves to dynamic-pool-72.isp-xyz.net or returns NXDOMAIN. The hostname doesn't prove identity — PTR records can be set to anything — but it provides context that guides further investigation.

Combine a reverse DNS lookup with a WHOIS lookup and an ASN lookup for a fuller picture.

When Reverse DNS Returns Nothing

A missing PTR record (NXDOMAIN) is common and sometimes expected:

• Residential IPs: Most home ISPs don't set PTR records for individual subscriber IPs
• Dynamic IPs: Ranges that get reassigned frequently often don't have PTR records
• Some cloud IPs: Not all cloud providers configure PTR records by default

A missing PTR record is a problem for mail servers (it will hurt your spam score), but it's perfectly normal for web servers, VPNs, or any service that doesn't send email.

Forward-Confirmed Reverse DNS (FCrDNS)

FCrDNS is the chain of verification that email servers care about most:

1. Your IP (203.0.113.42) has a PTR record pointing to mail.example.com
2. mail.example.com has an A record pointing back to 203.0.113.42
3. The two match — this is FCrDNS

Setting up FCrDNS for a mail server:

1. Set the PTR record through your hosting provider (look for "Reverse DNS" or "PTR record" in your server panel)
2. Make sure the hostname in your PTR record has an A record pointing to your server's IP in your domain's DNS
3. Verify with: dig -x YOUR_IP and dig A YOUR_HOSTNAME

Both lookups should return matching results.

Checking Multiple IPs

If you're auditing a range of IPs — checking which ones have PTR records, or verifying FCrDNS for a list of mail servers — batch tools are more efficient. The Reverse DNS Lookup tool handles individual lookups. For bulk lookups, for loops in bash work well:

for ip in 8.8.8.8 1.1.1.1 9.9.9.9; do
    echo -n "$ip: "
    dig -x $ip +short
done

Output:

8.8.8.8: dns.google.
1.1.1.1: one.one.one.one.
9.9.9.9: dns.quad9.net.

The Bottom Line

Reverse DNS is how an IP address claims an identity. It's the mechanism behind email server verification, readable logs, and meaningful traceroutes.

For servers that send email, FCrDNS is mandatory — configure your PTR record through your hosting provider and verify it matches your hostname's A record. For investigation, a reverse DNS lookup on any unknown IP is a fast first step.

Use the Reverse DNS Lookup tool to check any IP instantly.