Reverse DNS (rDNS) is the DNS lookup that turns an IP address into a hostname. The answer is a PTR record, published under in-addr.arpa for IPv4 or ip6.arpa for IPv6 by whoever holds the address block.
An rDNS lookup is a single query: dig -x 66.249.66.1 returns crawl-66-249-66-1.googlebot.com. An rDNS check is that query plus a second one in the opposite direction, because the holder of an address can write any name they like into a PTR. Gmail runs the check on every server that hands it mail, and Google tells site owners to run it on anything claiming to be Googlebot. The commands come first below, then how to read the answers that are not a clean pass, then who gets to set a PTR at all. Every DNS answer shown was live on October 6, 2026.
An rDNS lookup is one command
The common resolver tools all accept an IP address and build the reverse query for you. On Linux and macOS that means dig -x or host. Windows ships nslookup, which prints the same answer as a Name: line.
dig -x 66.249.66.1 +short
crawl-66-249-66-1.googlebot.com.
host 66.249.66.1
1.66.249.66.in-addr.arpa domain name pointer crawl-66-249-66-1.googlebot.com.
nslookup 66.249.66.1
Name: crawl-66-249-66-1.googlebot.com
Address: 66.249.66.1The host output gives away what went over the wire. Nobody asks the DNS about 66.249.66.1. The question was a PTR query for the name 1.66.249.66.in-addr.arpa, built by the rule in section 3.5 of RFC 1035 (November 1987): write the four octets in reverse order and append in-addr.arpa.
The reversal is the whole trick. DNS delegates from the right of a name, addresses are allocated from the left, so flipping the octets lines the two hierarchies up. The zone 203.in-addr.arpa belongs to APNIC because APNIC administers 203.0.0.0/8, and each holder further down gets the labels to the left of that.
IPv6 reverses one hex digit at a time
RFC 3596 applies the same idea to IPv6 with one hexadecimal digit per label under ip6.arpa. The tools expand the address for you, which explains the wall of digits host prints.
dig -x 2001:4860:4860::8888 +short
dns.google.
host 2001:4860:4860::8888
8.8.8.8.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.6.8.4.0.6.8.4.1.0.0.2.ip6.arpa domain name pointer dns.google.Expect far fewer answers on IPv6. RFC 8501 works out what filling a single /48 with PTR records would take: at a thousand records written per second, "the zone would still not be complete after 38 trillion years". ISPs therefore return NXDOMAIN, serve a wildcard, or synthesize a name at query time.
The same lookup from a browser or an API
For one address without a terminal, our reverse DNS lookup tool runs the live query. In code, the Ipregistry API returns the PTR next to the network data when you add hostname=true. The field is off by default because returning a fresh hostname slows the response down, so ask for it only where you use it (the response below is trimmed to three fields):
curl "https://api.ipregistry.co/66.249.66.1?key=YOUR_API_KEY&hostname=true"
{
"connection": { "asn": 15169, "organization": "Google LLC", "type": "hosting" },
"hostname": "crawl-66-249-66-1.googlebot.com",
"ip": "66.249.66.1"
}An rDNS check adds the forward lookup
Anyone who controls a reverse zone can publish any name in it. If we set the PTR for an address in our own space to crawl-66-249-66-1.googlebot.com, nothing in the DNS refuses. What we cannot do is edit googlebot.com, Google's forward zone, and make that name resolve to our address.
Forward-confirmed reverse DNS (FCrDNS) uses that asymmetry. The procedure is short:
- Look up the PTR for the IP address.
- If you are verifying an identity, check that the returned name ends in the domain you expect, on a label boundary:
.googlebot.com, not any string that contains "googlebot.com". - Resolve that name forward, A for IPv4 or AAAA for IPv6.
- Pass if the original IP is among the answers.
Here it is for a Googlebot address, for one of Gmail's outbound mail servers, and for an IPv6 resolver. The last one returns two AAAA records, and one match is enough.
dig -x 66.249.66.1 +short
crawl-66-249-66-1.googlebot.com.
dig crawl-66-249-66-1.googlebot.com A +short
66.249.66.1
dig -x 209.85.220.41 +short
mail-sor-f41.google.com.
dig mail-sor-f41.google.com A +short
209.85.220.41
dig -x 2001:4860:4860::8888 +short
dns.google.
dig dns.google AAAA +short
2001:4860:4860::8888
2001:4860:4860::8844As a loop, for IPv4. It prints one line per PTR name that resolves back, and stays silent when there is no PTR or no name confirms:
ip=66.249.66.1
for name in $(dig -x "$ip" +short); do
dig "$name" A +short | grep -qxF "$ip" && echo "pass: $name"
doneRFC 8601 standardizes the check as the iprev method and names the outcomes: pass, fail when the two lookups disagree or the forward query returns nothing, permerror when no PTR is published, and temperror for a transient DNS failure.
A pass proves that the address holder and the domain holder agree. It says nothing about what the client intends to do.
Reading the results that are not a clean pass
No PTR means unknown
The lookup comes back NXDOMAIN, dig +short prints nothing, and iprev calls it permerror. This is the normal state of consumer IPv6 and of cloud addresses nobody bothered to configure. Treat it as missing information. A mail receiver can afford to reject on it because mail servers are expected to have a PTR. A web application that blocks on it will lock out ordinary users.
A generic name identifies the provider
Most PTRs that exist were generated in bulk. Hoang and colleagues, working from the Rapid7 reverse DNS dataset for the whole public IPv4 space (Assessing the Privacy Benefits of Domain Name Encryption, 2020), counted 1.27 billion addresses with a PTR record. At least 172 million of them, 14 percent, pointed at a meaningful hostname. The rest were names built from the address written out with dashes.
A generic name is still information. Ranges that carry names like static.1.0.9.5.clients.your-server.de (Hetzner) are datacenter space, one of the inputs to a hosting classification alongside the announcing ASN. It cannot tell two tenants of the same provider apart, and mail receivers read it as a bad sign. Yahoo's sender guidance is blunt: "Do not use a reverse DNS that looks like a dynamically-assigned IP instead of a static mail server."
Several PTRs are legal, so check each one
An address may carry more than one PTR record, and dig -x +short then prints several lines in no guaranteed order. Code that stops at the first line will fail correctly configured addresses. RFC 8601 says so directly, "The response to a 'PTR' query could contain multiple names", and to keep DNS load down it requires verifiers to limit how many of those names they chase. Try each one up to a small cap and pass if any of them confirms.
A mismatch is the only real failure
The PTR exists, and the name either does not resolve or resolves somewhere else. Forgery is the dramatic cause. The common ones are duller: a server was renumbered and the A record still points at the old address, or somebody filled in the provider's PTR form and never created the matching A record. Wildcard PTRs on IPv6 land here too, because one name cannot resolve back to every address in a /64.
Where the check decides something
Mail delivery
RFC 1912 said it in February 1996: "For every IP address, there should be a matching PTR record in the in-addr.arpa domain", and "Make sure your PTR and A records match." Thirty years on, Google's sender guidelines make it a condition of delivery for every sender, bulk or not. The sending server's public IP "must have a corresponding PTR record that resolves to a hostname", and that hostname must have an A or AAAA record "that resolves to the same public IP address used by the sending server". Yahoo asks for the same thing. The Rapid7 dataset shows the effect: Hoang and colleagues found more than 3 million PTRs with a mail prefix.
Crawler verification
A user agent is a string anyone can send. Google's verification page therefore prescribes exactly the four steps above, with googlebot.com, google.com and googleusercontent.com as the accepted domains. Bing has documented the same procedure since 2012 for names ending in search.msn.com: 157.55.39.1 answers msnbot-157-55-39-1.search.msn.com, which resolves back to 157.55.39.1.
Bot directories lean on it as well. On August 28, 2026, Cloudflare opened BotBase to crawler operators, promising to "fetch your IP list, confirm your reverse DNS, or validate your Web Bot Auth signature automatically". Cloudflare's IP validation documentation states the reverse DNS rule in one sentence, "If the reverse DNS of an IP resolves to one of the provided domains, Cloudflare considers it valid", with no mention of the forward step. We assume Cloudflare performs it and left it out of the page. If you build your own verifier, do not copy the short version.
The method has a limit that no amount of care fixes. A crawler on rented cloud capacity cannot set a PTR on egress addresses it shares with other tenants, which is why Cloudflare added signed requests in July 2025. And at volume, Google itself recommends matching against its published range files instead of DNS (our walkthrough of verifying Googlebot by IP covers them).
Log enrichment
Hostnames make logs readable, and router names often embed a city or airport code. Resolve them off the request path and cache the result: a PTR query against a broken reverse zone can hang for seconds, and a hostname in a log line was never worth that.
Whoever holds the block writes the PTR
This is the part that surprises people who have only ever edited forward zones. You can own example.com outright and have no say over what your server's address calls itself.
IANA manages the apex of both reverse zones and delegates each allocated /8 to the RIR that administers it. The RIR delegates on octet boundaries to its members: in the RIPE region a /17 to /24 gets one or more /24 zones, a /9 to /16 gets /16 zones, and each is a domain object with nserver attributes in the RIPE Database.
Hold a /24 or more and you get a reverse zone of your own. Hold a /29 from a business ISP and there is no label boundary at /29, so the ISP either edits its /24 zone on your behalf or uses the CNAME trick from RFC 2317 (March 1998): delegate an invented child zone, then alias each address into it.
; in the provider's zone 2.0.192.in-addr.arpa
0/25 NS ns.A.domain.
1 CNAME 1.0/25.2.0.192.in-addr.arpa.
2 CNAME 2.0/25.2.0.192.in-addr.arpa.On a cloud provider, the provider holds the zone and gives you a form. When there is no form, there is no PTR.
If you are not sure who to ask, the failed lookup tells you. Run dig -x without +short on an address that has no PTR and read the SOA record in the authority section. For 51.68.0.10 it names the zone 0.68.51.in-addr.arpa and the server dns10.ovh.net, so OVH is the party that can add the record. Create the forward A or AAAA record first, set the PTR second, then run the check from the top of this post against your own address before a mail receiver does it for you.
The PTR, the ASN and the connection type answer three different questions about the same address, and a verifier that keys on all three is far harder to fool than one that trusts any of them alone. Ipregistry serves them in a single response, and a free account comes with 20,000 lookups to get started.
Frequently asked questions
What is the difference between an rDNS lookup and an rDNS check?
An rDNS lookup is one query: ask for the PTR record of an IP address and read the hostname that comes back. An rDNS check, also called forward-confirmed reverse DNS or FCrDNS, adds a second query: resolve that hostname forward and confirm the original IP address is among the A or AAAA answers. Only the check proves anything, because the holder of an address can publish any name in a PTR.
How do I do an rDNS lookup from the command line?
Run dig -x followed by the IP address, or host followed by the IP address, on Linux and macOS. On Windows, nslookup followed by the IP address does the same. All three build the in-addr.arpa or ip6.arpa query name for you and work for both IPv4 and IPv6.
Why does my IP address have no rDNS record?
Because whoever holds the reverse zone for your address block has not published a PTR for it. That is your ISP or cloud provider unless you hold a /24 or larger yourself. Most consumer IPv6 addresses and many cloud addresses have no PTR at all, and a missing PTR is not a sign of abuse.
Can a PTR record be faked?
Yes. Anyone who controls the reverse zone for an address can make its PTR say googlebot.com or anything else. What they cannot do is make the real googlebot.com zone resolve that name back to their address, which is why a forward lookup is required before trusting the name.
Is rDNS required for sending email?
In practice, yes. Google's sender guidelines require every sending server's public IP to have a PTR record, and the hostname in it must resolve back to the same IP. Yahoo asks for valid forward and reverse DNS as well, and advises against generic names that look like dynamically assigned addresses.
Keep users in the loop Ship release notes that get read. Try Noticeable