PTR records and reverse DNS for mail servers: why FCrDNS matters

What reverse DNS actually resolves

A normal DNS lookup takes a hostname and returns an IP address. Reverse DNS does the opposite: it takes an IP address and returns a hostname, using a dedicated DNS record type (PTR) stored in a special zone — in-addr.arpa for IPv4, defined in RFC 1035, or ip6.arpa for IPv6, added by RFC 3596. The lookup is structured as the IP’s octets or nibbles in reverse order under that zone, which is why it needs its own record type rather than reusing an ordinary A or AAAA record. AdminKit’s reverse DNS (PTR) tool performs this lookup for any IPv4 or IPv6 address and shows the hostname it resolves to, if any.

A PTR record is not controlled by the operator of a website or mail domain — it’s controlled by whoever owns the IP address block the address comes from, which for most senders means a hosting provider, cloud platform, or ISP. This is the single most important fact to understand before troubleshooting a PTR problem: you usually cannot fix a missing or wrong PTR record yourself by editing your own domain’s DNS, because it lives in a zone your DNS provider doesn’t control.

Why mail servers specifically care

Reverse DNS predates modern mail authentication (SPF, DKIM, DMARC) by decades, and it survives as a check because it’s cheap, requires no cooperation from the sender’s domain, and catches a specific category of low-effort abuse: mail sent directly from a compromised consumer device, a botnet node, or a throwaway cloud instance that was never configured as a real mail server. Legitimate mail infrastructure is set up deliberately — someone requested a PTR record, which means someone took a configuration step that abuse infrastructure usually skips. A missing PTR record doesn’t prove malicious intent, but its absence correlates strongly enough with abuse sources that many receiving mail servers treat it as a meaningful signal, sometimes enough on its own to reject a connection outright.

Forward-confirmed reverse DNS (FCrDNS)

Checking the PTR record alone has a gap: nothing stops whoever controls an IP block from publishing any hostname they like in the PTR record, including one that implies legitimacy it doesn’t have. Forward-confirmed reverse DNS closes that gap by checking both directions: look up the PTR record for the sending IP to get a hostname, then look up that hostname’s own A or AAAA record and confirm it resolves back to the same IP. If both directions agree, the sending IP and the claimed hostname are mutually consistent — not cryptographically proven, since DNS itself isn’t signed by default, but a meaningfully stronger signal than a PTR record checked in isolation. Many receiving mail servers perform exactly this two-step check before accepting a connection, which is why a correctly configured mail server needs both a PTR record pointing at a hostname, and that hostname’s forward record pointing back at the same IP.

Common misconfigurations

The most frequent real-world problem is simply no PTR record at all — common on newly provisioned cloud instances, where the default is no reverse DNS until you explicitly request one. The second most common is a PTR record that doesn’t match the mail server’s actual hostname used in its SMTP greeting (the HELO/EHLO command), which some receivers check for consistency as an additional signal beyond FCrDNS alone. A third, subtler problem is a PTR record whose forward A/AAAA lookup doesn’t resolve at all, or resolves to a different IP — breaking FCrDNS even though the PTR record itself technically exists.

How to check and fix it

1. Look up your sending IP’s PTR record with AdminKit’s reverse DNS tool. No result at all means you need to request one from whoever controls the IP.
2. Check that the hostname it returns resolves forward back to the same IP, using AdminKit’s DNS lookup tool against that hostname’s A or AAAA record — this is the FCrDNS check performed manually.
3. Request a specific PTR value from your hosting provider if none exists or it’s wrong; most cloud and hosting providers expose this in their control panel, and generally require the matching forward record to exist first.
4. Keep the PTR hostname consistent with your mail server’s HELO/EHLO identity, since some receivers check that too.
5. Treat this as one signal among several, not a complete fix for deliverability — see why is my IP address blacklisted? for the fuller picture of how sending reputation is built and damaged, and check your MX records to confirm mail is actually routing where you expect in the first place.