DNS PTR Record Explained — Reverse DNS Lookups

Every DNS lookup you are familiar with is probably a forward lookup — you type a domain name like example.com and get back an IP address. A PTR (Pointer) record does the opposite. It maps an IP address back to a hostname, enabling what is known as a reverse DNS lookup (rDNS).

Reverse DNS is a critical piece of internet infrastructure. Mail servers rely on it to filter spam, security teams use it to identify hosts in log files, and network operators depend on it for troubleshooting. If you run any internet-facing server, understanding PTR records is essential.

How Forward DNS Differs from Reverse DNS

In forward DNS, A records map a domain name to an IPv4 address, and AAAA records map a domain name to an IPv6 address. PTR records reverse that relationship:

Forward and reverse DNS are maintained independently. Creating an A record does not automatically create a matching PTR record. You must configure both sides separately, often with different providers.

Tip: Think of forward DNS as a phone book (name to number) and reverse DNS as caller ID (number to name).

How Reverse DNS Zones Work

Reverse DNS uses special domain namespaces managed under the .arpa top-level domain. The IP address is reversed and appended to the appropriate .arpa zone.

IPv4: in-addr.arpa

For IPv4, you reverse the four octets of the address and append .in-addr.arpa. For the IP address 192.0.2.25:

25.2.0.192.in-addr.arpa.    3600    IN    PTR    mail.example.com.

The reverse zone for the /24 network 192.0.2.0/24 would be 2.0.192.in-addr.arpa. You can query this with dig:

# Reverse lookup for an IPv4 address
dig -x 192.0.2.25
 
# Equivalent manual query against the in-addr.arpa zone
dig PTR 25.2.0.192.in-addr.arpa

IPv6: ip6.arpa

IPv6 reverse DNS works the same way but uses individual nibbles (4-bit hex digits) instead of octets. Each nibble is separated by a dot and the whole string is reversed under ip6.arpa.

For the address 2001:0db8:85a3:0000:0000:8a2e:0370:7334:

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.    3600    IN    PTR    mail.example.com.

That is 32 nibbles separated by dots — the full expanded form of the IPv6 address. Query it with:

# Reverse lookup for an IPv6 address
dig -x 2001:db8:85a3::8a2e:370:7334

The dig -x command handles the nibble expansion and zone construction automatically.

Tip: You never need to manually expand IPv6 nibbles for queries. The -x flag in dig does it for you.

Why Reverse DNS Matters

Email Deliverability

This is the single most important reason to configure PTR records. Major email providers — Gmail, Outlook, Yahoo — check the reverse DNS of connecting mail servers. Their logic is straightforward:

1. An SMTP connection arrives from IP 192.0.2.25
2. The receiving server performs a reverse lookup on 192.0.2.25
3. If no PTR record exists, or the PTR hostname does not resolve back to 192.0.2.25, the email is flagged or rejected

Without valid reverse DNS, your emails will likely land in spam or be blocked entirely. PTR records work alongside SPF, DKIM, and DMARC to establish sender legitimacy. For any MX record you configure, the IP address it resolves to should have a matching PTR.

Security and Threat Analysis

Firewalls, intrusion detection systems, and SIEM platforms perform reverse lookups to enrich log data. An IP address like 198.51.100.47 in a log is hard to contextualize; the hostname scanner.malicious-actor.example is immediately informative.

Network Troubleshooting

Tools like traceroute and mtr use reverse DNS to display hostnames at each hop. This makes it far easier to identify which network or provider is causing latency or packet loss. Without PTR records on router interfaces, you see only raw IP addresses.

Who Manages PTR Records

This is where reverse DNS differs most from forward DNS. You typically do not manage PTR records in the same place you manage your A or AAAA records.

The entity that holds the IP allocation from a Regional Internet Registry (RIR) controls the reverse zone. If you lease a server from a hosting provider, they control the reverse zone for that IP range. You must ask them to set the PTR record for your IP.

How to Request rDNS from Your Provider

Most providers offer a self-service option:

1. Cloud providers: Look for "Reverse DNS" or "PTR record" settings in the networking section of your instance or elastic IP configuration
2. Hosting providers: Check your server control panel for an rDNS or PTR option
3. ISPs: Open a support ticket requesting a PTR record for your static IP

When making the request, specify:

• The IP address (e.g., 192.0.2.25)
• The desired PTR hostname (e.g., mail.example.com)
• Confirm that the forward A record for that hostname already points to the IP

Tip: Always create the forward A/AAAA record before requesting the PTR. Providers often verify that the forward record exists.

Forward-Confirmed Reverse DNS (FCrDNS)

FCrDNS is the gold standard for reverse DNS configuration. It means:

1. The PTR record for an IP resolves to a hostname
2. That hostname's A or AAAA record resolves back to the same IP

This bidirectional confirmation proves that the domain owner and the IP owner agree on the association. Many email providers and security tools require FCrDNS for full trust.

Verifying FCrDNS with dig

# Step 1: Reverse lookup — find the hostname for the IP
dig -x 192.0.2.25 +short
# Expected output: mail.example.com.
 
# Step 2: Forward lookup — verify the hostname points back
dig A mail.example.com +short
# Expected output: 192.0.2.25
 
# If both match, you have valid FCrDNS

For IPv6:

# Step 1: Reverse lookup
dig -x 2001:db8::25 +short
# Expected output: mail.example.com.
 
# Step 2: Forward lookup
dig AAAA mail.example.com +short
# Expected output: 2001:db8::25

If either step fails or the results do not match, FCrDNS is broken.

