Check the PTR record of an IPv4 or IPv6 address and, more importantly, whether it survives the return trip. Free, no account, nothing stored.
Reverse DNS Lookup with Forward Confirmation
Forward-confirmed reverse DNS means the PTR record of an IP address names a host, and that host resolves back to the same IP address. The reportedIP Reverse DNS Lookup checks both directions in one pass and, when they disagree, names the addresses the PTR host actually serves.
How this tool works and its limits
The address is turned into its reverse name under in-addr.arpa for IPv4 or ip6.arpa for IPv6 and queried for a PTR record. Every name that comes back is then resolved forward, A and AAAA, and the full answer set is compared against the address that was asked about. The address is confirmed as soon as one PTR name resolves back to it.
The complete answer set matters: a PTR host is often shared by several addresses. 8.8.8.8 has the PTR name dns.google, and dns.google answers with 8.8.8.8 and 8.8.4.4 plus two IPv6 addresses. A check that compared only the first answer would call half of that pool unconfirmed. Addresses are compared in their binary form, so the many ways of writing one IPv6 address all count as the same address.
A PTR record can only be published by whoever holds the IP address block, normally the hosting or transit provider, not by the owner of the domain. A missing or unconfirmed PTR record is one of the most common reasons a mail server is rejected or filtered, which is why the result explains the state instead of only marking it.
What forward-confirmed reverse DNS actually means
A reverse lookup answers one question: which name does the owner of this address publish for it? That name is the PTR record. On its own it proves nothing, because the owner of an address can publish any name at all, including one that belongs to somebody else.
The check that counts is the return trip. Take the name from the PTR record, look up its A and AAAA records, and see whether the address you started from is among them. If it is, both halves of the pair agree and the name is confirmed. If it is not, the PTR record is a claim nobody backed up. Receiving mail servers, abuse desks and log analysis tools all make this second step, which is why a PTR record alone is not enough.
Why a mail server is refused over this
A sending mail server without a confirmed PTR record is the single most common reason a message is rejected at the connection stage, before the content is ever looked at. Large providers treat a missing or unconfirmed reverse record as a sign of a compromised host or a consumer connection, because that is usually what it is.
The fix is not in your control alone: the PTR record lives with whoever owns the address block, so it is your hosting provider or your ISP who sets it. What is in your control is making the forward record match it.
What this tool checks
1. Input
Enter an IPv4 address, an IPv6 address or a hostname. A hostname is resolved to all of its A and AAAA records and every address is checked separately, because a dual-stack host can be correct on one protocol and broken on the other.
2. PTR lookup
The address is turned into its reverse name and queried. IPv4 uses the reversed octets under in-addr.arpa, IPv6 uses all 32 nibbles reversed under ip6.arpa.
3. Forward confirmation
Every name the PTR record returns is resolved again, and the full set of its A and AAAA records is compared against the original address. A host behind round robin answers with several addresses, so comparing only the first one would mark correct setups as broken.
4. The divergence
When the pair does not match, the result names the addresses the PTR record actually points to. That is what tells you whether you are looking at a stale record, a shared reverse entry or a name that was never yours.