PTR

A PTR record (pointer record) is the DNS resource record that maps an IP address back to a hostname, which makes it the foundation of reverse DNS lookups. Among DNS records, it is the counterpart of the A record and the AAAA record: those answer “which address does this name have”, while a PTR answers “which name belongs to this address”.

PTR records live in special reverse zones under the in-addr.arpa domain for IPv4 and the ip6.arpa domain for IPv6. They are usually controlled by whoever holds the address block, typically an internet service provider, a hosting company or a cloud platform, rather than by the owner of the forward domain name. That ownership split explains most of the practical difficulties administrators meet with reverse DNS.

How a PTR record resolves an address to a name

A PTR lookup works by turning the address into a domain name and then querying that name like any other. For IPv4, the four octets are written in reverse order and the suffix in-addr.arpa is appended, so the address 192.0.2.25 becomes 25.2.0.192.in-addr.arpa. The resolver then asks for the record of type PTR at that name, and the answer is a fully qualified hostname such as mail.example.com..

The reversal is deliberate. DNS delegates authority from right to left, while IP addresses are allocated from left to right, from large blocks to small ones. Reversing the octets lets the holder of 198.51.100.0/24 receive a delegation for 100.51.198.in-addr.arpa and manage every PTR inside it, exactly as a domain owner manages a forward zone.

IPv6 uses the same idea at a finer grain. The 128-bit address is expanded to 32 hexadecimal nibbles, each nibble becomes one label, and the labels are reversed under ip6.arpa. The resulting names are long, but delegation can follow any nibble boundary, which suits the usual /32, /48 and /64 allocations.

The table below shows how the query name is built for both address families.

Anatomy of a PTR record and its parameters

A PTR record has the same five-part structure as other DNS records: owner name, TTL, class, type and data. Its data field holds exactly one domain name, never an address. A typical entry in a reverse zone file reads 25 3600 IN PTR mail.example.com., where the owner name is relative to the zone origin.

The standards allow several PTR records for one address, but this is a poor practice. Many applications read only the first answer, the order is not guaranteed, and some mail filters treat multiple pointers as suspicious. The safe rule is one PTR per address, pointing to one canonical name.

Reverse zones usually tolerate longer TTL values than forward zones because address-to-name mappings change rarely. A TTL of one day is common; lowering it to a few minutes is only useful shortly before a planned change of the hostname.

Forward-confirmed reverse DNS

A PTR record alone proves nothing, because anyone who controls a reverse zone can claim any hostname. The holder of an address block could publish a PTR that says bank.example.com without owning that domain. For this reason, serious consumers of reverse DNS perform forward-confirmed reverse DNS, often abbreviated FCrDNS.

The check has two steps. First, the receiver looks up the PTR of the connecting address and obtains a hostname. Second, it resolves that hostname forward with an A or AAAA query. The result is trusted only when the forward answer contains the original address. Because the forward zone belongs to the domain owner, a match shows that both parties agree on the mapping.

Comparing PTR with its forward neighbors helps clarify its role in the record family.

Where PTR records matter in practice

The most demanding consumer of PTR records is email delivery. Most large mailbox providers reject or heavily penalize messages from a sending IP that has no PTR record, and many also require that the PTR passes forward confirmation. A generic name such as host-192-0-2-25.dynamic.isp.example often looks like a residential connection and triggers spam filtering.

• Mail servers: a valid, forward-confirmed PTR is a baseline requirement, and the name should match or relate to the SMTP HELO greeting.
• Network diagnostics: tools such as traceroute and ping display readable router names instead of bare addresses, which often reveal location and provider.
• Logging and auditing: web and firewall logs can be enriched with hostnames, although doing it at write time slows logging.
• Access control: some legacy services restrict clients by hostname, which is only safe with forward confirmation.

The decision table below summarizes what an operator should do in common situations.

Common mistakes and limitations

The most frequent mistake is editing the PTR in the wrong place. Adding a PTR to the forward zone of example.com has no effect, because resolvers query the .arpa zone, not the domain. Unless the reverse zone has been delegated, the change must go through the provider that holds the address block.

A second class of problems comes from inconsistency over time. When a server moves to a new address, administrators often update the A record but forget the PTR, which breaks forward confirmation and silently harms email reputation. Reverse zones are also frequently left without DNSSEC signing, so PTR answers deserve less trust than signed forward data.

Finally, reverse DNS is not a security boundary. It identifies a host only as far as the address holder is honest, it can lag behind real assignments, and large IPv6 ranges are rarely populated with individual PTRs. Some operators synthesize IPv6 PTRs on the fly instead of storing billions of entries.

The short version

Most of the time, the internet’s naming system works like a phone book: you know a name and look up the number. A PTR record is the reverse phone book. You start with a number, the IP address, and ask which name belongs to it.

The catch is that the reverse book is kept by whoever owns the numbers, usually the internet or hosting provider, not by the owner of the name. That is why a server owner often has to ask the provider to set it. When both books agree, other systems, especially email services, treat the server as more trustworthy.

Where it makes a difference

A small company moves its outbound mail server to a new cloud virtual machine with the address 203.0.113.40. It updates the A record for mail.example.com and the SPF policy, yet within a day many recipients report that messages land in spam and one large provider rejects them outright with a note about missing reverse DNS.

The administrator checks the address and finds that its PTR still points to the provider’s generic name. Because the cloud provider owns the reverse zone, the fix is made in the provider’s console: the PTR for 203.0.113.40 is set to mail.example.com. A forward lookup of that name already returns 203.0.113.40, so forward confirmation now succeeds.

After the resolver caches expire, typically within an hour, the rejections stop and delivery rates return to normal. The team adds a PTR check to its server migration checklist so the same gap does not appear on the next move.