PTR Records for Email Servers

Configuring PTR records correctly is one of the most important steps in mail server setup, right alongside configuring your MX records and SPF/DKIM/DMARC.

Requirements for Mail Server PTR

1. PTR must exist: The IP your mail server sends from must have a PTR record
2. PTR must match HELO/EHLO: The hostname in the PTR should match what your server announces in the SMTP HELO/EHLO greeting
3. Forward record must match: The PTR hostname must have an A or AAAA record pointing back to the same IP (FCrDNS)
4. Avoid generic hostnames: PTR values like host-192-0-2-25.isp.example signal a residential or unmanaged IP — mail servers distrust these

Example: Complete Mail Server DNS

; Forward DNS (managed in your DNS zone)
mail.example.com.         3600    IN    A       192.0.2.25
mail.example.com.         3600    IN    AAAA    2001:db8::25
example.com.              3600    IN    MX      10 mail.example.com.
 
; Reverse DNS (managed by your IP provider)
25.2.0.192.in-addr.arpa.  3600    IN    PTR     mail.example.com.

Testing Your Mail Server PTR

# Check PTR record
dig -x 192.0.2.25
 
# Verify FCrDNS
dig A $(dig -x 192.0.2.25 +short) +short
 
# Check MX record points to a host with valid PTR
dig MX example.com +short
# Then check PTR for each MX target's IP

IPv6 Reverse DNS: The Full Picture

IPv6 reverse DNS follows the same principles as IPv4 but is more complex because of the address length. A full IPv6 reverse record name contains 32 nibble labels.

Constructing an IPv6 PTR Name

Take the address 2001:db8:abcd:0012:0000:0000:0000:0001:

1. Expand fully: 2001:0db8:abcd:0012:0000:0000:0000:0001
2. Remove colons: 20010db8abcd001200000000000000001
3. Reverse the characters: 1000000000000000002100dcba8bd01002
4. Insert dots between each character: 1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.2.1.0.0.d.c.b.a.8.b.d.0.1.0.0.2
5. Append .ip6.arpa: 1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.2.1.0.0.d.c.b.a.8.b.d.0.1.0.0.2.ip6.arpa

Tip: Use dig -x to avoid manual nibble expansion. For programmatic generation, tools like ipv6calc or Python's ipaddress module can produce the .ip6.arpa name automatically.

IPv6 Reverse Zone Delegation

IPv6 reverse zones are typically delegated on nibble boundaries. Common delegation sizes:

If you have your own IPv6 allocation, you can host the reverse zone on your authoritative nameservers and manage PTR records directly through DNScale.

Practical dig Examples

# Basic reverse lookup
dig -x 8.8.8.8
# Returns: dns.google.
 
# Short output only
dig -x 8.8.8.8 +short
# Returns: dns.google.
 
# Query against a specific nameserver
dig -x 192.0.2.25 @ns1.dnscale.eu
 
# Reverse lookup with full answer section
dig -x 1.1.1.1 +noall +answer
# Returns: 1.1.1.1.in-addr.arpa. 1800 IN PTR one.one.one.one.
 
# IPv6 reverse lookup
dig -x 2606:4700:4700::1111 +short
# Returns: one.one.one.one.
 
# Trace the delegation path for a reverse lookup
dig -x 192.0.2.25 +trace

Common Mistakes

1. Forgetting the forward record: You set a PTR to mail.example.com but never create the matching A record. FCrDNS fails and email deliverability suffers.

2. Mismatched HELO hostname: Your mail server announces smtp.example.com in HELO but the PTR points to mail.example.com. Some receiving servers will reject this.

3. Multiple PTR records per IP: While technically allowed by the DNS protocol, having more than one PTR record per IP address causes unpredictable behavior. Stick to one PTR per IP.

4. Using the wrong provider: You try to create a PTR record in your forward DNS zone instead of with your IP provider. PTR records live in reverse zones controlled by the IP allocation holder.

5. Ignoring IPv6 PTR: You configure PTR for your IPv4 address but not for your IPv6 address. As IPv6 adoption grows, mail servers increasingly check IPv6 rDNS too.

6. Generic ISP hostnames: Leaving the default ISP-assigned PTR like host-192-0-2-25.residential.isp.example signals that the IP is not a managed mail server.

Testing and Verification Checklist

Run these commands to verify your reverse DNS setup:

# 1. Check PTR exists
dig -x YOUR_IP +short
 
# 2. Verify FCrDNS
HOSTNAME=$(dig -x YOUR_IP +short)
dig A $HOSTNAME +short
 
# 3. Confirm HELO matches PTR (connect to your own mail server)
echo "EHLO test" | nc -w5 YOUR_IP 25
 
# 4. Check from an external perspective
dig -x YOUR_IP @8.8.8.8 +short

Related Record Types

• A Record — Forward lookup: domain to IPv4 address
• AAAA Record — Forward lookup: domain to IPv6 address
• MX Record — Mail server designation, closely tied to PTR configuration
• SPF, DKIM, DMARC — Email authentication records that complement PTR
• DNS Record Types — Overview of all DNS record types
• What is DNS — Fundamentals of the Domain Name System

Conclusion

PTR records are the backbone of reverse DNS, and they play a decisive role in email deliverability, security logging, and network diagnostics. While forward DNS records like A and AAAA are managed in your DNS hosting provider, PTR records are controlled by whoever owns the IP address allocation. Always configure FCrDNS — matching forward and reverse records — and verify your setup with dig -x before putting any mail server into production.