Reverse DNS Lookup and IP Reputation: What rDNS Can Tell You

A normal DNS lookup turns a hostname into an IP address. Reverse DNS goes the other way: it asks which hostname, if any, has been published for an address. The answer comes from a PTR record stored under a special part of the DNS tree, in-addr.arpa for IPv4 (RFC 1035) and ip6.arpa for IPv6 (RFC 3596), where the address is written backwards so that the holder of each block can be delegated its own slice of the tree.

That delegation is the point to understand before reading any result. The PTR record for an address is controlled by whoever holds the address block, usually an ISP, hosting company or large enterprise, not by the owner of the domain the name appears to belong to. A WHOIS or RDAP lookup shows who holds the block; the reverse DNS shows what that holder chose to publish for one address inside it.

A worked example: the PTR record for 8.8.8.8 is dns.google, and a forward lookup of dns.google returns 8.8.8.8 and 8.8.4.4. The name and the address point at each other, which is the condition described in the next section.

Most systems ship a resolver tool that can ask for a PTR record directly. On Linux and macOS, dig -x 203.0.113.10 performs the reverse query and prints the PTR answer; host 203.0.113.10 and nslookup 203.0.113.10 do the same with shorter output. On Windows PowerShell, Resolve-DnsName 203.0.113.10 -Type PTR returns the name under NameHost. The -x option is documented in the BIND 9 manual page for dig, which also shows how to query a specific resolver.

The addresses in these examples come from 203.0.113.0/24, a block reserved for documentation, so they return no record; a real address returns a hostname, an empty answer (NXDOMAIN or no PTR) or occasionally several PTR records, and the hostname field in an IP lookup tool is usually the result of this same query, so the same caveats apply to it.

Because the block holder can publish any text as a PTR record, a reverse name on its own is only a claim. It becomes a usable signal when the name also resolves forward to the same address: look up the PTR, then the A or AAAA record of the name it returns, and check that the original address is in the answer. This forward-confirmed reverse DNS is what mail receivers and crawler-verification procedures actually test.

RFC 1912, the IETF's catalogue of common DNS mistakes, puts the operator-side rule plainly: make sure your PTR and A records match, and for every address there should be a matching PTR record; it also notes that every Internet-reachable host should have a name. A PTR record that names someone else's domain but does not resolve back to the address fails this check and should be read as an inconsistency, not as evidence that the named organisation is involved.

A confirmed reverse name tells you how the block holder labels that address: mail servers, crawlers and corporate gateways often carry a deliberate, stable name such as a mail or crawl prefix on the operator's own domain, while consumer broadband, mobile and default hosting ranges usually carry a generated name that embeds the address itself or a pool identifier, because the provider names whole ranges rather than each customer.

Nothing standardises these conventions, so treat the pattern as context rather than a classification. RFC 8501, which describes the options an ISP has for reverse DNS on IPv6, shows how varied the practice is: a provider can return a negative response, publish a wildcard, generate names dynamically, or let customers update their own records. An address with no reverse name may simply sit in a range where the provider chose the first of those options.

Email is where reverse DNS has a formal role. Google's sender guidelines require that sending domains or IPs have valid forward and reverse DNS records, and that the sending IP address match the IP address of the hostname in its PTR record. A sending server without a matching PTR record is therefore treated as failing a basic configuration requirement before any content or reputation check runs.

For a mail operator that means publishing a PTR record that names the server's own hostname and making sure the hostname resolves back to the sending address; for anyone investigating a message, a sender whose reverse name is missing or generic is a reason to look at authentication results and blocklist status more closely, not a verdict on the message.

Reverse DNS is also the published way to tell a real search-engine crawler from a bot that merely copies its user agent. Google's procedure is a reverse lookup on the accessing address, a check that the returned name ends in googlebot.com, google.com or googleusercontent.com, and a forward lookup of that name that must return the same address; the forward step is the one that cannot be skipped, because a bot operator who controls a hosting block can publish a PTR record ending in googlebot.com for their own address but cannot make Google's name servers return that address for the name. Google also publishes its crawler address ranges as JSON files in CIDR format, and Bing documents how to verify Bingbot, so both methods are available when reading server logs for bot traffic.

Reverse DNS answers a narrow question: what name did the block holder publish for this address, and does it resolve back? It does not say who is using the address now, whether the host is compromised, or whether its traffic is wanted; a compromised server keeps its legitimate PTR record, and a missing record is normal on many residential and mobile ranges. Read it alongside the autonomous system and network type for what kind of network the address belongs to, an IP reputation check for recent abuse reports, and the request behaviour in your own logs; when those agree the reverse name usually explains why, and when they disagree it is the cheapest clue to start with.