What Is Reverse DNS and When Do You Need It?

Introduction

Standard DNS works in one direction: you give it a domain name like mail.example.com, and it returns an IP address like 203.0.113.25. Reverse DNS does exactly the opposite. You provide an IP address, and the system returns the hostname associated with it. If you need a refresher on how forward DNS resolution works, see our guide on how DNS works.

This might sound like a niche capability, but reverse DNS touches critical infrastructure workflows every day. When a mail server receives an inbound message, one of the first things it does is perform a reverse DNS lookup on the sending IP. When a security analyst investigates suspicious traffic in a log file, reverse IP lookup turns raw addresses into identifiable hostnames. When you run traceroute, those readable hop names come from reverse DNS.

If you manage a mail server, run any internet-facing service, or analyze network traffic, understanding how reverse DNS works is not optional. This guide explains the mechanism, walks through practical commands, and covers every scenario where you need to get it right.

How Reverse DNS Works

A reverse DNS lookup resolves an IP address to a hostname through PTR (pointer) records. These records live in a special domain namespace managed specifically for this purpose.

The in-addr.arpa Domain

For IPv4, reverse DNS uses the in-addr.arpa domain. The IP address is reversed at the octet level and appended to this domain. For example, to look up the hostname for 8.8.8.8, the DNS resolver queries:

8.8.8.8.in-addr.arpa

The octets are reversed because DNS is hierarchical from right to left. In forward DNS, mail.example.com delegates from com to example to mail. Reversing the IP octets preserves this delegation model. The 8.0.0.0/8 block is delegated first, then 8.8.0.0/16, and so on down to the individual host record.

For IPv6, the same concept applies using the ip6.arpa domain, but each nibble (4-bit hex digit) is reversed individually. A single IPv6 address produces a 64-character domain name, which is why IPv6 reverse DNS is almost always automated.

How the Query Flows

When you initiate a reverse DNS lookup, here is what happens:

1. Your resolver reverses the IP octets and appends in-addr.arpa.
2. It queries the root DNS servers, which delegate to the appropriate Regional Internet Registry (ARIN, RIPE, APNIC, etc.).
3. The RIR’s nameservers delegate further to the nameservers of the organization that owns the IP block.
4. The authoritative nameserver for that IP range returns the PTR record containing the hostname.

If no PTR record exists at any point in this chain, the reverse DNS lookup fails, and the query returns NXDOMAIN or an empty result.

Why Reverse DNS Matters

Email Deliverability

This is the most common reason administrators encounter reverse DNS. Nearly every major mail provider, including Google Workspace, Microsoft 365, and Yahoo Mail, checks the PTR record of the sending IP before accepting a message.

Here is the logic a receiving mail server follows:

1. An SMTP connection arrives from IP 203.0.113.25.
2. The receiving server performs a reverse DNS lookup on that IP.
3. If no PTR record exists, the message is rejected or sent to spam.
4. If a PTR record returns mail.example.com, the server may then do a forward lookup on mail.example.com to see if it resolves back to 203.0.113.25. This is forward-confirmed reverse DNS.

Google’s postmaster guidelines state this explicitly: “The sending IP must have a PTR record. The hostname in the PTR record must have a forward DNS that resolves back to the sending IP.” Without this, your email will not reach Gmail inboxes reliably.

If you run your own mail server, you can perform a reverse DNS lookup instantly to verify your configuration before sending a single message.

Security and Forensics

Raw IP addresses in log files are difficult to work with at scale. Reverse DNS lookup lets security analysts quickly associate addresses with organizations and hostnames. When you see 198.51.100.44 in a firewall log, a reverse IP lookup might reveal scanner-node.suspiciousvps.net, giving you immediate context about the traffic source.

Many intrusion detection systems and SIEM platforms perform automatic reverse DNS lookups to enrich log data. This correlation is also useful when investigating abuse reports, since reporting to the correct responsible party requires knowing who operates the IP. A properly configured firewall can log source IPs alongside reverse DNS data, making forensic analysis much faster.

You can also check your public IP and its associated hostname to see what your own infrastructure reveals about itself.

Network Troubleshooting

When you run traceroute or mtr, every hop in the path can display a hostname if a PTR record exists. Compare:

5  72.14.236.216  12.4 ms
6  142.251.49.135  13.1 ms

versus:

5  lax17s55-in-f216.1e100.net (72.14.236.216)  12.4 ms
6  lax28s18-in-f135.1e100.net (142.251.49.135)  13.1 ms

The second output immediately tells you the traffic is transiting Google’s network. This context is invaluable when diagnosing routing anomalies, latency issues, or path changes. Network engineers working with subnet calculations and routing tables rely on reverse DNS to make sense of trace data. For a broader look at diagnosing connection problems, see our network connectivity troubleshooting guide.

Compliance and Auditing

Some enterprise security policies and regulatory frameworks require reverse DNS to be configured for all public-facing IP addresses. PCI DSS assessments, SOC 2 audits, and some government security baselines treat missing PTR records as a configuration deficiency. Even when not strictly mandatory, auditors view properly configured reverse DNS as a sign of operational maturity.

