Loading network utility...
Loading network utility...
Sending emails without a valid PTR record causes instant spam filtering and rejection. This guide explains how the in-addr.arpa tree resolves reverse lookups and how to configure matching forward and reverse DNS.
Run live checks and calculations directly on LotsofNetwork.
Standard forward DNS resolves human-friendly domain names to machine-routable IP addresses (e.g. example.com ➔ 93.184.216.34). Reverse DNS does the exact opposite: given an IP address, it queries the DNS hierarchy to discover the assigned domain hostname.
To make reverse lookups possible within the existing tree-structured DNS protocol, the Internet Engineering Task Force (IETF) created a special top-level domain named in-addr.arpa for IPv4 (and ip6.arpa for IPv6).
Because IPv4 address octets read from largest network to smallest host (left to right), while DNS domains read from most specific to least specific (left to right), the octets of an IP address must be reversed when querying PTR records.
Forward Mapping:
example.com ─────── A Record Query ───────► 93.184.216.34
Reverse Mapping:
93.184.216.34 ───── Reverse Octets ─────► 34.216.184.93.in-addr.arpa
│
▼ (PTR Query)
mail.example.comSimply having a PTR record is not always enough to prove authentic identity. Spammers could configure a PTR record on an IP address pointing to a reputable domain like 'google.com' without owning Google.
To prevent this impersonation, mail servers and security gateways enforce Forward-Confirmed Reverse DNS (FCrDNS):
1. Step 1: The receiving mail server takes the client IP (e.g. 198.51.100.5) and runs a reverse lookup to find the PTR hostname (mail.example.com).
2. Step 2: The server immediately executes a forward DNS lookup on that returned hostname (mail.example.com) to find its A records.
3. Step 3: If the IP address found in Step 2 matches the originating IP in Step 1, FCrDNS passes with flying colors. If there is a mismatch or missing record, the connection is rejected.
Over 85% of global email spam originates from compromised home computers, residential cable modems, and IoT devices infected with malware. Internet service providers assign residential IPs dynamic hostnames containing words like 'pool', 'dynamic', or 'dhcp', and intentionally block PTR configuration on home connections.
Consequently, enterprise email providers (including Google Workspace, Microsoft 365, Yahoo, and Fastmail) use PTR and FCrDNS status as a primary spam gatekeeper. If your mail server IP lacks a matching PTR record, incoming SMTP connections are immediately rejected with error codes like 550 5.7.1 Service unavailable.
You can verify your server's reverse DNS and PTR configuration using dig or nslookup:
# Test Reverse DNS for an IPv4 address using dig: dig +short -x 8.8.8.8 # Output: # dns.google. # Test forward confirmation of the returned hostname: dig +short A dns.google # Output: # 8.8.8.8 # 8.8.4.4 (Matches! FCrDNS Confirmed)
Unlike forward A records (which you configure at domain registrars like Namecheap or Cloudflare), PTR records must be configured by the organization that owns the underlying IP block:
- AWS EC2: In the AWS Management Console, navigate to Elastic IPs, select your IP, click 'Actions' ➔ 'Update reverse DNS', and enter your mail server domain name.
- DigitalOcean: Go to Networking ➔ Floating IPs, select your droplet, and update the PTR hostname.
- Linode / Hetzner / Vultr: Open the Networking tab on your VPS dashboard and enter your Fully Qualified Domain Name (FQDN) in the Reverse DNS field.
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
Calculate CIDR, masks & host ranges
Two-way CIDR notation to IP range converter
Inspect SSL expiry, issuer, SANs & TLS