Reverse DNS (rDNS), also known as PTR (Pointer) records, is a critical DNS configuration that maps IP addresses back to domain names—the reverse of standard forward DNS lookups. While forward DNS translates domain names like "example.com" to IP addresses, reverse DNS performs the opposite function, resolving IP addresses to hostnames. This bidirectional DNS resolution is essential for many Internet services, particularly email delivery, security protocols, and network troubleshooting.
For system administrators managing mail servers, web hosting infrastructure, or enterprise networks, proper reverse DNS configuration is not optional—it's a fundamental requirement. Many mail servers reject emails from servers without valid reverse DNS records, ISPs use rDNS for abuse tracking, and security tools rely on it for authentication and logging. This comprehensive guide covers everything from understanding reverse DNS fundamentals to configuring PTR records across different hosting environments and DNS providers.
Whether you're setting up a new mail server, troubleshooting email delivery issues, or implementing best practices for your infrastructure, this guide provides the knowledge and practical steps needed to successfully configure and maintain reverse DNS records.
Reverse DNS lookup queries DNS servers to find the hostname associated with an IP address. When configured correctly, an IP address resolves to a hostname through a PTR record, which should ideally match the forward DNS A or AAAA record for that hostname.
Forward DNS Example:
mail.example.com → A record → 192.0.2.10
Reverse DNS Example:
192.0.2.10 → PTR record → mail.example.com
Reverse DNS uses a special domain hierarchy called in-addr.arpa for IPv4 and ip6.arpa for IPv6:
IPv4 Reverse DNS: For IP address 192.0.2.10, the reverse DNS query becomes:
10.2.0.192.in-addr.arpa
The IP address is reversed, and .in-addr.arpa is appended.
IPv6 Reverse DNS: For IPv6 address 2001:db8::1, each hexadecimal digit is separated and reversed:
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
1. Email Delivery
Modern mail servers perform reverse DNS checks to combat spam:
Most mail servers verify that sending servers have valid PTR records
Absence of reverse DNS often results in email rejection or spam classification
Major email providers (Gmail, Outlook, Yahoo) require proper rDNS
SPF, DKIM, and DMARC authentication work best with matching rDNS
2. Security and Authentication
SSH connections can use reverse DNS for host verification
Intrusion detection systems use rDNS for threat analysis
Access control lists can filter based on hostnames
SSL/TLS certificate validation may reference reverse DNS
3. Logging and Troubleshooting
Log files show hostnames instead of IP addresses
Network diagnostics tools display meaningful names
Traffic analysis becomes more interpretable
Compliance and auditing requirements
4. Professional Reputation
Demonstrates proper infrastructure management
Indicates legitimate, non-temporary services
Builds trust with email recipients and service providers
Before configuring reverse DNS, ensure you have:
IP address ownership or authorization - You must control the IP address
Access to DNS control panel or hosting provider interface
Understanding of your DNS infrastructure - Know who manages your reverse DNS
Forward DNS already configured - A or AAAA records should exist first
Email server details (if applicable) - FQDN and mail server hostname
Basic DNS knowledge - Understanding of A, AAAA, MX, and PTR records
Identify who controls your reverse DNS:
Dedicated Servers / VPS:
# Find the authoritative nameserver for your IP's reverse DNS
whois 192.0.2.10 | grep -i "nameserver"
# Query reverse DNS authority
dig -x 192.0.2.10 +short
Common Scenarios:
Hosting Providers - Control panel access (cPanel, Plesk, custom)
Cloud Providers - AWS Route 53, Google Cloud DNS, Azure DNS
ISPs - Direct contact or ticketing system
Data Centers - IPMI, management portal, or support tickets
Your Own DNS Servers - Full control via BIND, PowerDNS, etc.
WHM (Web Host Manager) provides easy reverse DNS management:
https://your-server-ip:2087
Log in with root credentials.
Go to IP Functions → Edit DNS Zone
Or search for "Reverse DNS" in WHM
Select your IP address from the dropdown
Enter the fully qualified domain name (FQDN)
Click "Save"
Example Configuration:
IP Address: 192.0.2.10
PTR Record: mail.example.com
dig -x 192.0.2.10 +short
# Should return: mail.example.com.
Log into Plesk admin interface.
Go to Tools & Settings
Select DNS Settings or IP Addresses
Click on the IP address you want to configure
Enter the hostname in the PTR record field
Apply changes
Access DirectAdmin as admin user.
Navigate to IP Management
Select Reverse IP Setup
Enter your IP address
Specify the hostname
Save configuration
AWS requires submitting a request for reverse DNS configuration:
Gather required details:
Elastic IP address
Fully qualified domain name (FQDN)
Use case (usually "email server")
Go to AWS Support Center
Create a Service Limit Increase case
Select Elastic IPs and Reverse DNS
Provide:
Elastic IP address
Reverse DNS hostname
Forward DNS must already resolve to this IP
AWS typically processes requests within 1-2 business days.
dig -x <your-elastic-ip> +short
nslookup <your-elastic-ip>
# List your instances
gcloud compute instances list
# Configure reverse DNS for instance
gcloud compute instances set-reverse-dns-lookup INSTANCE_NAME \
--zone=ZONE \
--public-ptr \
--public-ptr-domain=mail.example.com
Navigate to Compute Engine → VM instances
Click on the instance
Click Edit
Under Network interfaces, expand the interface
Enter Public DNS PTR Record
Save changes
# Configure reverse DNS
az network public-ip update \
--resource-group MyResourceGroup \
--name MyPublicIP \
--reverse-fqdn mail.example.com
Navigate to Public IP addresses
Select your public IP
Go to Configuration
Enter DNS name label and Reverse FQDN
Save
Log into DigitalOcean dashboard.
Click Networking in the sidebar
Select Floating IPs or your Droplet
DigitalOcean requires support ticket submission:
Open a support ticket
Request reverse DNS configuration
Provide:
Droplet IP address
Desired PTR record hostname
Confirmation that forward DNS is configured
Log into Linode Manager
Select your Linode
Go to Remote Access tab
Under Reverse DNS, click Edit
Enter hostname
Click Save
linode-cli linodes ip-update \
--linode-id 123456 \
--address 192.0.2.10 \
--rdns mail.example.com
Log into Vultr account
Select your server instance
Click on Settings tab
Find IPv4 or IPv6 section
Click pencil icon next to IP address
Enter reverse DNS hostname
Click Set Reverse DNS
BIND is the most widely used DNS server software.
For IP address 192.0.2.10 in subnet 192.0.2.0/24:
Reverse zone name: 2.0.192.in-addr.arpa
Create zone file /etc/bind/db.2.0.192:
$TTL 86400
@ IN SOA ns1.example.com. admin.example.com. (
2024011101 ; Serial (YYYYMMDDNN)
3600 ; Refresh
1800 ; Retry
604800 ; Expire
86400 ) ; Minimum TTL
; Nameserver records
@ IN NS ns1.example.com.
@ IN NS ns2.example.com.
; PTR records
10 IN PTR mail.example.com.
20 IN PTR web.example.com.
30 IN PTR db.example.com.
Explanation:
10 represents the last octet of IP 192.0.2.10
PTR mail.example.com. maps to the hostname
Note the trailing dot after hostnames (important!)
Edit /etc/bind/named.conf.local:
zone "2.0.192.in-addr.arpa" {
type master;
file "/etc/bind/db.2.0.192";
allow-update { none; };
};
# Check named configuration
sudo named-checkconf
# Check zone file syntax
sudo named-checkzone 2.0.192.in-addr.arpa /etc/bind/db.2.0.192
# Reload BIND configuration
sudo systemctl reload bind9
# Or
sudo rndc reload
dig -x 192.0.2.10 @localhost
nslookup 192.0.2.10 localhost
For IPv6 address 2001:db8::10:
Zone name: 0.0.0.0.8.b.d.0.1.0.0.2.ip6.arpa
Create /etc/bind/db.2001:db8:::
$TTL 86400
@ IN SOA ns1.example.com. admin.example.com. (
2024011101
3600
1800
604800
86400 )
@ IN NS ns1.example.com.
@ IN NS ns2.example.com.
; PTR for 2001:db8::10
0.1.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. IN PTR mail.example.com.
zone "0.0.0.0.8.b.d.0.1.0.0.2.ip6.arpa" {
type master;
file "/etc/bind/db.2001:db8::";
};
sudo named-checkzone 0.0.0.0.8.b.d.0.1.0.0.2.ip6.arpa /etc/bind/db.2001:db8::
sudo systemctl reload bind9
dig -x 2001:db8::10
PowerDNS offers modern DNS server functionality with backend database support.
-- Add reverse zone
INSERT INTO domains (name, type) VALUES ('2.0.192.in-addr.arpa', 'NATIVE');
-- Get domain ID
SELECT id FROM domains WHERE name='2.0.192.in-addr.arpa';
-- Add PTR record
INSERT INTO records (domain_id, name, type, content, ttl)
VALUES (1, '10.2.0.192.in-addr.arpa', 'PTR', 'mail.example.com', 3600);
-- Add SOA record
INSERT INTO records (domain_id, name, type, content, ttl)
VALUES (1, '2.0.192.in-addr.arpa', 'SOA', 'ns1.example.com admin.example.com 2024011101 3600 1800 604800 86400', 86400);
-- Add NS records
INSERT INTO records (domain_id, name, type, content, ttl)
VALUES (1, '2.0.192.in-addr.arpa', 'NS', 'ns1.example.com', 3600);
# Create reverse zone
pdnsutil create-zone 2.0.192.in-addr.arpa
# Add PTR record
pdnsutil add-record 2.0.192.in-addr.arpa 10 PTR mail.example.com
# Check zone
pdnsutil check-zone 2.0.192.in-addr.arpa
# List records
pdnsutil list-zone 2.0.192.in-addr.arpa
# Basic reverse lookup
dig -x 192.0.2.10
# Short output
dig -x 192.0.2.10 +short
# Query specific nameserver
dig -x 192.0.2.10 @8.8.8.8
# Detailed output
dig -x 192.0.2.10 +trace
Expected output:
;; ANSWER SECTION:
10.2.0.192.in-addr.arpa. 3600 IN PTR mail.example.com.
# Reverse lookup
nslookup 192.0.2.10
# Specify DNS server
nslookup 192.0.2.10 8.8.8.8
# Simple reverse lookup
host 192.0.2.10
# Verbose output
host -v 192.0.2.10
Verify that forward and reverse DNS match:
# Check forward DNS
dig mail.example.com +short
# Output: 192.0.2.10
# Check reverse DNS
dig -x 192.0.2.10 +short
# Output: mail.example.com.
# Both should match!
#!/bin/bash
# reverse-dns-check.sh
HOSTNAME="mail.example.com"
# Get IP from forward lookup
IP=$(dig +short $HOSTNAME | head -n1)
if [ -z "$IP" ]; then
echo "Error: No A record found for $HOSTNAME"
exit 1
fi
echo "Forward DNS: $HOSTNAME → $IP"
# Get hostname from reverse lookup
REVERSE=$(dig -x $IP +short)
echo "Reverse DNS: $IP → $REVERSE"
# Check if they match
if [ "$REVERSE" == "$HOSTNAME." ]; then
echo "✓ Forward and reverse DNS match!"
exit 0
else
echo "✗ Mismatch detected!"
echo " Expected: $HOSTNAME."
echo " Got: $REVERSE"
exit 1
fi
Usage:
chmod +x reverse-dns-check.sh
./reverse-dns-check.sh
# Online tool
# Visit: https://mxtoolbox.com/ReverseLookup.aspx
# Enter your mail server IP address
# Check if mail server has valid rDNS
dig -x <mail-server-ip> +short
# Verify matches MX record hostname
dig example.com MX +short
# Test from Google DNS
dig -x 192.0.2.10 @8.8.8.8 +short
# Test from Cloudflare DNS
dig -x 192.0.2.10 @1.1.1.1 +short
# Test from your ISP's DNS
dig -x 192.0.2.10 +short
# All should return the same result
Symptoms:
dig -x 192.0.2.10
# Returns NXDOMAIN or no PTR record
Diagnosis:
# Check who controls the reverse DNS
whois 192.0.2.10 | grep -i "nameserver"
# Verify DNS delegation
dig -x 192.0.2.10 +trace
Solutions:
Contact your hosting provider or ISP
Verify you have authority to set PTR records
Submit request through appropriate channel
Ensure forward DNS is already configured
Symptoms:
dig -x 192.0.2.10 +short
# Returns: old-hostname.example.com
# Expected: mail.example.com
Solutions:
Update PTR record via control panel
Clear DNS cache:
# Linux
sudo systemd-resolve --flush-caches
sudo systemctl restart systemd-resolved
# Clear local DNS cache
sudo /etc/init.d/nscd restart
Wait for DNS propagation (up to 48 hours, typically much faster)
Verify with multiple DNS servers
Symptoms:
dig mail.example.com +short
# Returns: 192.0.2.10
dig -x 192.0.2.10 +short
# Returns: server.hosting.com
Impact:
Email delivery issues
Failed SPF checks
Security warnings
Solutions:
Ensure PTR record matches A record hostname exactly
Update PTR record to match forward DNS
Or update A record to match PTR (if appropriate)
Symptoms:
dig -x 192.0.2.10
# Returns multiple PTR records
Problems:
Non-standard configuration
May cause email delivery issues
Unpredictable behavior
Solutions:
Remove extra PTR records, keeping only one:
# In BIND zone file, ensure only one PTR record exists
10 IN PTR mail.example.com.
# Remove any duplicate entries
Symptoms:
PTR record works on some DNS servers but not others
Intermittent resolution
Diagnosis:
# Check multiple DNS servers
for ns in 8.8.8.8 1.1.1.1 208.67.222.222; do
echo "Testing $ns:"
dig -x 192.0.2.10 @$ns +short
done
Solutions:
Wait for full DNS propagation (24-48 hours)
Check TTL values (lower TTL = faster propagation)
Verify authoritative nameservers have updated records
Symptoms:
dig -x 2001:db8::10
# No PTR record returned
Solutions:
Verify IPv6 PTR record format is correct
Ensure full expanded IPv6 notation in zone file
Check ip6.arpa delegation
Contact provider for IPv6 rDNS support
Always ensure forward and reverse DNS match:
# Good configuration:
mail.example.com. A 192.0.2.10
10.2.0.192.in-addr.arpa. PTR mail.example.com.
Always use complete hostnames:
✓ Correct: mail.example.com
✗ Incorrect: mail
✗ Incorrect: example.com (if server is mail.example.com)
For mail servers, PTR record must match:
# MX record points to:
example.com. MX 10 mail.example.com.
# Mail server A record:
mail.example.com. A 192.0.2.10
# PTR record must be:
10.2.0.192.in-addr.arpa. PTR mail.example.com.
# All must match!
Maintain comprehensive documentation:
IP address assignments and PTR records
Hosting provider contact information
DNS change procedures
Verification test results
Configuration change history
Implement automated monitoring:
#!/bin/bash
# monitor-rdns.sh
IP="192.0.2.10"
EXPECTED="mail.example.com."
ACTUAL=$(dig -x $IP +short)
if [ "$ACTUAL" != "$EXPECTED" ]; then
echo "ALERT: Reverse DNS mismatch!" | mail -s "rDNS Alert" admin@example.com
fi
Add to cron:
# Check every hour
0 * * * * /usr/local/bin/monitor-rdns.sh
For servers with multiple IPs, configure rDNS for each:
192.0.2.10 → mail.example.com
192.0.2.11 → web.example.com
192.0.2.12 → db.example.com
On shared hosting:
May share IP with other domains
PTR record typically shows hosting provider's hostname
Consider dedicated IP for email servers
Verify email delivery not affected
Set appropriate TTL values:
; Short TTL for testing (15 minutes)
10 900 IN PTR mail.example.com.
; Standard TTL (1 hour)
10 3600 IN PTR mail.example.com.
; Long TTL for stable configuration (24 hours)
10 86400 IN PTR mail.example.com.
Reverse DNS exposes infrastructure information:
# Reveals server purpose
192.0.2.10 → mail.example.com
192.0.2.11 → db-master.example.com
192.0.2.12 → vpn-gateway.example.com
Mitigations:
Use generic hostnames for sensitive systems
Implement access controls
Monitor DNS queries for reconnaissance
Implement DNSSEC for authenticity:
# Sign reverse zone with DNSSEC
dnssec-keygen -a RSASHA256 -b 2048 -n ZONE 2.0.192.in-addr.arpa
dnssec-signzone -o 2.0.192.in-addr.arpa db.2.0.192
Restrict zone transfer:
zone "2.0.192.in-addr.arpa" {
type master;
file "/etc/bind/db.2.0.192";
allow-transfer { 203.0.113.10; }; # Secondary NS only
allow-query { any; };
};
Enable DNS query logging:
logging {
channel query_log {
file "/var/log/named/query.log" versions 3 size 10m;
severity info;
print-time yes;
print-category yes;
};
category queries { query_log; };
};
; Forward DNS (example.com)
example.com. IN A 192.0.2.50
mail.example.com. IN A 192.0.2.10
example.com. IN MX 10 mail.example.com.
example.com. IN TXT "v=spf1 ip4:192.0.2.10 -all"
default._domainkey IN TXT "v=DKIM1; k=rsa; p=MIGfMA0GCS..."
; Reverse DNS (2.0.192.in-addr.arpa)
10.2.0.192.in-addr.arpa. IN PTR mail.example.com.
Forward A record exists (mail.example.com → IP)
Reverse PTR record exists (IP → mail.example.com)
Forward and reverse match exactly
MX record points to correct mail server
SPF record includes mail server IP
DKIM configured and signing
DMARC policy published
rDNS verified from multiple locations
# Test complete email DNS setup
dig example.com MX +short
dig mail.example.com A +short
dig -x <mail-server-ip> +short
dig example.com TXT +short | grep spf
Reverse DNS configuration is a fundamental aspect of proper server administration, particularly for email infrastructure and professional network management. While the process varies across hosting providers and DNS implementations, the underlying principle remains consistent: establishing bidirectional DNS resolution that provides authenticity, improves deliverability, and enhances troubleshooting capabilities.
Key takeaways:
Email servers require matching forward and reverse DNS for reliable delivery
Authority matters - ensure you have control or access to modify PTR records
Verification is essential - always test from multiple DNS servers
Consistency prevents issues - maintain matching A and PTR records
Documentation and monitoring ensure long-term stability
Provider-specific procedures vary but follow similar principles
FQDN usage is mandatory for proper configuration
Whether you're configuring reverse DNS through a hosting provider's control panel, submitting requests to cloud providers, or managing your own DNS servers with BIND or PowerDNS, the practices and verification methods covered in this guide will help ensure successful implementation.
For mail server administrators, proper reverse DNS is not optional—it's a prerequisite for professional email delivery. Take the time to configure it correctly, verify thoroughly, and monitor continuously to maintain optimal email reputation and delivery rates.
Continue expanding your DNS knowledge by exploring DNSSEC, advanced BIND configurations, and DNS-based security mechanisms to further enhance your infrastructure's reliability and security.