Reverse DNS and PTR Records Explained

Reverse DNS is the quiet mirror image of the lookups you do every day: instead of turning a name into a number, it turns an IP address back into a hostname using a special kind of record called a PTR record.

Most of the time, the Domain Name System works in one direction. You type a name like example.com, and DNS hands your device an IP address such as 93.184.216.34. Reverse DNS runs the same machinery backwards. Given an address like 93.184.216.34, it answers the question, "what name, if any, is attached to this IP?" That answer comes from a PTR record (short for "pointer record"), and while most people never touch one directly, PTR records quietly influence email delivery, server logs, and the trust that networks place in one another.

Forward DNS vs reverse DNS

Ordinary DNS lookups are called forward lookups because they go from name to address. A typical forward lookup uses an A record (for IPv4) or an AAAA record (for IPv6). Reverse DNS goes the other way, from address to name, and it lives in its own dedicated corner of the DNS tree.

The two directions are completely independent. Setting up a website's A record does not automatically create a matching PTR record, and the reverse is also true. This is deliberate: the owner of a domain name and the owner of an IP address block are often different parties, so DNS keeps the two jobs separate.

How a PTR record is structured

To make reverse lookups fit into the normal DNS tree, IP addresses are rewritten as special domain names. For IPv4, the four octets of the address are reversed and appended to in-addr.arpa. So the address 93.184.216.34 becomes the name:

34.216.184.93.in-addr.arpa

A PTR record stored at that name points to a hostname, such as example.com. The octets are reversed because DNS names get more specific from right to left, while IP addresses get more specific from left to right. Flipping the order lets a provider delegate control of a whole block of addresses in one clean step.

IPv6 works the same way but is more verbose. Each of the 32 hexadecimal digits of the fully expanded address is reversed and placed under ip6.arpa, one digit per label. It looks unwieldy, but the principle is identical to the IPv4 version. If you want a refresher on how the two address formats differ, see our guide to IPv4 vs IPv6.

Why reverse DNS matters for email

The single biggest reason PTR records exist in practice is email. Mail servers are constantly bombarded by spam sent from poorly configured or hijacked machines, and one cheap way to filter that noise is to check the sending server's reverse DNS.

When a mail server connects to deliver a message, the receiving server can look up the PTR record for the sender's IP. Many receivers go a step further and perform a forward-confirmed reverse DNS check: they take the hostname from the PTR record, resolve that name forward, and confirm it points back to the same IP. A legitimate, well-run mail server passes this test easily; a random infected home computer usually does not.

The practical consequence is simple. If you run your own mail server on an IP with no PTR record, or with a generic one like host-203-0-113-45.example-isp.net, your messages are far more likely to be delayed, filtered into spam, or rejected outright. This is why anyone sending mail from their own server asks their provider to set a matching PTR record.

Other uses: logs, diagnostics, and trust

Reverse DNS shows up in plenty of quieter places too. Server access logs often display hostnames instead of raw IPs, which makes it easier to see at a glance that traffic came from, say, a search engine's crawler rather than an anonymous address. Network tools like ping and traceroute use reverse DNS to label each hop along a path with a human-readable name, turning a list of numbers into something you can actually read.

Because PTR records are controlled by the address block owner, they also carry a small amount of trust. A hostname like mail.example.com attached to an IP is a hint that the address belongs to a real, accountable organisation. It is not proof of anything on its own, but combined with forward confirmation it is a useful signal.

Checking reverse DNS yourself

You do not need special access to look up a PTR record. On most systems the command-line tools dig -x 93.184.216.34 or nslookup 93.184.216.34 will return the hostname, if one exists. Plenty of web-based tools do the same thing in a browser. If a lookup returns nothing, that simply means no PTR record is configured for that address, which is completely normal for many home and dynamic connections.

Setting reverse DNS is the harder part. Since the in-addr.arpa and ip6.arpa zones are delegated to the owner of the IP range, you generally submit a request through your ISP or hosting control panel rather than editing a zone file yourself. Larger providers may delegate a reverse zone to you so you can manage PTR records directly, but that is the exception rather than the rule.

Reverse DNS is a small, elegant idea: reuse the same distributed database that maps names to numbers, and let it run in reverse. Most of the time it works invisibly in the background, but the moment you send email from your own server or read a traceroute, you are relying on it. For more on the naming system it builds upon, explore the rest of the guides here at IP Animals.