Reverse DNS Lookup

DNS is organised by name, so to look something up by address the address has to be turned into a name. RFC 1035 defined the in-addr.arpa zone for this. The four octets of an IPv4 address are written in reverse order and in-addr.arpa is appended, so 8.8.8.8 becomes 8.8.8.8.in-addr.arpa and 203.0.113.5 becomes 5.113.0.203.in-addr.arpa. The reversal puts the most significant part of the address at the right, where DNS keeps the most significant part of a name, so that a whole /24 can be delegated as the single zone 113.0.203.in-addr.arpa.

IPv6 uses ip6.arpa, defined in RFC 3596, and reverses the address one hexadecimal nibble at a time. The address is first expanded to its full 32 digits, then each digit becomes a label. So 2606:4700:4700::1111 becomes 1.1.1.1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.7.4.0.0.7.4.6.0.6.2.ip6.arpa, which is 34 labels long. Our reverse DNS lookup shows the exact query name it sent for either family.

The record type stored at that name is PTR, and its value is a hostname. The in-addr.arpa and ip6.arpa trees are delegated from the regional internet registries down to whoever holds each address block, which is why the PTR record for your server is set at your hosting provider and not in the zone for your domain.

Forward-confirmed reverse DNS (FCrDNS) is the check that the PTR record and the forward record agree. A lookup of the IP returns a hostname, a lookup of that hostname returns a set of addresses, and the original IP must be among them. When it is, the address has a name that its owner and the domain owner both vouch for. When it is not, the PTR is just a string that the network owner typed in.

The check matters because the two records are controlled by different people. The network owner can put any name in a PTR record, including mail.google.com. Only the owner of google.com can make mail.google.com resolve back to that address. Our lookup resolves every PTR name it receives and reports the address as forward-confirmed when any of them points back at the queried IP.

The owner of the address block, which in practice means your hosting or cloud provider, or your ISP. Your registrar and your DNS provider have nothing to do with it, and adding a PTR record to your own zone file does nothing, because resolvers never look there. Where to find the setting depends on the provider:

• AWS. On an Elastic IP, through the reverse DNS setting on the address, after the forward record exists. Port 25 also needs to be unblocked by request.
• Google Cloud. On the reserved external address, as a PTR record field, again after the forward record resolves to it.
• Azure. On the public IP resource, under configuration, as the reverse FQDN.
• Hetzner, DigitalOcean, Linode, Vultr and most VPS hosts. In the server or networking panel, often labelled rDNS. DigitalOcean sets it automatically from the droplet name if that name is a valid hostname.
• Business ISPs. On request, for static addresses only. Consumer connections almost never allow it, which is one reason mail from them is refused.

Most providers require the forward record to exist before they will accept the PTR, so create the A or AAAA record first, wait for it to resolve, then set the PTR.

A receiving mail server sees the IP address of the connecting server before anything else, and the PTR record is the first thing it looks up. Google's sender guidelines require every sending IP to have a PTR record that resolves forward to the same address, and Gmail rejects mail from addresses without one with a 550 5.7.25 error. Microsoft and Yahoo apply the same check as a reputation signal. Spam filters go further and score down generic names such as 5.113.0.203.dynamic.example.net, because they look like consumer connections rather than mail servers.

The name in the PTR should ideally be the same hostname the mail server announces in its HELO or EHLO command, and the same name that appears in the MX record. All three matching is what receivers interpret as a properly run server. Our SMTP test checks the PTR of every MX host it connects to and warns when it does not match the MX hostname.

The -x flag builds the in-addr.arpa or ip6.arpa name for you and asks for the PTR record. To see the forward confirmation, look up the name that comes back.

$ dig -x 8.8.8.8 +short
dns.google.

$ dig -x 2606:4700:4700::1111 +short
one.one.one.one.

$ dig A dns.google +short
8.8.8.8
8.8.4.4

# the same query without -x, spelled out
$ dig PTR 8.8.8.8.in-addr.arpa +short
dns.google.

On Windows, nslookup 8.8.8.8 performs the same lookup and prints the name. On macOS and Linux, host 8.8.8.8 does the same with less output.