When configuring production servers, mail transfer agents (MTAs), or cloud infrastructure, Reverse DNS (rDNS) and PTR (Pointer) records are critical yet frequently misunderstood components of the Internet directory structure.
While forward DNS maps friendly domain names (api.example.com) to machine IP addresses (198.51.100.42), reverse DNS performs the opposite transformation—translating raw numerical IP addresses back to canonical hostnames.
If your mail servers lack properly configured PTR records or fail Forward-Confirmed Reverse DNS (FCrDNS) checks, major inbox providers like Google Gmail, Microsoft Outlook, and Yahoo Mail will drop or reject your emails with 550 5.7.1 authentication errors.
Test your server PTR records instantly with our IP to Hostname Tool or verify email authentication with DMARC, SPF & DKIM Checker.
1. How Reverse DNS Works: The .arpa Infrastructure
Because standard DNS trees are structured hierarchically from right to left (Top-Level Domain down to hostnames), resolving a numerical IP address directly without prior knowledge of the parent domain requires a dedicated reverse directory.
The Internet Engineering Task Force (IETF) designated the .arpa (Address and Routing Parameter Area) top-level domain for reverse lookups.
IPv4 Reverse Architecture (in-addr.arpa)
For IPv4 addresses, the four dotted octets are reversed and appended with .in-addr.arpa:
Standard IPv4: 198.51.100.42
Octets: [198] . [51] . [100] . [42]
Reversed Path: 42 . 100 . 51 . 198 . in-addr . arpa
DNS Hierarchy:
(.) Root
└── arpa.
└── in-addr.
└── 198.
└── 51.
└── 100.
└── 42 (PTR ➔ mail.example.com)
IPv6 Reverse Architecture (ip6.arpa)
For 128-bit IPv6 addresses, every single 4-bit hexadecimal nibble (32 digits in total) is separated by dots, listed in reverse order, and appended with .ip6.arpa (RFC 3596):
IPv6 Address: 2001:db8::1
Expanded: 2001:0db8:0000:0000:0000:0000:0000:0001
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
2. Forward-Confirmed Reverse DNS (FCrDNS) Explained
FCrDNS (Forward-Confirmed Reverse DNS), also known as full-circle reverse DNS, is a two-way validation method used by receiving mail servers, anti-spam filters, and security appliances to verify that the sender legitimately owns the originating IP address.
+───────────────────────────────────────────────────────────────+
│ FCrDNS Verification Flow │
+───────────────────────────────────────────────────────────────+
│
Step 1: Inbound Connection
Sender IP connects: 198.51.100.25
│
▼
Step 2: Reverse PTR Lookup
Query: 25.100.51.198.in-addr.arpa
Result: mail.example.com
│
▼
Step 3: Forward A / AAAA Lookup
Query: mail.example.com A
Result: 198.51.100.25
│
┌───────────────┴───────────────┐
▼ ▼
IPs Match? (YES) IPs Match? (NO)
FCrDNS PASSED FCrDNS FAILED
Accept for SPF/DKIM 550 SMTP Rejection / Spam
The 3 Requirements for FCrDNS Compliance:
- Valid PTR Record: The sending IP address must have an authoritative PTR record returning an FQDN (e.g.,
mail.example.com). - Matching Forward A Record: The returned FQDN must have a forward
Arecord that resolves back to the originating IP address. - SMTP HELO/EHLO Alignment: The hostname advertised by the sending MTA in its SMTP
HELOorEHLObanner must match the FQDN in the PTR record.
3. Configuring PTR Records Across Major Cloud Providers
Unlike forward A records (which are configured in your domain registrar's DNS panel), PTR records must be set with the cloud provider or ISP that owns the public IP allocation.
AWS EC2 (Elastic IPs)
AWS allows reverse DNS configuration directly on Elastic IP addresses via the AWS CLI or Console:
# Update reverse DNS for an AWS Elastic IP
aws ec2 modify-address-attribute \
--allocation-id eipalloc-0123456789abcdef0 \
--domain-name mail.example.com
Google Cloud Platform (Compute Engine)
In GCP, reverse DNS is configured directly on the VM network interface:
- In the Google Cloud Console, navigate to Compute Engine ➔ VM Instances.
- Click Edit on your VM instance.
- Under Network interfaces, click on the external IP.
- Enable Enable PTR record and enter your domain name (e.g.
mail.example.com).
Microsoft Azure
In Azure, reverse DNS is managed on the Public IP address resource:
# Set Reverse FQDN on Azure Public IP
az network public-ip update \
--resource-group ProductionRG \
--name MailServerPublicIP \
--reverse-fqdn mail.example.com
DigitalOcean & Linode
On VPS hosts like DigitalOcean and Linode, setting the hostname (droplet/node name) to your Fully Qualified Domain Name automatically configures the corresponding PTR record on their authoritative nameservers.
4. Diagnostic Playbook: CLI Tools (dig, host, nslookup)
1. Reverse Lookup with dig -x
The standard command to perform a reverse DNS lookup:
dig -x 8.8.8.8 +short
# Output: dns.google.
2. Trace Authoritative Delegation Chain
To inspect which nameserver holds the authoritative PTR record and bypass resolver caching:
dig -x 198.51.100.42 +trace
3. Quick Lookup with host
host 1.1.1.1
# Output: 1.1.1.1.in-addr.arpa domain name pointer one.one.one.one.
4. Direct Nameserver Query with nslookup
nslookup -type=PTR 9.9.9.9 8.8.8.8
5. RFC 2317: Classless Subnet Reverse Delegation
Standard in-addr.arpa delegation is designed around 8-bit octet boundaries (/8, /16, /24). When an ISP allocates a smaller subnet (e.g., a /28 with 16 addresses or a /29 with 8 addresses), the ISP cannot delegate the full /24 zone.
RFC 2317 standardizes classless in-addr.arpa delegation by having the parent ISP place CNAME records in their /24 zone pointing to a subzone managed by the tenant:
; Parent ISP Zone (100.51.198.in-addr.arpa):
16/28 IN NS ns1.customer.com.
16/28 IN NS ns2.customer.com.
17 IN CNAME 17.16/28.100.51.198.in-addr.arpa.
18 IN CNAME 18.16/28.100.51.198.in-addr.arpa.
; Customer Child Zone (16/28.100.51.198.in-addr.arpa):
17 IN PTR mail.customer.com.
18 IN PTR vpn.customer.com.
6. Common Troubleshooting Checklist
| Issue | Root Cause | Solution |
|---|---|---|
NXDOMAIN / No PTR Record |
Hosting provider has not published PTR in in-addr.arpa zone | Open a ticket or use cloud console to set Reverse DNS for your static IP |
| FCrDNS Validation Failure | Hostname in PTR resolves to a different IP than originating server | Update the forward A record of mail.domain.com to match the Elastic IP |
| SMTP Banner Mismatch | Postfix/Exim myhostname does not match PTR FQDN |
Configure SMTP server configuration with matching FQDN |
| Stale PTR after Migration | High TTL cached on global recursive resolvers | Wait for previous TTL to expire (typically 12–24h) |
Use the IP to Hostname Tool and DNS Lookup Tool to verify live records across global nameservers.