What Is a PTR Record? Understanding Reverse DNS

What Is a PTR Record?

A PTR record (Pointer record) maps an IP address to a hostname — the reverse of what A records do. While A records answer "What IP does this domain have?", PTR records answer "What domain name is associated with this IP?"

The Basics

• PTR stands for "Pointer"
• Enables reverse DNS lookups (IP → hostname)
• Stored in special reverse DNS zones
• Managed by the IP address owner (usually ISP or hosting provider)
• Critical for email server reputation

Forward vs Reverse DNS

Example PTR Record

; IPv4 reverse DNS
25.100.51.198.in-addr.arpa.    3600    IN    PTR    mail.example.com.

; IPv6 reverse DNS
8.b.d.0.1.0.0.2.ip6.arpa.      3600    IN    PTR    mail.example.com.

How PTR Records Work

The in-addr.arpa Zone

IPv4 reverse DNS uses a special domain: in-addr.arpa

The IP address is reversed and appended to this domain:

IPv6 Reverse DNS

IPv6 uses ip6.arpa with each hex digit separated:

The Reverse DNS Hierarchy

Performing a Reverse Lookup

# Using dig
dig -x 198.51.100.25

# Using host
host 198.51.100.25

# Using nslookup
nslookup 198.51.100.25

Why PTR Records Matter

Email Deliverability

This is the most common reason MSPs deal with PTR records. Mail servers check PTR records to:

1. Verify sender identity — IP should resolve to a legitimate hostname
2. Match forward DNS — PTR hostname should resolve back to the same IP
3. Check for spam characteristics — Generic PTR = likely spam

What mail servers want to see:

What triggers spam filters:

Security and Logging

PTR records help with:

• Log analysis — See hostnames instead of IPs
• Intrusion detection — Identify connecting hosts
• Access control — Some services require valid PTR

Network Troubleshooting

# traceroute shows hostnames with PTR records
traceroute google.com

# Hop 5: router.isp.net [198.51.100.1]  vs  198.51.100.1

Setting Up PTR Records

Who Controls PTR Records?

Unlike forward DNS where you control your domain's records, PTR records are controlled by whoever owns the IP address block:

Common Provider Instructions

AWS EC2:

1. Request Elastic IP
2. Create reverse DNS record via AWS Support or in console
3. Provide the hostname and IP

Azure:

1. Go to Public IP resource
2. Set "DNS name label"
3. PTR automatically created as: label.region.cloudapp.azure.com

DigitalOcean:

1. Set Droplet name to desired PTR value
2. PTR automatically matches Droplet name

Most Hosting Providers:

1. Open support ticket
2. Provide: IP address, desired hostname
3. Provider creates PTR record

Verifying PTR Setup

# Check PTR record
dig -x 198.51.100.25

# Verify forward/reverse match
dig mail.example.com A
dig -x 198.51.100.25

# Both should show mail.example.com ↔ 198.51.100.25

Forward-Confirmed Reverse DNS (FCrDNS)

For best email deliverability, ensure:

1. PTR exists — IP resolves to a hostname
2. Forward matches — That hostname resolves back to the IP
3. Hostname is meaningful — Not generic like "198-51-100-25.static.isp.net"

# Test FCrDNS
IP="198.51.100.25"
PTR=$(dig -x $IP +short)
FORWARD=$(dig $PTR A +short)

echo "IP: $IP"
echo "PTR: $PTR"
echo "Forward: $FORWARD"

# Should show same IP

Best Practices for MSPs

1. Always Set PTR for Mail Servers

Any server sending email must have:

• PTR record matching a meaningful hostname
• A record for that hostname pointing back to the IP
• SPF record authorizing the IP

2. Use Meaningful Hostnames

Good PTR values:

• mail.example.com
• smtp.example.com
• outbound.example.com

Poor PTR values:

• 198-51-100-25.example.com
• server1.example.com (too generic)
• No PTR at all

3. Check PTR During Server Provisioning

Add to your server setup checklist:

1. Request/configure PTR record
2. Wait for propagation (can take 24-48 hours)
3. Verify with dig -x
4. Verify FCrDNS match

4. Monitor PTR Records

Include in your monitoring:

• PTR record exists
• Forward/reverse match
• Hostname hasn't changed unexpectedly

5. Document PTR Configurations

Track:

• IP address
• Expected PTR value
• Who controls it (ISP, cloud provider, colo)
• Contact for changes

6. Plan for IP Changes

When migrating servers:

1. Provision new IP and set PTR first
2. Update forward DNS (lower TTL beforehand)
3. Migrate services
4. Remove old PTR (optional, usually handled by provider)

Frequently Asked Questions

Why can't I set PTR records in my DNS provider?

PTR records must be set by whoever controls the IP address block. This is usually your ISP, hosting provider, or cloud provider — not your DNS provider.

How long does PTR propagation take?

Typically 24-48 hours, but can vary by provider. Some cloud providers update within minutes.

Do I need PTR for every server?

PTR is essential for:

• Mail servers (required for deliverability)
• Any server that initiates outbound connections where the receiving end checks reverse DNS

Less critical for:

• Web servers (browsers don't check PTR)
• Internal servers

What if my ISP won't set a custom PTR?

Options:

• Use a different ISP/hosting provider
• Use a third-party email relay service
• For email specifically, use a service like SendGrid, Mailgun, or Microsoft 365

Can one IP have multiple PTR records?

Technically yes, but it's uncommon and not recommended. Most services expect a single PTR record per IP.

Does PTR affect SEO or website performance?

No. Browsers and search engines don't use PTR records. PTR primarily matters for email and network administration.

Get Started with Unified DNS

While PTR records are managed separately from your domain DNS, Unified DNS lets you view, modify, audit, and backup all your DNS configurations — with automated backups and Hudu syncing to keep your documentation complete, including notes on the PTR records your mail servers need.

Unified DNS is live — try it free for a month with code FREETRIAL2026 at billing setup. No commitment. Or request a demo for a walkthrough.