Loading network utility...
Loading network utility...
While standard Forward DNS translates human-readable domain names into IP addresses, Reverse DNS (rDNS) performs the exact inverse operation: mapping an IP address back to its verified canonical hostname via PTR records stored in special in-addr.arpa and ip6.arpa zones.
Run live checks and calculations directly on LotsofNetwork.
In the DNS hierarchy, domains are structured from most specific on the left (subdomain) to least specific on the right (TLD, e.g., mail.example.com). However, IP addresses are written in the opposite direction: the network identifier is on the left and the host identifier is on the right (e.g., 198.51.100.25).
To allow the standard hierarchical DNS delegation model to resolve IP addresses, RFC 1035 established the special top-level domain .arpa and the second-level domain in-addr.arpa for IPv4.
To query a reverse DNS record, the octets of the IPv4 address are reversed and appended to in-addr.arpa. For example, to find the reverse hostname for 198.51.100.25, a DNS resolver queries 25.100.51.198.in-addr.arpa for a PTR (Pointer) record.
Target IPv4 Address: 198.51.100.25 Octets in Normal Order: [198].[51].[100].[25] Reversed Octets: [25].[100].[51].[198] Appended Reverse Domain: 25.100.51.198.in-addr.arpa BIND Zone PTR Record Entry: 25.100.51.198.in-addr.arpa. 86400 IN PTR mail.example.com.
The single most critical application of Reverse DNS today is enterprise email deliverability and anti-spam verification. Major mail providers (including Google Workspace, Microsoft 365, and Yahoo Mail) strictly enforce Forward-Confirmed Reverse DNS (FCrDNS).
When your mail server connects to a recipient MTA on TCP Port 25, the receiving server inspects the connecting TCP socket IP address and performs a PTR lookup. If no PTR record exists, or if the PTR points to a generic ISP customer hostname (e.g., c-73-12-45-98.hsd1.comcast.net), the message is instantly flagged as suspicious or rejected with an SMTP 550 error.
Under FCrDNS, the receiving server goes one step further: after receiving the hostname from the PTR record (e.g., mail.example.com), it performs a Forward DNS 'A' lookup on mail.example.com. If the resulting 'A' record does NOT match the connecting IP address, the connection is treated as forged or hijacked and terminated.
| FCrDNS Validation Step | DNS Query Type | Expected Result | Failure Consequence |
|---|---|---|---|
| Step 1: Inbound Connection | Socket Inspection | Connecting IP: 198.51.100.25 | N/A |
| Step 2: Reverse Lookup | PTR on 25.100.51.198.in-addr.arpa | Returns mail.example.com | Immediate 550 SMTP rejection if missing |
| Step 3: Forward Confirmation | A lookup on mail.example.com | Returns 198.51.100.25 | Immediate rejection if IP mismatch (spoofing) |
| Step 4: SMTP HELO/EHLO Match | Banner Inspection | EHLO matches mail.example.com | Spam score penalty if mismatch |
A frequent point of confusion for developers is where to configure PTR records. Unlike Forward DNS records (A, CNAME, MX) which you manage at your domain registrar or cloud DNS provider (Cloudflare, Namecheap, Route 53), Reverse DNS is owned by the entity that controls the IP address allocation.
For cloud servers and VPS instances, your hosting provider (AWS, DigitalOcean, Linode, Hetzner, Vultr) controls the IP block allocated to them by the regional registry (ARIN, RIPE, APNIC). You must configure the PTR record in your cloud provider's networking console, not at your domain registrar.
Verify PTR records and test Forward-Confirmed Reverse DNS using standard terminal commands:
# Perform a PTR lookup on an IPv4 address using dig dig -x 198.51.100.25 +short # Output: mail.example.com. # Verify forward confirmation (FCrDNS) on the returned hostname dig mail.example.com A +short # Output must match: 198.51.100.25 # Query reverse DNS using host command host 198.51.100.25 # Windows Command Prompt nslookup syntax nslookup -type=PTR 198.51.100.25 8.8.8.8
AI Mobile App Developer & Full-Stack Systems Engineer•Dhaka, Bangladesh
Bayajit Islam is an AI Mobile App Developer and Full-Stack Systems Engineer based in Dhaka, Bangladesh. With 2+ years of hands-on production experience building cross-platform apps for iOS, Android & Desktop with Flutter & Dart, asynchronous backends with FastAPI & Python, and modern web applications with Next.js, TypeScript, and Docker, he engineered LotsofNetwork as a zero-latency, privacy-first diagnostic platform for developers and network administrators.
Quick answers to common questions on this topic.
High-speed, zero-cost engineering tools built for network diagnostics and developer workflows.
Detect IP, GeoIP, ISP, ASN & PTR
Query A, AAAA, MX, TXT & NS records
Domain registrar & expiry info
Audit SPF, DKIM & DMARC records
Check global DNS record propagation across Anycast resolvers
Calculate CIDR, masks & host ranges