domaindetails.com
Knowledge Base/Technical Guides/How Reverse DNS Lookup Works: PTR Records Explained (2025)
Technical Guides

How Reverse DNS Lookup Works: PTR Records Explained (2025)

Understand reverse DNS lookups, PTR records, why they matter for email deliverability, and how to configure them with hosting providers.

15 min
Published 2025-12-01
Updated 2025-12-01
By DomainDetails Team

Quick Answer

Reverse DNS (rDNS) is the process of looking up a domain name from an IP address, the opposite of regular DNS which resolves domain names to IP addresses. PTR (Pointer) records are the DNS record type that enables reverse DNS lookups. These records are critical for email deliverability because major email providers like Gmail, Yahoo, and Microsoft require sending servers to have valid PTR records. As of February 2024, Google and Yahoo mandate that all email senders pass Forward-Confirmed reverse DNS (FCrDNS) checks, making proper PTR configuration essential for anyone running mail servers.

Table of Contents

What Is Reverse DNS?

Reverse DNS (rDNS) is a DNS query that resolves an IP address to a domain name. This is the opposite of forward DNS, which resolves domain names to IP addresses.

Forward vs. Reverse DNS

Lookup Type Input Output Record Type
Forward DNS mail.example.com 192.0.2.25 A record
Reverse DNS 192.0.2.25 mail.example.com PTR record

Why Reverse DNS Exists

Reverse DNS serves several purposes:

  1. Email Authentication: Verifying that mail servers are who they claim to be
  2. Logging and Analytics: Converting IP addresses in logs to readable hostnames
  3. Network Troubleshooting: Identifying devices and servers by their names
  4. Security Auditing: Tracking the origin of network connections
  5. Anti-Spam Filtering: Validating legitimate email senders

The History of Reverse DNS

The reverse DNS system was established in the early days of the internet through RFC 1035 (1987). The now-obsolete "inverse query" (IQUERY) mechanism was originally specified but never achieved widespread use and was permanently retired in 2002. Today, all reverse DNS lookups use the in-addr.arpa domain for IPv4 and ip6.arpa for IPv6.

How PTR Records Work

PTR (Pointer) records are the DNS record type that enables reverse DNS lookups.

PTR Record Structure

A PTR record maps a reversed IP address (in a special format) to a hostname:

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

Breaking down this record:

Component Value Description
Name 25.2.0.192.in-addr.arpa. Reversed IP in special domain
TTL 3600 Time to live (1 hour)
Class IN Internet class
Type PTR Pointer record
Value mail.example.com. The hostname

The Reverse Lookup Process

When a receiving mail server wants to verify the sender's IP:

  1. Receive connection: Mail server sees connection from 192.0.2.25
  2. Construct query: Reverses IP and appends .in-addr.arpa: 25.2.0.192.in-addr.arpa
  3. Query DNS: Asks DNS servers for PTR record at that name
  4. Receive response: Gets mail.example.com as the answer
  5. Verify (FCrDNS): Looks up A record for mail.example.com to confirm it returns 192.0.2.25

IPv4 vs. IPv6 PTR Records

PTR records work differently for IPv4 and IPv6:

IPv4 Example:

  • IP Address: 192.0.2.25
  • PTR Name: 25.2.0.192.in-addr.arpa
  • Total labels: 6

IPv6 Example:

  • IP Address: 2001:db8::567:89ab
  • Expanded: 2001:0db8:0000:0000:0000:0000:0567:89ab
  • PTR Name: b.a.9.8.7.6.5.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
  • Total labels: 34 (32 hex digits + ip6 + arpa)

The IN-ADDR.ARPA and IP6.ARPA Domains

The reverse DNS system uses special domains managed by IANA (Internet Assigned Numbers Authority).

IN-ADDR.ARPA for IPv4

The .in-addr.arpa domain contains all IPv4 reverse DNS zones. The address is reversed because DNS is hierarchical from right to left, matching IP address allocation hierarchy.

