Most people learn DNS as “name to IP.” But there’s a parallel system that goes the other way: IP to name. It’s called reverse DNS, and it’s powered by PTR records in a special-purpose DNS hierarchy called in-addr.arpa.

Reverse DNS isn’t useful for browsing the web — your browser doesn’t care what a server “claims” to be called. But it’s quietly central to email reputation, abuse tracking, and any investigation that starts with “what’s at this IP?” This post is the practical guide.

What Reverse DNS Actually Is

A normal DNS lookup: “What’s the IP of cloudflare.com?” → 104.18.27.89.

A reverse DNS lookup: “What’s the name of 104.18.27.89?” → some hostname that whoever owns that IP has chosen to associate with it.

The reverse lookup uses a PTR (pointer) record in the special in-addr.arpa. zone for IPv4 (or ip6.arpa. for IPv6). The IP is written in reverse:

89.27.18.104.in-addr.arpa.    PTR    elephant.cloudflare-dns.com.

When a resolver does a reverse lookup, it queries 89.27.18.104.in-addr.arpa. in the DNS hierarchy and gets back the PTR record.

How to Do a Reverse Lookup

`dig`

dig -x 104.18.27.89

The -x flag tells dig to do a reverse lookup. Internally it constructs the in-addr.arpa query for you.

`nslookup`

nslookup 104.18.27.89

Most nslookup implementations automatically detect that the argument is an IP and do a reverse lookup.

Programming languages

Most stdlibs have a function for this:

// Node.js
const { reverse } = require('node:dns').promises
const names = await reverse('104.18.27.89')

# Python
import socket
name, aliases, addresses = socket.gethostbyaddr('104.18.27.89')

// Go
names, _ := net.LookupAddr("104.18.27.89")

Browser-based

Many IP lookup tools include reverse DNS in their response. Look for a “PTR” or “Reverse DNS” field.

Why PTR Records Matter

1. Email reputation (the big one)

When your mail server connects to another mail server to deliver email, the receiving server checks:

What’s the source IP?
What does the source IP’s reverse DNS say it is?
Does the forward DNS of that name match the source IP?

This three-step check is called forward-confirmed reverse DNS (FCrDNS). Mail servers use it as a sanity test — a sender that can pass FCrDNS is presumed to be a legitimate, well-configured mail server. A sender without proper reverse DNS, or where the forward and reverse don’t match, often gets:

Rejected outright
Greylisted (deferred for retry)
Heavily scored for spam likelihood

If you’re running your own outbound mail server, setting a proper PTR record is mandatory. You can’t set it via your DNS provider — see “Who Owns the PTR” below. You have to ask your ISP or hosting provider.

2. Identifying anonymous IPs

When you see traffic from an IP and want to know “what is this?”, a reverse lookup gives a hint. Examples:

103-21-244-1.cloudflare.com → Cloudflare CDN edge
ec2-54-184-12-99.us-west-2.compute.amazonaws.com → AWS EC2 instance
static.249.94.46.78.clients.your-server.de → Hetzner server
crawl-66-249-66-1.googlebot.com → Google’s crawler

You can often tell what kind of system an IP belongs to from the PTR alone. A PTR like c-67-188-117-89.hsd1.ca.comcast.net says “Comcast residential cable in California.” A PTR like s33.azureresellersolution.de says “Azure-hosted service.”

3. Abuse tracking

Reverse DNS records are an extra confirmation layer when an IP is involved in abuse. If [email protected] reports that IP 203.0.113.45 is attacking their service, you can:

Look up the PTR — mail-fwd.example-spammer.com.
Look up the forward of that name — same IP.
Confirm the rDNS, FCrDNS, and forward all line up.
Look up the ASN owner of the IP and the registered abuse contact.
File a complaint with confidence that the IP and the operator are correctly identified.

Without rDNS, the IP is just numbers. With rDNS, you have a hostname — often informative, sometimes the only signal of who’s running the system at that IP.

4. Network diagnostics

traceroute shows the IPs of routers along the path to a destination. Most traceroute implementations also do a reverse lookup on each IP to show a hostname. The hostnames usually tell you:

The geographic location (many PTRs include city codes — lhr01.cloudflare-as.com → London)
The transit provider or interconnect point
Whether you’re on a customer link, peering link, or transit link

This makes traceroute output dramatically more useful than just numeric IPs.

Who Owns the PTR

This is the part that trips people up. A PTR record is owned by whoever owns the IP, not by the domain owner.

If your domain is example.com and you point it at 203.0.113.45, you control the A record (in example.com’s zone). You do not control the PTR record for 203.0.113.45. That PTR lives in the 203.0.113.45.in-addr.arpa. zone, which is delegated by IANA → RIR → ISP → … and ultimately controlled by whoever was allocated that IP block.

