What Is a PTR Record

A PTR (Pointer) record provides reverse DNS (rDNS) lookup, mapping an IP address back to a domain name. While A and AAAA records convert domain names to IP addresses, PTR records do the opposite — enabling you to find which domain is associated with a given IP. PTR records are a fundamental part of DNS and play a critical role in email deliverability, security logging, and network operations.

How PTR Records Work

PTR records use special reverse lookup zones within the DNS hierarchy. Instead of looking up a name to find an address, you query a specially constructed name under the .arpa top-level domain.

IPv4: IP addresses are reversed and placed under in-addr.arpa

1.2.0.192.in-addr.arpa.    3600    PTR    mail.example.com.

This maps 192.0.2.1 to mail.example.com

IPv6: Each nibble is reversed under ip6.arpa

4.3.3.7.0.7.3.e.2.a.8.0.0.0.0.0.0.0.0.0.3.a.5.8.8.b.d.0.1.0.0.2.ip6.arpa.    3600    PTR    mail.example.com.

Understanding Reverse DNS Zones

Reverse DNS zones are structured around IP address blocks. The zone name is derived from the network portion of the IP range:

IPv4 Reverse Zones

For a /24 block like 192.0.2.0/24, the reverse zone is:

2.0.192.in-addr.arpa

For larger blocks, the zone covers fewer octets:

# /16 block (192.0.0.0/16)
0.192.in-addr.arpa
 
# /8 block (10.0.0.0/8)
10.in-addr.arpa

For blocks smaller than /24 (classless delegation), the parent zone uses CNAME records or NS records to delegate individual IPs or ranges to the appropriate nameserver. RFC 2317 defines this classless in-addr.arpa delegation method.

IPv6 Reverse Zones

IPv6 reverse zones work at the nibble boundary (every 4 bits). A /48 allocation like 2001:db8:abcd::/48 results in:

d.c.b.a.8.b.d.0.1.0.0.2.ip6.arpa

Each nibble becomes a label in the reverse zone name, read from right to left.

Why PTR Records Matter

Email Deliverability

Mail servers check PTR records to verify sender legitimacy. This is one of the most important uses of reverse DNS:

• Many mail servers reject email from IPs without valid PTR records
• The PTR should match the server's HELO/EHLO hostname
• Mismatched or missing PTR records often result in spam filtering
• Major providers like Gmail, Outlook, and Yahoo all check PTR records

Together with SPF, DKIM, and DMARC, PTR records form the foundation of email authentication. While SPF and DKIM use TXT records in forward DNS, PTR records verify the sender's IP at the network level.

Security and Logging

• Firewall logs can show hostnames instead of raw IPs
• Security tools use rDNS for threat analysis and enrichment
• Network troubleshooting benefits from readable hostnames
• Intrusion detection systems correlate IP addresses with known domains

Service Verification

• SSH connections can display the connecting hostname
• Web servers can log visitor hostnames (though this adds latency)
• Network monitoring tools provide clearer reports
• Anti-spam systems use rDNS as one signal among many

Forward-Confirmed Reverse DNS (FCrDNS)

FCrDNS is the gold standard for PTR configuration. It means:

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

This two-way match confirms that the owner of the domain and the owner of the IP address agree on the relationship. Many security and anti-spam systems specifically check for FCrDNS, not just the presence of a PTR record.

# Step 1: Look up the PTR record for an IP
dig -x 192.0.2.25 +short
# Result: mail.example.com.
 
# Step 2: Look up the A record for the hostname
dig A mail.example.com +short
# Result: 192.0.2.25
 
# Both match — FCrDNS is confirmed

If the forward lookup returns a different IP than the one you started with, FCrDNS fails. This can happen when PTR records point to generic ISP hostnames that don't resolve back to the original IP.

FCrDNS verification is critical for email servers. If your mail server's PTR record points to mail.example.com but mail.example.com resolves to a different IP, most receiving mail servers will treat your messages with suspicion or reject them outright.

Common Use Cases

Mail Server Configuration

; Forward record
mail.example.com.              3600    A      192.0.2.25
 
; Reverse record (in reverse zone)
25.2.0.192.in-addr.arpa.      3600    PTR    mail.example.com.

Web Server

; Forward record
www.example.com.               3600    A      192.0.2.80
 
; Reverse record
80.2.0.192.in-addr.arpa.      3600    PTR    www.example.com.

Multiple Services on One IP

When one IP hosts multiple services, the PTR typically points to the primary hostname or a generic server name:

