All posts
June 12, 20266 min read

Reverse DNS and PTR records explained

Normal DNS goes one way: you give it a name like mail.example.com and it hands back an IP address. Reverse DNS goes the other way. You give it an IP address and it tells you the hostname that the owner of that address has chosen to publish for it. The two directions are independent. Having a forward record does not create the reverse one, and the reverse answer can point anywhere the address owner likes, so it is a claim rather than a proof on its own.

PTR records and the in-addr.arpa zone

Reverse lookups are stored in their own special zone rather than alongside a domain's other records. For IPv4 this zone is in-addr.arpa, and the record type that holds the answer is a PTR, short for pointer.

The trick is that the IP address is reversed and turned into a name. To look up the hostname for 203.0.113.5, a resolver queries the PTR record at:

5.113.0.203.in-addr.arpa

The octets are written backwards because DNS reads names from most specific on the left to least specific on the right, while IP addresses are written most general first. Reversing them lets a network owner delegate control of their address block the same way a domain owner controls a subdomain. IPv6 uses the same idea under ip6.arpa, with each hex digit reversed and separated by dots.

A key consequence: you do not set your own PTR record. Reverse DNS for an address is controlled by whoever holds that IP block, normally your hosting provider or ISP. To set a custom PTR you usually request it through them.

Why mail servers care

Reverse DNS matters most for email. When a sending server connects to deliver a message, the receiving server can see the connecting IP address and look up its PTR record. A missing reverse record, or one that still shows a generic provider hostname like ip-203-0-113-5.example-isp.net, is treated as a weak signal that the sender may not be a legitimate mail server. Many receivers downgrade or reject mail from addresses with no proper reverse DNS, so a clean PTR record that matches your mail domain is part of being deliverable, alongside SPF, DKIM, and DMARC.

Forward confirmed reverse DNS

Because a PTR record can claim any hostname, receivers run a stronger check called forward confirmed reverse DNS, or FCrDNS. The steps are simple.

  1. Take the connecting IP address and look up its PTR record to get a hostname.
  2. Take that hostname and do a normal forward lookup to get its IP addresses.
  3. Confirm the original IP appears in that forward result.

If both directions agree, the hostname is verified: whoever set the PTR also controls the forward record for the name it claims. If the forward lookup does not contain the original address, the reverse claim is unconfirmed and the receiver treats it with suspicion. FCrDNS does not prove the sender is honest, but it proves the reverse and forward records were configured by the same party, which is enough to filter out a large amount of casual spoofing.

How to look up a PTR

You can check the reverse record for any address directly. Given an IP, a reverse lookup returns the PTR hostname the address owner has published.

$ dig -x 203.0.113.5 +short
mail.example.com.
$ host 203.0.113.5
5.113.0.203.in-addr.arpa domain name pointer mail.example.com.

If you do not want to reach for the command line, the Reverse DNS (PTR Lookup) tool resolves the PTR for an IP and shows the associated hostname. To run the FCrDNS check yourself, take that hostname and confirm it forward resolves back to the same IP with the DNS Lookup tool. And if you are debugging email specifically, pair this with the MX Lookup to confirm the mail servers for the domain line up with the address that is actually sending.