Reverse DNS (PTR): from IP address to name

Normal DNS asks "what is your address?". Reverse DNS asks the address "and who are you, exactly?".

The short answer

Reverse DNS turns an IP address back into a name. It uses PTR records (pointer records) stored under special domains: in-addr.arpa for IPv4 and ip6.arpa for IPv6 [1][2]. Who can set such a record? The party that controls the address block, which for a home connection is usually your provider, not you. Our assessment: you mainly care about reverse DNS when a server sends mail or when you want readable names in logs.

How it works

1. The reversed address. For IPv4 the octets are written in reverse order and followed by in-addr.arpa. RFC 1035 gives the example of the address 10.2.0.52 and the name 52.0.2.10.IN-ADDR.ARPA [1]. The PTR record at that name holds the host name.
2. IPv6 uses nibbles. For IPv6, RFC 3596 defines the domain ip6.arpa, with the address written as reversed hexadecimal digits separated by dots [2]. The names get long, which is why tools hide the work.
3. Who controls it. The records sit in a zone that belongs to whoever received the address block, so a provider sets them for its customers. For blocks smaller than a /24, RFC 2317 describes how the parent zone delegates the reverse lookups [3]. Our assessment: at home, check your provider's portal or ask support whether it offers a PTR setting for your address.
4. Forward and back must agree. Google's sender requirements, quoted by a UK government blog, say that every sending IP address must map to a host name in a PTR record, and that this host name must resolve forward to the sending address [4]. The same post notes that a missing PTR does not always cause rejection, but adds to the spam score [4]. The sender requirements of other mail providers are unverified here.
5. Not a proof of identity. A PTR record only shows that whoever controls the address block published a name. Our assessment: use it as one signal among several, not as a login.
6. Logs and tools. Many tools resolve addresses to names for readable logs. A failing or slow reverse lookup can make such tools wait, so a missing PTR can show up as lag, not as an error.

A homelab example

The Bytearium homelab runs rack servers (HPE ProLiant DL360 Gen9 and DL380 Gen10) and a QNAP NAS, as of 14 to 18 Oct 2026. We have not recorded PTR records for our addresses, so we say nothing about them. A general example for your own line: read your public IPv4 address from your router, then ask for its name with dig -x <your-address> +short [5]. An empty answer means no PTR record is published. A generic provider name, often built from the address, means the provider has set a default. Whether the answer matches a name you control is the thing to compare. If you plan to send mail from home, read the postmaster pages of the receiving providers first, and expect that a home address range may be treated with suspicion (our assessment, unverified for specific providers).

Checklist

• Read your public address and note the date.
• Run dig -x <address> +short and write down the answer.
• Check whether the returned name resolves back to the same address.
• Ask your provider whether you can set the PTR record yourself.
• Check the sender requirements of the mail providers you want to reach.
• Avoid assuming that a PTR record proves who runs a server.
• Repeat the check after the provider changes your address.