What is Forward-Confirmed Reverse DNS (FCrDNS)?
In standard forward DNS lookups, a human-readable domain name (such as mail.example.com) is translated into an IP address (such as 198.51.100.25).Reverse DNS (rDNS) performs the inverse translation: given an IP address, it queries a specialized PTR (Pointer) record within the in-addr.arpa (for IPv4) orip6.arpa (for IPv6) zone to discover the hostname associated with that IP.
However, simply having a PTR record is not enough to pass enterprise spam filters. Anyone who controls an IP subnet could configure a PTR record pointing to an arbitrary domain like mail.google.com. To establish genuine authenticity, modern mail systems require Forward-Confirmed Reverse DNS (FCrDNS):
- Step 1 (Reverse Lookup): The recipient server queries the PTR record for sending IP
198.51.100.25, obtaining hostnamemail.example.com. - Step 2 (Forward Lookup): The recipient immediately queries the forward
Arecord formail.example.com. - Step 3 (Confirmation): The recipient checks whether the IP returned in Step 2 matches the original sending IP from Step 1. Only if they match bidirectionally is the connection considered forward-confirmed.
Why Google, Yahoo, and Microsoft Enforce FCrDNS
Spammers, botnets, and malware-infected home PCs typically send unauthorized email from dynamic residential IP addresses (e.g., DSL, cable modem, or 5G cellular pools) that lack custom PTR records or possess generic generic ISP hostnames such aspool-123-45-67-89.dynamic.isp.com.
Because legitimate businesses send mail from dedicated servers, cloud instances, or managed SMTP relays, internet service providers treat the absence of FCrDNS as a critical spam signal. In 2024, Google and Yahoo made FCrDNS a mandatory requirementfor all senders. Outbound email from servers lacking valid FCrDNS is immediately blocked with SMTP error:
How to Configure PTR Records with Your Hosting Provider
Unlike standard DNS records (such as A, CNAME, MX) which you manage through your domain registrar (GoDaddy, Namecheap, Cloudflare),PTR records must be created by the owner of the physical IP address allocation.
Depending on where your mail server is hosted, you must configure rDNS through your infrastructure dashboard:
Navigate to the EC2 console → Network & Security → Elastic IPs → Actions → Update reverse DNS. Enter your mail hostname (e.g. mail.example.com).
Rename your Droplet / VPS to match your fully qualified mail domain (mail.example.com). The hosting control panel will automatically provision the corresponding PTR record in its authoritative in-addr.arpa zone.
Frequently Asked Questions (FAQ)
Yes. A large corporate mail cluster may have 10 different outbound IPs all sharing the PTR hostname outbound.mail.example.com, as long as the forward A record for that hostname resolves to all 10 IP addresses to maintain bidirectional FCrDNS confirmation.
While technically permitted by DNS specifications, assigning multiple PTR records to a single IP address is strongly discouraged for mail servers. Many recipient MTAs only evaluate the first PTR returned or discard ambiguous responses, causing random deliverability failures.
No. FCrDNS validates server identity at the IP/network transport layer. In contrast, SPF verifies authorized sender IPs,DKIM guarantees message integrity via cryptographic signatures, and DMARC enforces domain alignment policies. All four technologies are required for reliable, high-volume email delivery.