How IP reversal works:

IP Address:    192.0.2.25
Reversed:      25.2.0.192
Full PTR name: 25.2.0.192.in-addr.arpa

Zone delegation:

  • IANA delegates /8 blocks (first octet) to Regional Internet Registries (RIRs)
  • RIRs delegate smaller blocks to ISPs and organizations
  • ISPs may delegate to customers or manage PTR records for them

Example zone hierarchy:

                    arpa.
                      |
                  in-addr.
                      |
                    192.        <- IANA delegates to RIR
                      |
                    0.192.      <- RIR delegates to ISP
                      |
                  2.0.192.      <- ISP manages or delegates

IP6.ARPA for IPv6

The .ip6.arpa domain handles IPv6 reverse DNS. Each hexadecimal digit of the expanded IPv6 address becomes a label.

IPv6 reversal process:

  1. Expand the IPv6 address (no shorthand)
  2. Remove colons
  3. Reverse all 32 hex digits
  4. Separate with dots
  5. Append .ip6.arpa

Example:

IPv6: 2001:db8::1
Expanded: 2001:0db8:0000:0000:0000:0000:0000:0001
No colons: 20010db8000000000000000000000001
Reversed: 100000000000000000000000008bd0102
With dots: 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
Full 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

Who Controls Reverse DNS Zones?

Unlike forward DNS where you control your domain, reverse DNS zones are controlled by whoever owns the IP address block:

IP Owner Reverse DNS Control
ISP Usually controls PTR for residential IPs
Cloud Provider Provides interface or API to set PTR
Dedicated Server Host Often allows PTR configuration
Colocation Customer May have delegated control
Enterprise (owns IPs) Full control of reverse zone

Forward-Confirmed Reverse DNS (FCrDNS)

FCrDNS is a verification method that confirms both forward and reverse DNS match.

How FCrDNS Works

FCrDNS performs two lookups and compares results:

Step 1: Reverse Lookup
Input:  192.0.2.25
Query:  25.2.0.192.in-addr.arpa PTR?
Result: mail.example.com

Step 2: Forward Lookup
Input:  mail.example.com
Query:  mail.example.com A?
Result: 192.0.2.25

Step 3: Compare
Original IP: 192.0.2.25
Forward lookup result: 192.0.2.25
Match? YES -> FCrDNS PASSED

Why FCrDNS Matters

FCrDNS creates a weak but useful form of authentication:

  1. Proves domain ownership: Only the domain owner can create the A record
  2. Proves IP control: Only the IP owner can create the PTR record
  3. Links domain to IP: Establishes a verified relationship
  4. Blocks spoofing: Spammers using compromised machines can't easily pass FCrDNS

FCrDNS Failure Scenarios

Common reasons FCrDNS checks fail:

Scenario Reverse Lookup Forward Lookup Result
No PTR record NXDOMAIN N/A FAIL
PTR mismatch other.example.com 192.0.2.25 FAIL
Missing A record mail.example.com NXDOMAIN FAIL
Different IP mail.example.com 192.0.2.99 FAIL
Correct setup mail.example.com 192.0.2.25 PASS

Why PTR Records Matter for Email

PTR records are essential for email deliverability and server reputation.

Email Server Verification

When your mail server sends an email:

  1. Receiving server sees your IP address
  2. It performs a reverse DNS lookup
  3. It checks if the PTR record matches your server's hostname
  4. Many servers verify with FCrDNS
  5. Failure at any step may cause rejection or spam classification

Impact on Email Deliverability

Without proper PTR records:

  • Gmail: May reject or spam-folder your emails
  • Yahoo: Will likely reject or mark as spam
  • Microsoft/Outlook: May reject outright
  • Corporate servers: Often configured to require valid PTR

The Email Authentication Stack

PTR records are one layer in modern email authentication:

