Pointer Record (PTR)

A PTR record (Pointer record) is a type of DNS record used to map an IP address to a domain name (e.g. 127.0.0.1 -> localhost). It is the record type that makes reverse DNS (rDNS) lookups possible.

This page covers the record itself — where it lives, how it is constructed, and who controls it. For why a mail server needs one and what happens when it is missing, see reverse DNS (rDNS).

Where does a PTR record live?

A PTR record is not stored in the zone of the domain it points to. It lives in a special reverse zone derived from the IP address itself, and it is controlled by whoever holds the address space — not by whoever owns the domain name.

That is the most important practical consequence: you cannot add a PTR record for your mail server in your own DNS zone file. You have to ask the party that controls the IP address.

For IPv4, the zone is in-addr.arpa and the octets of the address are reversed:

212.227.15.4  ->  4.15.227.212.in-addr.arpa

For IPv6, the zone is ip6.arpa. The address is expanded to its full form and every nibble (single hex digit) is reversed and separated by a dot, which makes for a considerably longer name:

2001:db8::1  ->  1.0.0.0. ... .0.0.8.b.d.0.1.0.0.2.ip6.arpa

The record itself is then an ordinary DNS entry pointing at a hostname:

4.15.227.212.in-addr.arpa.  3600  IN  PTR  mout.web.de.

Note the trailing dot on the target: a PTR record must point to a fully qualified domain name.

Who controls the PTR record for my server?

Control follows the IP address block, so it depends on how you obtained it:

If you have been delegated a block smaller than a /24, the reverse zone cannot be split on a byte boundary. Providers handle this with the CNAME-based delegation scheme described in RFC 2317, which is why a reverse lookup on such an address sometimes shows a CNAME pointing at an oddly-named zone before resolving to the PTR record.

Can one IP address have multiple PTR records?

Technically yes — DNS permits multiple PTR records for the same address. In practice you should publish exactly one for a mail server.

Multiple PTR records make the result of a reverse lookup non-deterministic: different queries can return the answers in a different order, and a receiving mail server checking your identity may not get the name you expected. Since that check often decides whether your mail is accepted, the ambiguity is not worth it.

How can I check a PTR record?

Use dig to query the record. First look up the address of a mail server:

$ dig a mout.web.de +short
212.227.15.4
217.72.192.78
212.227.17.12

Then query the PTR record for one of those addresses. The -x flag builds the in-addr.arpa name for you:

$ dig -x 212.227.15.4

;; QUESTION SECTION:
;4.15.227.212.in-addr.arpa.	IN	PTR

;; ANSWER SECTION:
4.15.227.212.in-addr.arpa. 82994 IN	PTR	mout.web.de.

The forward lookup and the reverse lookup agree here: the hostname resolves to the address, and the address resolves back to the same hostname. That round trip is called forward-confirmed reverse DNS, and it is what receiving mail servers actually test. A PTR record pointing to a hostname that does not resolve back to the same address will fail that check even though the PTR record itself exists.

What should the PTR record point to?

It should point to the hostname the mail server uses to identify itself in the SMTP HELO/EHLO greeting, and that hostname should have a matching forward record back to the same IP address.

Generic names assigned automatically by hosting providers, of the kind that embed the IP address itself, are a common source of trouble. Some receiving systems treat them as an indication of dynamic or residential address space and score the connection accordingly, or refuse it outright.