25.2.0.192.in-addr.arpa.      3600    PTR    server1.example.com.

Each IP address should have only one PTR record. While technically multiple PTR records per IP are allowed by the DNS specification, it creates ambiguity and many applications only use the first result. Choose the most representative hostname for the IP.

Record Format

Adding a PTR Record

Important Note

PTR records are typically managed by whoever controls the IP address block:

• Cloud providers (AWS, GCP, Azure) - Configure via their console
• Hosting providers - Use their control panel or contact support
• ISPs - Contact your ISP for PTR record changes
• Own IP space - Manage in your reverse DNS zone

If DNScale manages your reverse zone, you can add PTR records directly.

Using the Dashboard

1. Navigate to your reverse zone (e.g., 2.0.192.in-addr.arpa)
2. Click Add Record
3. Configure the record:
   • Name: Enter the last octet(s) of the IP (e.g., 1 for 192.0.2.1)
   • Type: Select PTR
   • Value: Enter the fully qualified domain name
   • TTL: Set the cache duration (default: 3600)
4. Click Create Record

Using the API

Create a PTR record:

curl -X POST "https://api.dnscale.eu/v1/zones/{reverse_zone_id}/records" \
  -H "Authorization: Bearer YOUR_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "name": "1",
    "type": "PTR",
    "content": "mail.example.com",
    "ttl": 3600
  }'

Note: The zone must be a reverse zone (e.g., 2.0.192.in-addr.arpa).

API Response:

{
  "status": "success",
  "data": {
    "message": "Record created successfully",
    "record": {
      "id": "encoded-record-id",
      "name": "1.2.0.192.in-addr.arpa.",
      "type": "PTR",
      "content": "mail.example.com.",
      "ttl": 3600,
      "disabled": false
    }
  }
}

IP Address to PTR Name Conversion

IPv4

Reverse the octets and append .in-addr.arpa:

192.0.2.1 → 1.2.0.192.in-addr.arpa

IPv6

Expand fully, reverse each nibble, add dots, append .ip6.arpa:

2001:db8::1
= 2001:0db8:0000:0000:0000:0000:0000:0001
→ 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

IPv6 reverse DNS is particularly challenging because of the sheer number of addresses. For a /48 allocation, you have 2^80 possible addresses — far too many to create individual PTR records. Common approaches include:

• Creating PTR records only for actively used addresses
• Using wildcard PTR records (supported by some DNS servers)
• Generating PTR records dynamically based on the IP address itself

Testing PTR Records

# Query PTR for IPv4
dig -x 192.0.2.1
 
# Query PTR for IPv6
dig -x 2001:db8::1
 
# Using specific nameserver
dig -x 192.0.2.1 @ns1.dnscale.eu
 
# Short output
dig -x 192.0.2.1 +short
 
# Full FCrDNS verification in one go
PTR=$(dig -x 192.0.2.25 +short) && dig A $PTR +short

Best Practices

1. Match forward and reverse - PTR should resolve to a hostname that resolves back to the same IP (forward-confirmed reverse DNS)

2. Use FQDNs - Always use fully qualified domain names with trailing dot

3. One PTR per IP - Unlike A records, each IP should have only one PTR record

4. Mail server PTR is critical - Email deliverability depends heavily on proper PTR configuration

5. PTR must match HELO - For mail servers, ensure PTR matches the SMTP HELO/EHLO hostname

6. Keep TTL reasonable - Use 3600 seconds (1 hour) or higher; PTR records rarely change

7. Don't use generic names - Avoid ISP default names like 192-0-2-1.isp.example.com for mail servers

Common Issues

Related Record Types

• A - Forward lookup (domain to IPv4)
• AAAA - Forward lookup (domain to IPv6)
• MX - Mail server configuration
• TXT - SPF, DKIM, and DMARC for email authentication
• NS - Nameserver delegation for reverse zones
• SOA - Zone authority for reverse zones
• DNS Record Types - Overview of all DNS record types

Conclusion

PTR records are essential for email deliverability, security logging, and network operations. The key to proper PTR configuration is forward-confirmed reverse DNS: the PTR hostname must resolve back to the same IP address. While PTR records are often managed by IP address providers rather than DNS hosting providers, understanding how reverse DNS zones work helps you ensure proper configuration and troubleshoot delivery issues. When you control your own IP space, DNScale can manage your reverse DNS zones alongside your forward zones, keeping both sides of the lookup consistent.