Layer Purpose Relation to PTR
PTR/FCrDNS Verify server identity Primary function
SPF Authorize sending IPs Should include IPs with PTR
DKIM Cryptographic signing Independent of PTR
DMARC Policy enforcement Builds on SPF and DKIM

Note: PTR records alone aren't sufficient. You need SPF, DKIM, and DMARC configured alongside PTR for optimal deliverability.

2024-2025 Email Authentication Requirements

Major email providers have implemented strict requirements that affect PTR records.

Google and Yahoo Requirements (February 2024)

Starting February 1, 2024, Google and Yahoo require:

For all email senders:

  • Valid forward and reverse DNS records (PTR records)
  • SPF or DKIM email authentication
  • Spam rates below 0.3%

For bulk senders (5,000+ messages/day to Gmail):

  • SPF AND DKIM authentication
  • DMARC policy (can be p=none)
  • Valid PTR records with FCrDNS
  • One-click unsubscribe
  • Keep spam rate below 0.1%

Microsoft Outlook Requirements (April 2025)

Microsoft announced new requirements effective April 2, 2025:

  • Valid PTR records for sending IPs
  • SPF, DKIM, and DMARC authentication
  • Similar bulk sender requirements to Google/Yahoo

What This Means for You

Sender Type PTR Required? Additional Requirements
Personal email Recommended SPF recommended
Small business Yes SPF + DKIM recommended
Bulk sender (5000+/day) Mandatory SPF + DKIM + DMARC mandatory
Transactional email Yes Full authentication stack

Setting Up PTR Records

Setting up PTR records requires working with whoever controls your IP address.

Determining Who Controls Your Reverse DNS

First, identify who can set your PTR record:

  1. Check your IP ownership:

    whois 192.0.2.25
    

    Look for the organization that owns the IP block.

  2. For cloud hosting: Your cloud provider controls PTR records

  3. For dedicated servers: Usually the hosting provider

  4. For ISP connections: Your ISP controls residential/business IP PTR records

General PTR Setup Process

  1. Ensure you have a static IP: PTR records require a static (non-changing) IP
  2. Create an A record: Set up mail.yourdomain.com pointing to your IP
  3. Request PTR record: Contact IP owner to set PTR to match your A record
  4. Wait for propagation: PTR changes may take hours to propagate
  5. Verify with testing: Confirm both forward and reverse lookups work

PTR Record Naming Best Practices

The hostname in your PTR record should:

  • Match your mail server's A record exactly
  • Be a valid, resolvable hostname
  • Follow the pattern: mail.yourdomain.com or smtp.yourdomain.com
  • Not be a generic ISP hostname like 192-0-2-25.isp.net

PTR Records by Hosting Provider

Here's how to configure PTR records with major providers.

AWS (Amazon Web Services)

AWS allows PTR configuration for Elastic IP addresses.

Requirements:

  • Must have an Elastic IP (EIP) assigned
  • Must have a corresponding A record already configured
  • Must request removal of email sending limitations first

Process:

  1. Ensure your EIP has an A record pointing to it
  2. Open AWS Support Console
  3. Submit "Request to Remove Email Sending Limitations"
  4. In the request, specify your EIP and desired PTR hostname
  5. AWS verifies the A record and creates the PTR

Important: You cannot add PTR records directly in Route 53 for AWS-owned IP addresses. The process requires a support request.

For non-AWS IPs with Route 53:

  1. Create a hosted zone named after your reverse zone (e.g., 2.0.192.in-addr.arpa)
  2. Add PTR records in that zone
  3. Get the zone's NS records and provide them to your IP provider for delegation

Google Cloud Platform

Google Cloud allows PTR configuration through the Console or API.

Steps:

  1. Go to VPC Network > External IP addresses
  2. Find your static IP
  3. Click the IP address to edit
  4. Enter your desired PTR record hostname in the "DNS PTR Record" field
  5. Save changes

Requirement: The A record for the hostname must resolve to the same IP.

