Reverse DNS Lookup

Reverse DNS maps addresses back to names using ordinary DNS delegation under special domains. For IPv4, RFC 1035 section 3.5 defines in-addr.arpa: the four octets are written in reverse order, so 192.0.2.25 becomes 25.2.0.192.in-addr.arpa. For IPv6, RFC 3596 defines ip6.arpa with one label per hexadecimal nibble, also reversed, so 2001:db8::25 becomes a 32-label name ending in ...8.b.d.0.1.0.0.2.ip6.arpa. The record found at that name is a PTR (type 12), for example 25.2.0.192.in-addr.arpa. 3600 IN PTR mail.example.com. Reversing the order puts the network part on the right, matching DNS's right-to-left hierarchy so that address blocks can be delegated like domains.

That delegation follows address allocation, not domain ownership. The regional internet registries (ARIN, RIPE NCC, APNIC, LACNIC, AFRINIC) delegate reverse zones to the networks they assign space to, which then delegate further or host the PTRs themselves. As a result, the PTR for an IP is controlled by whoever owns or leases the address, usually your ISP, cloud provider or hosting company, and never by the registrar of your domain. On cloud platforms you typically set it in the console for an elastic or static IP; with an ISP or colocation provider you open a ticket. Blocks smaller than a /24 cannot be delegated on octet boundaries, so RFC 2317 describes classless delegation using CNAMEs from the parent reverse zone into a customer-controlled zone.

A PTR on its own proves little, since anyone controlling a reverse zone can claim any name. Receivers therefore use forward-confirmed reverse DNS (FCrDNS): look up the PTR, resolve that name forward with A or AAAA, and check that the original IP is in the result. Google's sender guidelines require valid forward and reverse DNS for sending IPs, and many receivers reject or penalize mail that fails FCrDNS or whose PTR looks dynamic. The best practice for a mail server is a single PTR naming a host inside a domain you control, for example mail.example.com, with a matching A/AAAA record and the same name used in the SMTP HELO/EHLO greeting and the TLS certificate.

Beyond mail, RFC 1912 recommends that every internet-reachable host have consistent reverse and forward records, and some services such as SSH logging, older FTP daemons and network monitoring perform reverse lookups on every connection, adding latency when the reverse zone is slow or lame. Reverse DNS is also a useful but not authoritative signal: names are chosen by the address owner and can be stale or deliberately misleading, so treat them as hints and corroborate with WHOIS, ASN and geolocation data.