Reverse DNS Is an Assertion, Not a Proof — Here's What FCrDNS Actually Verifies

An IP address like 203.0.113.42 tells you a server exists at that address — a reverse DNS lookup tells you the name that the server's owner has chosen to associate with it, which is a completely different piece of information with completely different trust properties

The previous articles on this site covered reverse DNS basics, PTR records and email deliverability, IP geolocation, and IPv4 vs IPv6 reverse DNS delegation. This article addresses the trust question: what reverse DNS actually verifies, what it doesn't, and how this distinction affects whether you should rely on it for security decisions, logging, or identification.

Forward vs reverse DNS: the fundamental asymmetry

Forward DNS (A/AAAA records) maps a name → an IP address. If you query example.com and get 203.0.113.42, that tells you the owner of the example.com domain has chosen to point it at that IP.

Reverse DNS (PTR records) maps an IP address → a name. If you query 203.0.113.42 and get mail.example.com, that tells you the owner of that IP address (usually an ISP, hosting provider, or the organization that was allocated that IP block) has chosen to associate that name with that IP.

These are maintained independently, by potentially different parties — the forward DNS for example.com is controlled by whoever manages example.com's DNS. The reverse DNS for 203.0.113.42 is controlled by whoever was allocated that IP block (which might be a hosting provider, not the same organization).

What reverse DNS doesn't verify: no cryptographic proof of identity

A PTR record saying mail.example.com for IP 203.0.113.42 does not prove that 203.0.113.42 is operated by example.com. It proves that whoever controls the reverse DNS zone for that IP chose to set that PTR record. That might be example.com itself — or it might be the hosting provider on example.com's behalf — or it might be whoever previously had that IP before example.com (if PTR records weren't updated when the IP was reassigned).

This is why "the reverse DNS says it's X" is not equivalent to "this IP is operated by X." Without additional verification, PTR records are assertion-only — they represent a claim, not a cryptographically signed proof.

The "forward-confirmed reverse DNS" check: a stronger (but imperfect) verification

"FCrDNS" (Forward-Confirmed Reverse DNS) — also called "double-checked reverse DNS" or "RDNS verification" — is a pattern for getting stronger confidence than PTR records alone:

1. Take the IP address
2. Perform a reverse DNS lookup → get a hostname (e.g., mail.example.com)
3. Perform a forward DNS lookup on that hostname → get an IP address
4. Compare: does the forward-resolved IP match the original IP?

If yes: the PTR record is "forward-confirmed" — someone controls both the IP's reverse DNS and the A/AAAA record for the returned hostname, and they've configured both to be consistent. This is a meaningful (though still not cryptographic) signal of legitimate, consistent configuration.

If no: the PTR record is "unconfirmed" — it might be stale (PTR wasn't updated when the IP changed hands), misconfigured, or potentially an intentional attempt to impersonate a domain via a PTR record.

Email systems use FCrDNS as part of their anti-spam/reputation checks — as covered in the previous deliverability article. It's also used in server access logs, network monitoring, and some firewall/access-control systems.

When PTR records are legitimately useful for logging and monitoring

For human-readable server logs, reverse DNS provides context that raw IP addresses lack:

• 203.0.113.42 - - [request log] gives you an IP to look up later
• mail.example.com (203.0.113.42) - - [request log] immediately suggests this was an email server from example.com

This is informational, not authoritative. Log analysis doesn't require cryptographic identity verification — the hostname in a log entry is a clue about what the traffic might have been, not a proof of origin. For purposes like understanding traffic patterns, identifying bot traffic, or investigating anomalies, PTR records provide useful context even without being definitively verified.

Resolving hostnames for every log entry adds latency (each PTR lookup is a DNS query) — this is why many high-traffic systems log IPs and resolve them offline or on demand (when investigating specific entries), rather than resolving in real-time.

Googlebot verification: a worked example of FCrDNS in practice

Google publishes guidance for verifying Googlebot traffic: if you see traffic from an IP claiming to be Googlebot (via User-Agent), do not trust the User-Agent alone — instead, perform a reverse DNS lookup on the IP. If the hostname ends in googlebot.com or google.com, perform a forward lookup on that hostname and verify the IP matches. Only if both steps pass should the traffic be treated as genuine Googlebot.

This is FCrDNS in practice — and Google explicitly recommends it specifically because User-Agent strings are trivially forged. PTR records are harder to forge (you need control of the reverse DNS zone for that IP, which requires controlling the IP allocation or having the ISP cooperate) — so FCrDNS provides substantially more confidence than User-Agent alone, even though it's still not cryptographically guaranteed.

How to use the Reverse DNS tool on sadiqbd.com

1. For basic identification: look up an IP from your logs to get a human-readable hostname — treat the result as informational, a clue about likely identity, not a verified identity
2. For stronger verification: perform the forward lookup yourself — resolve the returned hostname back to an IP and check it matches; if it does, the PTR record is forward-confirmed and substantially more trustworthy
3. For email deliverability: the previous article covered this specifically — your sending IP's PTR record should resolve to a hostname that forward-resolves back to the same IP; mismatches or missing PTR records affect spam-filter scores

Frequently Asked Questions

Can I set any PTR record I want for an IP I control? Generally, no — not unilaterally. PTR records are set in reverse DNS zones that are delegated to IP block holders by the IP registries. For large IP blocks allocated directly to your organization (e.g., a /24 or larger), your organization likely has control of the reverse zone and can set PTR records yourself. For individual IPs from a hosting provider or ISP, they typically control the reverse zone — and PTR records are set either by them on request, or via a self-service interface they provide. This is why "my email server needs a PTR record" often means "I need to ask my hosting provider to set one" rather than "I can just add it to my DNS records."

Is the Reverse DNS tool free? Yes — completely free, no sign-up required.

Try the Reverse DNS tool free at sadiqbd.com — look up the hostname for any IP address instantly.