Microsoft Azure

Azure supports reverse DNS for public IP addresses.

Using Azure Portal:

  1. Go to your Public IP address resource
  2. Click "Configuration"
  3. Enter the "DNS name label" which sets the PTR record
  4. Save

Using Azure CLI:

az network public-ip update \
  --resource-group myResourceGroup \
  --name myPublicIP \
  --reverse-fqdn mail.example.com

Note: Azure sets PTR to [label].[region].cloudapp.azure.com by default. For custom PTR hostnames, you may need to contact Azure support.

DigitalOcean

DigitalOcean automatically creates PTR records based on your Droplet's name.

To set PTR:

  1. Rename your Droplet to the desired FQDN (e.g., mail.example.com)
  2. PTR record is automatically updated within minutes

Alternative:

  1. Go to Networking > PTR Records
  2. Select your Droplet's IP
  3. Enter the desired hostname
  4. Save

Linode (Akamai)

Linode provides PTR configuration in the Cloud Manager.

Steps:

  1. Log in to Cloud Manager
  2. Select your Linode
  3. Click the "Network" tab
  4. Find your IP address
  5. Click "Edit RDNS"
  6. Enter your desired hostname
  7. Save

OVHcloud

OVHcloud allows PTR configuration through their control panel.

Steps:

  1. Log in to OVHcloud Control Panel
  2. Go to your server or IP management
  3. Find "Reverse DNS" or "rDNS" settings
  4. Enter your desired hostname
  5. Save and wait for propagation

Hetzner

Hetzner provides reverse DNS configuration in their Robot panel.

Steps:

  1. Log in to Hetzner Robot
  2. Go to Server > IPs
  3. Click on your IP address
  4. Edit the "Reverse DNS" field
  5. Save

Vultr

Vultr handles PTR records through their customer portal.

Steps:

  1. Log in to Vultr portal
  2. Go to your server instance
  3. Click "Settings" > "IPv4"
  4. Click "Update" next to Reverse DNS
  5. Enter your hostname
  6. Save

Verifying PTR Record Configuration

After setting up PTR records, verify they're working correctly.

Command Line Tools

Using dig (Linux/Mac):

# Reverse lookup for IPv4
dig -x 192.0.2.25

# Or explicitly query PTR
dig 25.2.0.192.in-addr.arpa PTR

# For IPv6
dig -x 2001:db8::1

Using nslookup (Windows/Linux/Mac):

nslookup 192.0.2.25

# Or specify type
nslookup -type=PTR 25.2.0.192.in-addr.arpa

Using host (Linux/Mac):

host 192.0.2.25
# Output: 25.2.0.192.in-addr.arpa domain name pointer mail.example.com.

Verifying FCrDNS

Check that forward and reverse match:

# Step 1: Get PTR record
dig -x 192.0.2.25 +short
# Output: mail.example.com.

# Step 2: Verify A record matches
dig mail.example.com A +short
# Output: 192.0.2.25

# If both IPs match, FCrDNS passes

Online Testing Tools

Several online tools can verify your PTR setup:

Email Deliverability Tests

Send test emails to verify deliverability:

  1. mail-tester.com: Get a unique address, send an email, receive detailed report
  2. Check headers: Examine received email headers for authentication results
  3. Gmail Postmaster Tools: Monitor ongoing deliverability metrics

Common PTR Record Issues

Troubleshooting common problems with reverse DNS.

Issue: No PTR Record Found

Symptoms:

  • dig -x returns NXDOMAIN
  • Email rejected with "no reverse DNS" error

Causes:

  • PTR record never created
  • Wrong IP address configured
  • Propagation not complete

Solutions:

  1. Contact your IP provider to create the PTR record
  2. Verify the correct IP address
  3. Wait 24-48 hours for propagation
  4. Check with different DNS servers

Issue: PTR Doesn't Match A Record (FCrDNS Failure)

