---
title: "Pointer Record (PTR)"
description: "A PTR record (Pointer record) is a type of DNS record that maps an IP address to a domain name, used for reverse DNS lookup."
url: "https://mailmum.io/glossary/pointer-record-ptr/"
---

# 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)](https://mailmum.io/glossary/reverse-dns-rdns/) lookups possible.

This page covers the record itself &mdash; 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)](https://mailmum.io/glossary/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 &mdash; 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:

```txt
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:

```txt
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:

```txt
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:

* **Hosting provider or VPS** &mdash; the provider holds the address space and
  usually exposes a field in their control panel where you set the value
  yourself. This is the common case.
* **[ISP](https://mailmum.io/glossary/internet-service-provider-isp/) connection** &mdash; the
  ISP holds the block. You normally have to request the change through support,
  and on consumer connections it is often not offered at all.
* **Your own allocation from a RIR** &mdash; you run the reverse zone yourself
  and can set records directly.

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](https://www.rfc-editor.org/rfc/rfc2317), 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 &mdash; 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:

```sh
$ 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:

```sh
$ 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.

## Related reading

A missing PTR record is one of the setup errors described in
[discover mail system setup errors using MailMum
monitoring](https://mailmum.io/posts/discover-mail-system-setup-errors-using-mailmum-monitoring/),
alongside forgotten A records and typos in the HELO/EHLO name. For what
receiving servers do with the result, see
[reverse DNS (rDNS)](https://mailmum.io/glossary/reverse-dns-rdns/) and
[hostname](https://mailmum.io/glossary/hostname/).
