What a reverse DNS lookup is asking
Forward DNS maps a name to an address. A reverse lookup does the opposite, and the direction matters because the two are completely separate data. Publishing an A record for a host does not create a reverse record, and creating a reverse record does not require an A record to exist. Nothing keeps them consistent by itself.
Reverse data lives under a special name space. An IPv4 address is reversed octet by octet and placed under in-addr.arpa, so the lookup for 8.8.8.8 asks about 8.8.8.8.in-addr.arpa. IPv6 reverses each hexadecimal digit instead and uses ip6.arpa. The report above shows the exact name that was queried, so you can reproduce it against any resolver.
Why the owner of the range publishes it, not you
The ability to publish a PTR record follows address ownership, not domain ownership. The operator that holds the address range delegates a reverse zone, and whoever administers that zone decides what each address claims to be called. That is why a home connection often has a functional-looking host name chosen by the provider — a city code, a technology code, a network segment — and sometimes has nothing at all.
This has a practical consequence that surprises people. If you send mail from a server whose address is allocated by a hosting provider, the PTR record you need is in the provider’s panel, not in your domain’s DNS panel. Looking for it in the wrong panel is the usual reason a missing record seems impossible to fix.
Why the forward check is the interesting part
A PTR record on its own is a weak claim. Any zone can say that an address is called anything. The stronger statement is the round trip: the address resolves to a name, and that name resolves back to the same address. That pair is what mail receivers commonly look for, and it is why this page performs the second lookup rather than stopping at the first.
The failure mode worth understanding is a PTR record that points at a name which no longer resolves back, or resolves somewhere else entirely. That is worse than having no record, because it looks like an attempt to appear legitimate. When a sending host is refused by receivers despite correct SPF and DKIM, a broken round trip is one of the first things to check.
Where this shows up in practice
Mail is the main consumer of reverse data. A receiving server that cannot resolve the address of a connecting host has less to base a decision on, and many receivers treat a missing or mismatched reverse record as a negative signal even when authentication passes. That is why the MX record check reads the reverse record of the first mail host, and why the email deliverability test treats authentication and reverse data as separate concerns.
Log reading is the second place it appears. Logs frequently contain only addresses, and a reverse lookup is what turns a column of numbers into host names that identify the network each request came from. Remember that the name you get is the network’s claim, not a verified label.
What a reverse lookup does not tell you
It does not identify a person, a subscriber or a physical location. There is no public mapping from an address to a named individual, and the reverse zone does not contain one. A host name containing a city is a fact about the provider’s naming convention.
It does not tell you whether an address is trustworthy, whether it is on a blocklist, or whether a service will accept a connection from it. Those are separate questions with separate sources IP reputation check and IP blacklist check.
It also does not confirm that a server is up. A PTR record is static data in a zone; it stays published whether the machine behind the address is running or not. For the network the address belongs to, the ASN lookup reports the announcing organisation, and IP check reports the address family and owner for the connection you are actually using.