Symptoms:

  • Reverse lookup returns wrong hostname
  • Forward lookup of that hostname returns different IP

Causes:

  • PTR hostname typo
  • A record not configured
  • A record points to different IP

Solutions:

  1. Verify A record exists: dig mail.example.com A
  2. Ensure PTR hostname exactly matches
  3. Update either record to match
  4. Wait for TTL to expire on both records

Issue: Generic ISP PTR Record

Symptoms:

  • PTR returns something like 192-0-2-25.isp.net
  • Email servers reject as "generic reverse DNS"

Causes:

  • Using ISP's default PTR
  • Haven't configured custom PTR

Solutions:

  1. Request custom PTR from ISP (may require business account)
  2. Use a hosting provider that allows custom PTR
  3. Consider dedicated IP with configurable PTR

Issue: Multiple PTR Records

Symptoms:

  • Multiple hostnames returned for one IP
  • Inconsistent behavior

Explanation: Unlike A records, having multiple PTR records for a single IP is unusual and may cause issues. Most implementations return only the first record found.

Solution: Keep only one PTR record per IP address.

Issue: PTR Record Takes Too Long to Update

Causes:

  • Long TTL on old record
  • DNS caching at various levels
  • Slow provider propagation

Solutions:

  1. Check current TTL: dig -x 192.0.2.25 (look at TTL value)
  2. Wait for TTL to expire
  3. Use different DNS servers to check propagation
  4. Contact provider if more than 48 hours

PTR Records and Cloud Email Services

Understanding PTR with hosted email services.

Office 365 / Microsoft 365

Microsoft 365 handles PTR records automatically for their sending infrastructure.

Key points:

  • Microsoft manages PTR records for their email servers
  • You cannot configure custom PTR for M365 sending IPs
  • M365 servers pass FCrDNS checks using Microsoft's PTR records
  • Your SPF record should include Microsoft: include:spf.protection.outlook.com

Example outbound scenario:

  • Your email sends via M365 servers
  • Receiving server sees Microsoft IP (e.g., 40.107.x.x)
  • PTR resolves to mail-xxx.outbound.protection.outlook.com
  • This is expected and acceptable behavior

Google Workspace

Google Workspace similarly manages PTR for Gmail sending infrastructure.

Key points:

  • Google manages PTR for their mail servers
  • Emails sent through Google's servers have valid PTR
  • Configure SPF: include:_spf.google.com
  • No action needed for PTR if using Google's mail servers exclusively

Amazon SES

Amazon Simple Email Service (SES) manages PTR records for their infrastructure.

Key points:

  • SES has valid PTR records on their sending IPs
  • Include SES in SPF: include:amazonses.com
  • For dedicated IPs, you can request custom PTR through AWS support

When PTR Matters for Cloud Email

You only need to worry about PTR records when:

  1. Running your own mail server (Postfix, Exchange on-prem, etc.)
  2. Using dedicated sending IPs from services that allow PTR configuration
  3. Sending directly from your server (not relaying through a cloud service)

Best Practices

Follow these guidelines for optimal PTR record management.

1. Use Meaningful Hostnames

Good PTR hostnames indicate purpose:

mail.example.com          # Good - indicates mail server
smtp.example.com          # Good - indicates SMTP server
mx1.example.com           # Good - indicates mail exchanger
server.example.com        # Acceptable
192-0-2-25.example.com    # Bad - just the IP in a hostname

2. Ensure Perfect FCrDNS Match

Your A and PTR records must match exactly:

# A record
mail.example.com.    A    192.0.2.25

# PTR record
25.2.0.192.in-addr.arpa.    PTR    mail.example.com.

3. Use Static IPs for Mail Servers

  • Dynamic IPs make PTR management impossible
  • ISPs rarely allow custom PTR on dynamic IPs
  • Get a static IP for any mail server

