Skip to content

PTR record

Every record so far has answered the same shape of question: given this name, what's the address? A PTR record answers the reverse — given this address, what name claims it?

dig +short -x 8.8.8.8

dns.google.

-x is dig's shorthand for a reverse lookup, and it's doing something less magical than it appears.

Reverse DNS is forward DNS with the address written backwards

There's no separate reverse database. Reverse lookups use the same DNS hierarchy, with addresses rewritten as names inside a special domain:

dig +short PTR 8.8.8.8.in-addr.arpa

dns.google.

The octets are reversed and .in-addr.arpa is appended. That reversal isn't decorative — DNS delegates from right to left, from the most general label to the most specific, and IP addresses are the opposite, with the network part on the left. Flipping them lines the two hierarchies up, so an organisation that owns 203.0.113.0/24 can be delegated authority over 113.0.203.in-addr.arpa and manage its own PTR records.

IPv6 uses the same trick, one hex digit per label, under ip6.arpa:

dig +short -x 2001:4860:4860::8888

dns.google.

You probably can't set your own

This is the practical fact that surprises people. A PTR record lives in the reverse zone for an address block, and that zone is controlled by whoever owns the address space — your cloud provider, your ISP, your hosting company. Owning example.com gives you no authority over the reverse zone for the address it points to.

So configuring reverse DNS means asking the address owner, through whatever interface they provide. On AWS it's a support request for Elastic IPs; most VPS providers expose a "reverse DNS" or "PTR" field in the instance settings. Either way it's a different system from your domain's DNS, and looking for it in Cloudflare or Route 53 is a common wasted half-hour.

Where it actually matters: email

For most services, missing reverse DNS is harmless. For a mail server it's close to fatal.

Receiving mail servers check the connecting server's address against a set of expectations, and the near-universal baseline is a forward-confirmed reverse DNS match:

  1. The connecting address is 203.0.113.44.
  2. Its PTR record says mail.example.com.
  3. An A record lookup for mail.example.com returns 203.0.113.44.

All three must agree. A missing PTR, or one pointing at a generic name like 203-0-113-44.static.isp.example, is treated as a strong spam signal — mail gets scored down, deferred, or rejected outright. The HELO/EHLO name the server announces should match too.

The symptom is distinctive: mail to some destinations arrives fine while large providers silently drop or spam-folder it, with no clear error. Anyone running their own mail server, rather than using a delivery service, has to get this right, and it's the first thing to check when deliverability is bad. It sits alongside the SPF, DKIM, and DMARC records covered in the TXT record article — those authenticate the message; PTR authenticates the machine.

dig +short -x 203.0.113.44

mail.example.com.

dig +short mail.example.com

203.0.113.44

Two commands, and the match either holds or it doesn't.

The other uses, and their costs

Log readability. Tools that resolve addresses to names produce logs a human can scan. It's genuinely useful and it has a cost: every unresolved address means a DNS query and a wait, which is why -n exists on tcpdump, ss, and most network tools, and why turning reverse lookups off is standard on anything processing volume.

Traceroute output. The hop names in a traceroute are PTR records, which is why some hops show a descriptive name revealing a carrier and a city while others show a bare address — the operator either set a PTR or didn't.

Weak identity checks. Some services still consult reverse DNS as a light trust signal. It should never be more than that: the reverse zone is controlled by whoever owns the address block, so a PTR proves something about address ownership and nothing about the entity using it today. Any check that treats a PTR as authentication is weak, which is exactly why the forward-confirmed pattern above requires the forward record to agree.

Practice

  1. Run dig +short -x against several addresses — a large provider's DNS server, your own public address, a random hop from a traceroute. Note which have PTRs and which don't, and speculate about why.
  2. Construct the in-addr.arpa name for 192.0.2.77 by hand, then verify with dig -x that you got the octet order right.
  3. Pick a domain that runs its own mail and verify the full forward-confirmed match for its MX host, showing both commands.
  4. Find where your cloud or VPS provider lets you set a PTR. If you can't find it in fifteen minutes, that's the answer to how separate the reverse zone really is.

Exercise 3 is the one that connects this record to something real. Reverse DNS is invisible infrastructure until the day mail stops being delivered, and then it's the first thing anyone experienced asks about.

A PTR record maps an address to a name. The next record goes further in the other direction: it names a host and the port its service runs on, which is more than any record so far has been willing to say.

Sources