What Is Reverse DNS? PTR Records Explained

Ordinary DNS answers "which address belongs to this name?". Reverse DNS answers the opposite question: "which name belongs to this address?". The record that holds the answer is the PTR record. It is a small thing that matters in a few places (mail delivery above all), and it confuses people because it does not live in your domain's zone and you usually cannot set it in your DNS panel.

How reverse DNS works

DNS can only look up names, so an IP address has to be turned into a name first. For IPv4 the four octets are reversed and .in-addr.arpa is appended:

192.0.2.25   →   25.2.0.192.in-addr.arpa.

The reversal puts the most significant part on the right, as in every domain name, which makes delegation possible: whoever is responsible for 192.0.2.0/24 runs the zone 2.0.192.in-addr.arpa and can publish a record for each address in it:

25.2.0.192.in-addr.arpa.   3600   IN   PTR   mail.example.com.

For IPv6 the address is written out in full, reversed one hexadecimal digit (nibble) at a time, under ip6.arpa:

2001:db8::25   →
5.2.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.8.b.d.0.1.0.0.2.ip6.arpa.

You never type this by hand; dig -x builds the name for you:

$ dig +short -x 192.0.2.25
mail.example.com.
$ dig +short -x 2001:db8::25
mail.example.com.

host 192.0.2.25 and nslookup 192.0.2.25 do the same.

Who controls the PTR record

The reverse tree follows address allocation, not domain ownership. The regional internet registries (RIPE NCC, ARIN, APNIC, LACNIC, AFRINIC) delegate reverse zones to the organisations that hold address blocks (ISPs, hosting and cloud providers), and they decide how customers may set PTR records.

Consequences:

Adding a PTR record to the zone of example.com does nothing. Nobody will ever query it there.
VPS or dedicated server: most providers have a "reverse DNS" field for each IP in their control panel. Many require the forward record to exist first.
Cloud platforms: usually supported for static/reserved addresses, sometimes only through an API call or a support request, and sometimes not for outbound mail at all.
Home or office connection: the ISP sets it. Business lines with a static IP can often get a custom PTR on request; residential lines generally cannot.
Shared hosting: the address is shared by many sites and the PTR names the hosting company's server. This is normal and nothing to fix.
Your own address block: you run the reverse zone yourself, or have it delegated. For blocks smaller than a /24, where a whole in-addr.arpa zone cannot be delegated along octet boundaries, providers use the CNAME-based technique from RFC 2317.

To see who to ask, look up who holds the address; see how to find where a website is hosted.

Forward-confirmed reverse DNS

A PTR record alone proves little, because whoever controls the reverse zone can write any name into it, including mail.yourbank.example. What receivers actually check is whether the two directions agree:

IP → PTR → a name
that name → A/AAAA → the same IP

$ dig +short -x 192.0.2.25
mail.example.com.
$ dig +short mail.example.com A
192.0.2.25

If the loop closes, this is called forward-confirmed reverse DNS (FCrDNS). It shows that the person controlling the address and the person controlling the name cooperate, which is a modest but real signal.

Why it matters for email

Mail receivers have used reverse DNS as a spam filter input for decades, because a machine with no PTR, or with a generic one like host-192-0-2-25.dynamic.isp.example, is far more likely to be an infected home computer than a mail server. Large mailbox providers state in their sender guidelines that sending IPs must have valid forward and reverse DNS; without it, expect rejections or deferrals with messages mentioning "PTR record" or "reverse DNS".

For a mail server, line up three names:

Thing	Should be
PTR of the sending IP	`mail.example.com`
`A`/`AAAA` of `mail.example.com`	the sending IP
Name in the SMTP greeting (`HELO`/`EHLO`)	`mail.example.com`

The PTR does not have to match the domain in the From address. A server mail.hosting.example can send for hundreds of customer domains; aligning those is the job of SPF, DKIM and DMARC, explained in MX, SPF, DKIM and DMARC.

If you send through an email service provider or a hosted mailbox service, the sending IPs are theirs, and so is the PTR. There is nothing for you to configure.

IPv6 deserves a specific warning: if your server has an IPv6 address, it will often prefer it for outgoing mail, and receivers tend to be stricter about PTR on IPv6. Either set PTR and AAAA for that address too, or make the mail server send over IPv4 only.

Other places you meet PTR records

traceroute and mtr show router names from PTR records, which often reveal the network and city of each hop.
Logs and security tools resolve client addresses to names. Treat those names as hints; they are controlled by the other side.
Access rules based on reverse DNS (for example "allow *.crawler.example") are only safe if the software forward-confirms the name. That is how search engines recommend verifying their crawlers.
Some SSH and FTP servers do a reverse lookup on each connection; a broken reverse zone shows up as a delay of several seconds at login (UseDNS in OpenSSH).

What a PTR record does not tell you

Not which websites run there. One IP can host thousands of sites; the PTR is a single name chosen by the address holder. "Reverse IP" services that list domains on an address use their own collected data, not PTR records.
Not who owns the server. server42.hosting.example tells you the hosting company. The registration data of the address block tells you the same, more reliably.
Not where it is. Airport codes in router names are hints at best.
Nothing, quite often. Many addresses have no PTR at all. For a web server that is harmless.

Setting it up: a checklist

Choose a hostname in a domain you control: mail.example.com. Avoid the bare domain and names that already serve another purpose.
Create the forward record first: mail.example.com A 192.0.2.25 (and AAAA if applicable).
Set the PTR in the provider's panel, or ask the provider or ISP to set it, to exactly that hostname.
Configure the mail server to introduce itself with the same name (myhostname in Postfix, for example).
Verify both directions with dig, for IPv4 and IPv6.
Allow for the TTL of the old PTR before judging the result. How caching works is described in what is TTL in DNS.

Common mistakes

Creating a PTR record in the forward zone and wondering why nothing changes.
A PTR pointing to a name that does not resolve, or resolves to a different IP.
Several PTR records on one address. It is legal, but many checks take only one of them, unpredictably. Use exactly one.
Leaving the provider's generic default PTR on an address that sends mail.
Setting up IPv4 carefully and forgetting that the server also sends over IPv6.
Changing the server's IP and updating only the forward record.
Reading a PTR as proof of identity. Without forward confirmation it proves nothing.

Check it with OrbitProbe

The OrbitProbe IP lookup resolves a hostname to its IPv4 and IPv6 addresses and shows, for each address, the reverse DNS name together with the autonomous system and the network owner. Enter your mail server's hostname: if the reverse name shown for each address is the hostname you entered, the loop is closed. If the reverse name is missing or generic, the network owner shown next to it is the organisation that can change it.