4. Set Reasonable TTLs

  • Use moderate TTLs (3600-86400 seconds)
  • Lower TTLs before planned changes
  • Higher TTLs for stable configurations

5. Monitor Email Deliverability

Regularly check:

  • Gmail Postmaster Tools
  • Microsoft SNDS (Smart Network Data Services)
  • Mail-tester.com results
  • Bounce rates and rejection messages

6. Complete the Authentication Stack

PTR alone isn't enough. Also configure:

  • SPF: Authorize your sending IPs
  • DKIM: Sign your emails cryptographically
  • DMARC: Define policy for authentication failures

7. Document Your Configuration

Keep records of:

  • Which IPs have PTR configured
  • Corresponding A records and hostnames
  • Provider contact for PTR changes
  • Last verification date

Frequently Asked Questions

What is the difference between PTR and A records?

A records map domain names to IP addresses (forward DNS), while PTR records map IP addresses to domain names (reverse DNS). They are essentially opposites. A records are in your domain's zone file, while PTR records are in a special in-addr.arpa or ip6.arpa zone controlled by whoever owns the IP address.

Do I need a PTR record if I use Gmail or Office 365?

If you only send email through Gmail (Google Workspace) or Microsoft 365, you don't need to configure PTR records yourself. These services manage their own PTR records for their sending infrastructure. However, if you run your own mail server or send from dedicated IPs, you do need proper PTR configuration.

Can I set PTR records in my regular DNS hosting?

No. PTR records must be set by whoever controls the reverse DNS zone for your IP address, which is typically your ISP, hosting provider, or cloud service. You cannot add PTR records to your domain's regular DNS zone.

How long does it take for PTR records to propagate?

PTR record propagation typically takes a few minutes to a few hours, though it can take up to 48 hours in some cases. The propagation time depends on the TTL of existing records and how quickly your provider updates their DNS servers.

Why is my PTR showing a generic hostname like 192-168-1-1.isp.net?

This is the default PTR record set by your ISP for their IP address pool. To get a custom PTR hostname, you need to contact your ISP or hosting provider to request a change. Some ISPs only offer custom PTR on business accounts.

Can I have multiple PTR records for one IP address?

While technically possible, having multiple PTR records for a single IP is non-standard and can cause inconsistent behavior. Best practice is to have exactly one PTR record per IP address.

Do PTR records affect website performance or SEO?

No. PTR records are primarily used for email server identification and network troubleshooting. They don't affect website loading, performance, or search engine rankings.

What happens if my PTR record is wrong?

If your PTR record doesn't match your mail server's hostname (FCrDNS failure), your emails may be rejected or marked as spam by receiving mail servers. Major providers like Gmail and Yahoo require valid FCrDNS since February 2024.

Key Takeaways

  • PTR records enable reverse DNS: They map IP addresses back to domain names, the opposite of A records.

  • Critical for email deliverability: Major email providers require valid PTR records and FCrDNS checks since February 2024.

  • IP owner controls PTR: You cannot set PTR records in your regular DNS hosting; they must be configured by whoever owns your IP address.

  • FCrDNS requires matching records: Your PTR hostname must have an A record that points back to the same IP address.

  • Cloud email services handle PTR: If you use Google Workspace, Microsoft 365, or similar services, they manage PTR records for their infrastructure.

  • Part of a complete stack: PTR records work alongside SPF, DKIM, and DMARC for full email authentication.

Next Steps

Immediate Actions

  1. Check your current PTR: Run dig -x YOUR_IP to see your current reverse DNS
  2. Verify FCrDNS: Ensure your PTR hostname has an A record pointing back
  3. Test email deliverability: Use mail-tester.com to get a comprehensive report

Tools to Use

  • DomainDetails.com: Look up domain DNS records and WHOIS information
  • MXToolbox: Comprehensive email and DNS testing tools
  • Mail-Tester: Test email deliverability and authentication
  • Google Postmaster Tools: Monitor Gmail deliverability

Research Sources