Reverse DNS Lookup

Forward DNS maps a name to an address: example.com to 93.184.216.34. Reverse DNS runs the other direction, mapping an address back to a name via a PTR (pointer) record. Unlike A/AAAA records, PTR records do not live under the domain itself - they live in a special reverse zone controlled by whoever holds the IP block, which in practice usually means the hosting provider or ISP, not the website owner.

This split matters: you can set every A record you want on your own domain, but you cannot create a PTR record for an IP you do not control the reverse zone for. Getting reverse DNS changed almost always means opening a ticket with the provider that assigned the address, not editing a zone file yourself.

• PTR records resolve IP → hostname, the reverse of A/AAAA
• They live in the in-addr.arpa (IPv4) or ip6.arpa (IPv6) zone, not the forward domain zone
• The zone is controlled by the IP block holder - usually a hosting provider or ISP
• A single IP can only have PTR records pointing to one canonical name in practice, even though the RFC permits multiple

RFC 1035 defines the reverse-lookup mechanism using a special domain, in-addr.arpa, built by reversing the octets of an IPv4 address and appending the suffix. The address 8.8.8.8 becomes the query name 8.8.8.8.in-addr.arpa. Reversal happens because DNS delegates zones most-significant-label-last: reversing the octets puts the coarsest part of the address space (the first octet) at the end of the name, matching how domain names delegate from right to left.

IPv6 uses the same idea under ip6.arpa, defined in RFC 3596, but at the nibble level instead of the octet level. Each hex digit (nibble) of the 128-bit address is reversed and dot-separated. The address 2001:4860:4860::8888 expands to its full 32-nibble form and then reverses to a query name ending in .ip6.arpa - considerably longer than the IPv4 case, and the reason IPv6 PTR zones are almost always managed through automation rather than by hand.

This tool queries the PTR record for the IP you enter and shows the resolved hostname alongside the query time and timestamp. A successful lookup returns one or more PTR values - the hostname(s) registered against that address in the reverse zone. An empty result means no PTR record exists for that IP, which is common and not inherently a problem: plenty of legitimate hosts have no reverse DNS configured at all.

Private IP ranges (10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16, and their IPv6 equivalents) are blocked from lookup since they have no meaningful public reverse zone and querying them leaks nothing useful. If your input is not a valid IPv4 or IPv6 literal, the tool rejects it before querying rather than returning a misleading empty response.

Reverse DNS matters most in email delivery. Most mail servers, including the major providers, perform a PTR lookup on the connecting IP during the SMTP handshake and treat missing or mismatched reverse DNS as a strong spam signal. A mail server sending from an IP with no PTR record, or one that resolves to something generic like a raw ISP hostname, is far more likely to be greylisted, rate-limited, or rejected outright - regardless of what the sending domain's SPF or DKIM records say.

The practical rule for anyone running outbound mail infrastructure: set a PTR record for the sending IP before sending any real volume, and make sure it resolves to a hostname that looks like it belongs to the sending domain or organization, not a generic hosting-provider default.

Forward-confirmed reverse DNS, sometimes called "full-circle" or "iprev" verification, goes one step further than a plain PTR lookup. The receiving server takes the IP, resolves its PTR record to get a hostname, then resolves that hostname forward (A or AAAA) and checks whether the result includes the original IP. If it does, the reverse and forward records agree, and the IP is treated as having a verified, consistent identity - a much stronger signal than a PTR record alone, since PTR records can be set to arbitrary values by whoever controls the reverse zone.

FCrDNS does not replace SPF, DKIM, or DMARC, but many receiving mail systems fold it into their overall reputation scoring. RFC 8601 formalizes this as the "iprev" authentication method reported in Authentication-Results headers, alongside SPF and DKIM outcomes. A mismatch there does not guarantee spam, but a consistent match is one more piece of evidence that the sending infrastructure is what it claims to be.