Reverse DNS

About the Reverse DNS

This reverse DNS tool takes an IPv4 or IPv6 address and looks up its PTR record, the hostname the address claims to be. It then performs a forward-confirmed reverse DNS (FCrDNS) check on every hostname found: it resolves each one forward again, using the matching address family, and confirms whether it points back to the exact original IP, the same validation receiving mail servers run on a sender before accepting a connection.

You reach for this when checking whether a mail server's IP has reverse DNS set up correctly before sending email, when a support ticket to your hosting provider needs proof of a missing or mismatched PTR, or more generally when identifying what a particular address claims to be, a VPN exit node, a cloud provider's block, or a residential ISP's dynamic range often reveal themselves through their PTR naming convention alone.

Unlike a bare PTR lookup, this tool shows every hostname found and, for each one, whether its own forward lookup actually confirms the original address, so a PTR that exists but points somewhere else is distinguished clearly from no PTR at all, two situations that call for slightly different next steps and get their own warnings.

The lookups run server-side against public resolvers, since PTR data lives in the in-addr.arpa/ip6.arpa reverse zones and is only reachable that way. The IP you enter is validated as a real address before anything is queried, results are never cached (no-store), and the check sits behind the same shared per-IP rate limit as every tool here.

How to use it

1. Enter the IPv4 or IPv6 address you want to check.
2. Submit to fetch its PTR record(s), the reverse hostname(s) it claims to be.
3. Read the headline verdict: FCrDNS confirmed, FCrDNS not confirmed, or no PTR at all.
4. Check each hostname row individually, a checkmark means that name's forward lookup matched the IP, an X means it did not.
5. Note the forward address(es) each hostname resolves to, shown next to the row, to see exactly where the mismatch is.
6. Read any warning about a missing PTR or a failed FCrDNS confirmation.
7. If you control the IP, request the PTR fix from your hosting provider or ISP, then re-run the check once it takes effect.

Examples

• Check 8.8.8.8 and see PTR dns.google, which resolves forward back to 8.8.8.8, FCrDNS confirmed.
• Check a mail server's IP and see PTR mail.example.com resolve forward back to that same IP, FCrDNS confirmed.
• An IP returns PTR host.example.net, but that hostname resolves to a different address, FCrDNS fails and mail from it may be penalised.
• An IP with no PTR record at all returns an empty PTR list, a frequent, easily overlooked deliverability problem for self-hosted mail.
• A residential or dynamic ISP address typically shows a generic PTR like host-203-0-113-10.isp.example.net, harmless for browsing but a red flag if that IP tries to send mail directly.
• Check an IPv6 address like 2001:4860:4860::8888 and confirm FCrDNS the same way, using AAAA-based forward resolution instead of A.

PTR lookup versus a full FCrDNS check

A plain PTR lookup answers one question: what hostname does this IP claim? It reads the reverse zone and stops there, a spoofed or stale PTR record would look identical to a correct one from that single step alone. Forward-confirmed reverse DNS adds the second half: take each hostname the PTR returned, resolve it forward again, and check whether it actually leads back to the same IP you started from. Only when both directions agree does the address get treated as having valid FCrDNS, which is exactly what a receiving mail server checks before deciding how much to trust an unfamiliar sending IP.

Why mail servers care about FCrDNS

Forward-confirmed reverse DNS is one of the oldest and still most common anti-spam signals. Many mail transfer agents (Postfix's reject_unknown_client_hostname, Exchange connection filtering, and most commercial spam filters) either reject or heavily penalise a connecting IP that has no PTR record or whose PTR does not forward-confirm, on the reasoning that legitimate, well-run mail infrastructure almost always has this set up correctly, while compromised hosts and opportunistic spam sources frequently do not.

• No PTR at all: often the single biggest reason self-hosted mail gets rejected or spam-scored.
• PTR present but not forward-confirmed: treated as a red flag, since it looks like spoofable or stale rDNS.
• Cloud and VPS providers usually assign a generic default PTR and require a support ticket to set a custom one.
• A correct FCrDNS setup alone does not guarantee delivery, it removes one common reason for outright rejection.

How to fix a missing or mismatched PTR

PTR records live in the reverse zone controlled by whoever owns the IP block, not in your domain's own DNS, so the fix always goes through the IP's owner.

• Identify who owns the IP block (your hosting provider, cloud platform or ISP), a WHOIS/RDAP lookup on the IP will show this if it isn't obvious.
• Request the specific PTR hostname you want, most providers have a support form or API for this rather than a self-service DNS panel.
• Make sure a matching forward A or AAAA record for that same hostname exists in your own domain's DNS, FCrDNS needs both directions to agree.
• Allow for propagation once the provider makes the change, reverse zones are cached like any other DNS data.
• Re-run this check afterwards to confirm both the PTR and the forward confirmation now line up.

Frequently asked questions