How to Perform a Reverse DNS Lookup

Command Line Methods

Every major operating system includes tools for reverse DNS lookups. Here are the most common approaches.

Using nslookup (Windows, macOS, Linux):

$ nslookup 8.8.8.8
Server:    192.168.1.1
Address:   192.168.1.1#53

Non-authoritative answer:
8.8.8.8.in-addr.arpa    name = dns.google.

Using dig -x (macOS, Linux):

$ dig -x 8.8.8.8 +short
dns.google.

The -x flag tells dig to perform a reverse lookup. It automatically handles the octet reversal and in-addr.arpa construction. For full detail, omit +short:

$ dig -x 8.8.8.8

;; QUESTION SECTION:
;8.8.8.8.in-addr.arpa.       IN      PTR

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

Using host (macOS, Linux):

$ host 8.8.8.8
8.8.8.8.in-addr.arpa domain name pointer dns.google.

Online Tools

If you need a quick check without opening a terminal, you can perform a reverse DNS lookup instantly using our web-based tool. This is particularly useful when you need to look up multiple IPs quickly or share results with non-technical stakeholders.

Programmatic Lookups

For automation and scripting, Python provides a straightforward approach:

import socket

try:
    hostname, aliases, addresses = socket.gethostbyaddr("8.8.8.8")
    print(f"Hostname: {hostname}")
except socket.herror as e:
    print(f"Reverse DNS lookup failed: {e}")

This is useful in log processing scripts, monitoring tools, and security automation pipelines where you need to resolve thousands of IPs programmatically.

How to Set Up Reverse DNS

This is where many administrators get confused. Unlike forward DNS records that you manage through your domain registrar or DNS provider (see our DNS records explained guide for details on A, MX, TXT, and other record types), PTR records are controlled by whoever owns the IP address block.

Who Controls Your PTR Record

The authority chain for reverse DNS follows IP address allocation, not domain ownership:

• Dedicated server or colocation: Your hosting provider controls the PTR record. Submit a request through their control panel or support ticket.
• VPS provider: Most VPS providers (DigitalOcean, Vultr, Linode, Hetzner) let you set PTR records directly in their dashboard.
• Business ISP: Contact your ISP and request a PTR record for your static IP.
• Residential ISP: Most residential ISPs will not set custom PTR records. The IP typically resolves to a generic hostname like pool-203-0-113-25.res.example.net.

Cloud Provider Processes

AWS: For EC2 Elastic IPs, submit a reverse DNS request through the AWS Support Center or use the ec2:ModifyAddressAttribute API. You must first set a forward DNS A record for the desired hostname, and AWS verifies it before publishing the PTR.

Azure: Configure PTR records in Azure DNS by creating a reverse DNS zone for your IP range. For Azure-assigned public IPs, set the ReverseFqdn property on the Public IP resource.

Google Cloud: Set the PTR record by updating the instance’s metadata or using the gcloud compute instances add-metadata command. GCP requires the forward record to exist and match.

What the PTR Record Should Contain

Your PTR record should point to a fully qualified domain name (FQDN) that you control and that resolves back to the same IP. For a mail server, this is typically your mail hostname:

203.0.113.25  →  PTR  →  mail.example.com
mail.example.com  →  A  →  203.0.113.25

Avoid pointing PTR records to bare domains, CDN hostnames, or anything that does not resolve back to the original IP. The forward and reverse records must agree.

Forward-Confirmed Reverse DNS (FCrDNS)

Forward-confirmed reverse DNS (sometimes called full-circle reverse DNS) is the verification that a reverse DNS lookup and a subsequent forward DNS lookup return consistent results. Specifically:

1. Start with IP 203.0.113.25.
2. Reverse lookup returns mail.example.com.
3. Forward lookup of mail.example.com returns 203.0.113.25.

If both directions match, you have FCrDNS. If the forward lookup returns a different IP, or the hostname does not resolve at all, FCrDNS fails.

Why Email Providers Care About FCrDNS

A PTR record alone can contain any hostname. There is no built-in validation at the DNS level that the PTR value is legitimate. A spammer could theoretically get their hosting provider to set a PTR of mail.bigbank.com even though they have no relationship to that domain.

FCrDNS closes this loophole. By verifying the forward record also matches, the receiving server confirms that the domain owner actually controls the IP address. This is why Google, Microsoft, and Yahoo all check FCrDNS as part of their spam filtering heuristics.

How to Verify Your FCrDNS

Run these two commands and confirm the results match:

# Step 1: Reverse lookup
$ dig -x 203.0.113.25 +short
mail.example.com.

# Step 2: Forward lookup
$ dig mail.example.com A +short
203.0.113.25

If both outputs are consistent, your FCrDNS is correctly configured. If either lookup fails or returns mismatched values, you need to update your DNS records or contact your IP provider.

Common Reverse DNS Problems

Frequently Asked Questions