Reverse DNS Explained: PTR Records, in-addr.arpa, and Why It Matters

Reverse DNS is one of those concepts that practitioners use every day — in log analysis, email deliverability, and network troubleshooting — but is rarely explained clearly. This guide covers how PTR records work, how in-addr.arpa and ip6.arpa zones are structured, and why getting reverse DNS right matters in production environments.

Forward DNS vs Reverse DNS

Standard (forward) DNS resolves a hostname to an IP address: you query for mail.example.com and get back 203.0.113.10. This is an A record (IPv4) or AAAA record (IPv6).

Reverse DNS does the opposite: given an IP address, it returns the hostname associated with it. The DNS record type for this is a PTR record (pointer record). The query looks like this:

# Forward lookup dig A mail.example.com ;; ANSWER SECTION: ;; mail.example.com.   300   IN   A   203.0.113.10 # Reverse lookup dig PTR 10.113.0.203.in-addr.arpa ;; ANSWER SECTION: ;; 10.113.0.203.in-addr.arpa.  300  IN  PTR  mail.example.com.

The in-addr.arpa Zone

DNS lookups always go from right to left in the hierarchy: .com → example → mail. IP addresses, however, are written left to right with the most significant octet first. To make IP addresses work in the DNS hierarchy, reverse DNS reverses the octets and appends the special domain in-addr.arpa.

For the IP 203.0.113.10:

1. Reverse the octets: 10.113.0.203
2. Append the zone: 10.113.0.203.in-addr.arpa
3. Query for a PTR record at that name

The in-addr.arpa zone is delegated by IANA to the RIRs, who in turn delegate sub-zones to ISPs and allocatees based on the IP blocks they assign. When an ISP gives you a block like 203.0.113.0/24, they also delegate the corresponding 113.0.203.in-addr.arpa zone to you — meaning you can create PTR records for all 256 addresses in that block.

For sub-allocations (blocks smaller than a /24), ISPs use RFC 2317 CNAME delegation to let customers manage their own PTR records within a shared /24. If your provider gave you a /28, they would set up CNAMEs like 10.113.0.203.in-addr.arpa CNAME 10.0/28.113.0.203.in-addr.arpa and delegate the 0/28.113.0.203.in-addr.arpa zone to your name servers.

IPv6 Reverse DNS: ip6.arpa

IPv6 reverse DNS works the same way, but uses the ip6.arpa zone and operates on individual nibbles (4-bit hex digits) rather than octets. An IPv6 address is 128 bits — 32 hex digits. Each digit is reversed individually and .ip6.arpa is appended.

For 2001:db8::1 (expanded: 2001:0db8:0000:0000:0000:0000:0000:0001):

# Expanded, no colons: 20010db8000000000000000000000001 # Reversed nibble by nibble, dots inserted: 1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.8.b.d.0.1.0.0.2.ip6.arpa # Query: dig PTR 1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.8.b.d.0.1.0.0.2.ip6.arpa

Most DNS management tools handle this expansion automatically. You provide the IPv6 address and the PTR value; the tool generates the correct ip6.arpa name.

Why Reverse DNS Matters

Email Deliverability (FCrDNS)

This is where missing PTR records cause the most immediate operational pain. Mail servers perform Forward-Confirmed Reverse DNS (FCrDNS) as an anti-spam check:

1. Receiving server looks up the PTR record for the connecting IP address.
2. It then performs a forward lookup (A/AAAA) on the returned hostname.
3. If the forward lookup resolves back to the same IP, the check passes.

If the PTR record does not exist, or if the forward lookup does not confirm the IP, many mail servers will reject the connection outright, or heavily weight it as spam. Major mail providers (Gmail, Microsoft 365) all perform this check. A correctly configured mail server needs:

• A PTR record from the sending IP pointing to the mail server's hostname
• An A record for that hostname pointing back to the same IP
• The hostname in the PTR record matching the EHLO/HELO string presented by the MTA

Security Logging and Incident Response

Network devices and security tools log IP addresses. When you review firewall logs, IDS alerts, or NetFlow data, reverse DNS lookups annotate raw IPs with hostnames — turning 54.230.12.88 into server-54-230-12-88.fra6.r.cloudfront.net, which immediately identifies the traffic as CloudFront rather than an unknown external host.

This is why SIEM systems and threat intelligence platforms always attempt PTR lookups as an enrichment step. However, PTR records are set by the IP owner — an attacker controlling a server can set their PTR to google.com. Forward-confirming the PTR is essential before trusting it for security decisions.

Network Troubleshooting Tools

Tools like traceroute, mtr, and ping all perform reverse DNS lookups on each hop IP by default. A clean set of PTR records on your WAN infrastructure makes traceroute output immediately meaningful — you can see which carrier, which PoP, and which interface each hop belongs to.

# traceroute output with PTR records configured: 3   12.34ms   ae-1.r00.londen12.uk.bb.gin.ntt.net (129.250.2.98) 4   13.21ms   ae-3.r20.amstnl02.nl.bb.gin.ntt.net (129.250.3.144) # vs. traceroute output without PTR records: 3   12.34ms   129.250.2.98 4   13.21ms   129.250.3.144

Why an IP May Have No PTR Record

Not every IP has a PTR record, and there are several legitimate reasons:

• The block owner has not configured it. Many cloud instance IPs have no PTR by default unless the operator sets one. AWS, GCP, and Azure all let you assign a custom PTR to an Elastic IP / static IP, but it is opt-in.
• Dynamic IP pools. Consumer broadband ISPs typically assign PTRs automatically (e.g., pool-72-84-188-25.rcmdva.fios.verizon.net), but some do not, and the hostname reveals it is a residential dynamic address.
• Delegation gap. The IP owner was not given DNS delegation for their block by the upstream provider, or failed to configure it. This is common with smaller ISPs.
• IPv6 gaps. IPv6 PTR coverage is lower than IPv4 in practice because many operators focus on IPv4 and neglect to set up IPv6 reverse zones.

Use the Reverse DNS Lookup tool to check PTR records for any IP instantly. It also performs the forward-confirm step so you can verify FCrDNS compliance for your mail server IPs. For related address-space work, the Subnet Calculator can help you identify the IP block boundary that determines which in-addr.arpa zone delegation you need to request.

Setting Up PTR Records

The process depends on who controls the IP block:

• Dedicated server / colocation: Request PTR delegation from your provider, or ask them to set specific PTR records if you do not need full zone control.
• Cloud (AWS): Allocate an Elastic IP, assign it to the instance, then use the "Edit reverse DNS" button in the EC2 console (or submit a PTR update request via support for IPs not in the self-service zone).
• Cloud (GCP): Assign a static external IP and create a PTR record via the Cloud DNS API or the console under the IP address resource.
• Your own BGP-announced block: Set up an in-addr.arpa zone in your authoritative DNS and notify your upstream to delegate it. ARIN, RIPE, APNIC and the other RIRs provide delegation forms in their member portals.

PTR records typically have a low TTL (300–900 seconds) since they are often tied to specific servers that may be reassigned. Once configured correctly, verify both the PTR and the forward-confirm using the Reverse DNS Lookup tool before going live.