So:

On AWS: You can request a PTR via the AWS Console (for Elastic IPs).
On GCP: You can set PTRs for static external IPs through the Cloud DNS console.
On a dedicated server or VPS: You’ll have a control panel option or a support ticket to your provider.
On a home / consumer ISP: Usually you cannot set a PTR. The ISP sets a generic one like c-67-188-117-89.hsd1.ca.comcast.net.
On mobile data / CGNAT: You definitely cannot set a PTR — the IP is shared among many customers anyway.

If you want your IP to have meaningful reverse DNS, you need to host on infrastructure that allows you to set it.

What Reverse DNS Doesn’t Do

A few things people assume reverse DNS does that it doesn’t:

It’s not authoritative

Anyone with control over an IP block can set arbitrary PTR records. “This IP claims to be google.com” doesn’t make it actually Google. The forward-reverse match (FCrDNS) is what gives reverse DNS some authority — but only insofar as the forward DNS is properly secured.

It doesn’t always exist

Many IPs have no PTR record at all, especially in legacy ranges or smaller hosting providers. “No reverse” is a valid state, not an error.

It can mislead

Cloud-hosted IPs often have generic PTRs (ec2-54-something.amazonaws.com) that tell you “AWS” but not the actual customer. Determining the real operator behind a cloud IP usually requires looking at the application running on it, not just reverse DNS.

It’s not free of weirdness

PTR records can include private addresses, special-purpose ranges, multicast addresses, etc. Most lookup tools handle these gracefully but some can produce surprising results (127.0.0.1 PTR is often localhost.).

IPv6 Reverse DNS

The IPv6 version of reverse DNS works the same conceptually but the format is different. IPv6 addresses are broken into 4-bit nibbles and reversed:

2606:4700:20::ac43:4a8a in reverse DNS becomes:
a.8.a.4.3.4.c.a.0.0.0.0.0.0.0.0.0.0.0.0.0.2.0.0.0.0.7.4.6.0.6.2.ip6.arpa.

It’s ugly but routine for code. dig -x 2606:4700:20::ac43:4a8a handles the conversion for you.

IPv6 reverse DNS is less consistently configured than IPv4. Many IPv6 ranges have no PTR records at all. If you’re running an IPv6-enabled mail server, set both A/AAAA and matching PTRs for both protocols.

When You’ll Care About Reverse DNS

For most application developers, reverse DNS is something that exists in the background:

You’re running your own mail server? You’ll deal with this very carefully.
You’re investigating an abuse incident? Reverse lookup is one of your first commands.
You’re debugging a connectivity issue? Reverse DNS in traceroute output is invaluable.
You’re auditing what an IP is? IP lookup tools typically include reverse DNS alongside geo and ASN data.

For typical web development, you’ll rarely set up or rely on PTR records yourself. But knowing they exist, what they mean, and what they can tell you turns “this IP is just numbers” into “this IP is a Cloudflare edge in Frankfurt running on AS13335.”

A Quick Example Walkthrough

Let’s say you see this IP attacking your service: 203.0.113.45.

Reverse lookup: dig -x 203.0.113.45 → mail-from-spammer.evil-domain.tld.
Forward lookup of that name: dig mail-from-spammer.evil-domain.tld. → 203.0.113.45 (matches — confirmed reverse).
WHOIS the IP: whois 203.0.113.45 → tells you the allocation owner and abuse contact.
ASN lookup: Look up the ASN → tells you the operating network.
Aggregate the data: “This is a server at evil-domain.tld, owned by Org X, hosted on AS Y, with abuse contact email Z.”

Without reverse DNS, you’d have the IP and the ASN. With it, you have a hostname that’s often a critical lead.

TL;DR

Reverse DNS maps IPs to names via PTR records in in-addr.arpa. (IPv4) or ip6.arpa. (IPv6).
You don’t control the PTR for your domain’s IP. The IP block’s owner does (your ISP/hosting provider).
Forward-confirmed reverse DNS (FCrDNS) — where forward and reverse match — is critical for mail server reputation.
Reverse lookups give context about what an IP is, especially for cloud-hosted services with informative PTRs.
Many IPs have no PTR record at all. That’s normal.
dig -x <ip> is the easiest way to do a reverse lookup.

For most use cases — investigating an unknown IP, debugging a connectivity issue, identifying what’s at an address — running both a forward and reverse lookup is the first move. Most IP lookup tools return both alongside the geo and ASN data, saving you the manual dig calls.

Reverse DNS Lookups: PTR Records Explained for Mail Servers and Audit Logs