PTR Records and Reverse DNS Explained

A PTR record stores a single piece of information: the hostname associated with an IP address. When a resolver performs a reverse lookup — handing DNS an IP and asking "what name belongs to this?" — the answer comes from a PTR record.

It is the exact reverse of forward resolution. An A record says mail.example.com → 198.51.100.10. The matching PTR record says 198.51.100.10 → mail.example.com. The two are stored in completely different places and are maintained independently, which is why they can — and sometimes do — disagree.

PTR records hold names, not addresses. Each reverse entry points at one hostname (the canonical name for that IP).

Reverse DNS is the process of resolving an IP address to a hostname using PTR records, as opposed to forward DNS, which resolves a hostname to an IP using A/AAAA records.

DNS is fundamentally a system for looking things up by name, so reverse lookups need a clever trick: the IP address is turned into a specially formatted name that lives inside a dedicated part of the DNS tree. Ask for the PTR record of that constructed name, and you get the hostname back. The next sections show exactly how that name is built.

Reverse lookups live under two special top-level zones reserved for this purpose:

• in-addr.arpa — used for IPv4 reverse DNS.
• ip6.arpa — used for IPv6 reverse DNS.

To look up an IP's PTR record, the address is first rewritten as a hostname inside one of these zones. The rewrite reverses the order of the address so that DNS's most-significant-on-the-right hierarchy lines up correctly: in a normal name like mail.example.com the broadest label (com) is on the right, so the address has to be flipped to match.

For IPv4, you take the four octets of the address, reverse their order, and append .in-addr.arpa. Take the address 198.51.100.10:

1. Split into octets: 198, 51, 100, 10.
2. Reverse the order: 10, 100, 51, 198.
3. Append the zone: 10.100.51.198.in-addr.arpa.

The resolver then asks for the PTR record at 10.100.51.198.in-addr.arpa, and the answer is the hostname for 198.51.100.10 — for example mail.example.com. Every IPv4 reverse lookup follows this same flip-and-append pattern.

IPv6 uses the same idea but at finer granularity. The address is first fully expanded (no :: shorthand, no dropped leading zeros) into its 32 hexadecimal digits. Each digit — called a nibble (4 bits) — becomes its own label, the whole sequence is reversed, and .ip6.arpa is appended.

So an IPv6 address in the documentation range 2001:db8::/32 expands to 32 hex digits, which are then written out one per label in reverse order, ending in .ip6.arpa. The principle is identical to IPv4 — broadest part on the right, address reversed — just applied nibble by nibble because IPv6 addresses are much longer.

This is the part that surprises people. You do not set PTR records in your domain's forward DNS zone. They are controlled by whoever holds the IP address block — typically your hosting provider or ISP, who in turn received the block via delegation from a Regional Internet Registry (RIR).

Authority over the reverse zone follows the IP allocation, not the domain name. The owner of example.com can publish all the A and AAAA records they like, but the PTR record for 198.51.100.10 can only be set by the party that controls the 198.51.100.0/24 reverse zone.

In practice this means you usually request a PTR record rather than self-serve it: you ask your hosting provider or ISP to point the reverse record for your IP at the hostname you want. Some providers expose a control-panel field for it; others require a support request. RIR delegation can also push reverse authority down to you for a larger block you control, but for a single server IP it almost always runs through the provider.

Reverse DNS is most consequential for outbound email. Many receiving mail servers treat a sending IP with no valid PTR record as a strong spam signal, and some refuse the connection outright. A legitimate mail server is expected to have proper reverse DNS; a missing or generic PTR (the kind ISPs auto-assign to residential IPs) is a classic marker of spam sources.

Stricter receivers go a step further and check forward-confirmed reverse DNS (FCrDNS). The receiver takes the connecting IP, looks up its PTR record to get a hostname, then resolves that hostname's A/AAAA record and confirms it points back to the same IP. Only if the round trip matches does the IP pass. So for mail it is not enough to have any PTR — the PTR's hostname must resolve forward to the exact IP that is sending.

If you run your own mail server, getting the PTR right (and matching it with a forward A/AAAA record) is one of the basic requirements for reliable delivery, alongside SPF, DKIM, and DMARC.

Beyond email, reverse DNS makes the network more legible to humans:

• Logs. Server and firewall logs can resolve client IPs to hostnames, so a log line reads as a recognizable name instead of a bare number.
• Troubleshooting. When you are diagnosing a connection, a PTR record tells you at a glance who an address belongs to — a provider, a data center, a known service.
• Traceroute readability. Each hop in a traceroute or mtr is shown by its reverse DNS name, which is how you can tell which networks and cities a path crosses rather than staring at raw IPs.

None of these are strictly required for the internet to function, but reverse DNS is what turns opaque addresses into meaningful names across all of them.

Forward and reverse DNS are independent systems with separate owners. Forward records (A/AAAA) live in the domain's zone, controlled by the domain owner. Reverse records (PTR) live in the in-addr.arpa / ip6.arpa zones, controlled by the IP block holder. Nothing automatically keeps them in sync.

Because of that, they can legitimately differ. One IP may host several websites, each with its own A record, while the IP has a single PTR pointing at just one canonical hostname. Or a forward record may have been updated while the provider's reverse record still points at an older name. A mismatch is not necessarily an error — but for email it matters, which is exactly why FCrDNS checks the round trip rather than trusting either direction alone.

You can see the PTR record and ownership for any IP with the who.is IP lookup tool. Enter an IPv4 or IPv6 address and it returns the reverse DNS (the hostname from the PTR record) alongside who holds the address block — the provider or network that controls that IP's reverse zone.

This is the quickest way to confirm a mail server's reverse DNS is set, spot a missing or generic PTR before it hurts deliverability, or identify the owner of an address you see in your logs. To cross-check the forward direction, run the hostname through the DNS lookup tool and confirm its A/AAAA record points back to the same IP — that is the FCrDNS round trip, by hand.