Networking & DNS

What is reverse DNS (rDNS) and why it matters

Reverse DNS maps an IP address back to a hostname using a PTR record. Learn how it differs from normal DNS, why mail servers check it, and how to look it up from your own computer.

Beginner4 min read

Normal DNS answers the question "what is the IP address of example.com?". Reverse DNS (rDNS) answers the opposite: "what name belongs to the IP address 203.0.113.10?". It is a small detail that most servers never need, until you send email. Then it can decide whether your messages arrive or land in spam. This guide explains how rDNS works, who controls it, and how to check it.

Before you start

  • Your server's IP address from your VPS provider's control panel.
  • A terminal on your computer: PowerShell on Windows, Terminal on macOS or Linux.
  • Optional: a domain name you control, if you want to set up matching forward and reverse records.

Forward DNS vs reverse DNS

  • Forward DNS uses A records (IPv4) and AAAA records (IPv6) to map a name to an address: mail.example.com → 203.0.113.10.
  • Reverse DNS uses a PTR (pointer) record to map an address back to a name: 203.0.113.10 → mail.example.com.

The two are stored in different places:

  • Forward records live in your domain's DNS zone, which you manage at your domain registrar or DNS provider.
  • Reverse records live in a special zone for the IP address, which is controlled by whoever owns that block of addresses. For a server, that is the hosting provider.

That is why you cannot add a PTR record in your domain's DNS panel. You ask the owner of the IP address to set it.

How a PTR lookup works

For an IPv4 address, the numbers are reversed and placed under the special domain in-addr.arpa. A lookup for 203.0.113.10 becomes a query for:

10.113.0.203.in-addr.arpa

The answer is the PTR record, a hostname such as mail.example.com. IPv6 uses the same idea under ip6.arpa, with each hex digit reversed. You do not need to build these names yourself; the tools below do it for you.

Why mail servers check it

Receiving mail servers use rDNS as one signal of whether a sender is legitimate:

  • A server with no PTR record looks like a home connection or a compromised machine, which are common sources of spam.
  • A PTR record that does not match the name the server uses to introduce itself (its HELO or EHLO name) also looks suspicious.
  • Many providers check forward-confirmed reverse DNS: the PTR record points to a name, and that name's A record points back to the same IP.

Missing or mismatched rDNS does not guarantee rejection, but it raises the spam score or causes outright refusal at strict providers. For mail, you also need SPF, DKIM and DMARC records.

Outside of email, rDNS makes logs and traceroute output easier to read, and some services use it for basic checks.

Check rDNS from your computer

On macOS or Linux, use dig with -x for a reverse lookup:

Bash
dig -x 203.0.113.10 +short

The output is the hostname, for example mail.example.com., with a trailing dot. No output means there is no PTR record.

On any system, nslookup works too:

Bash
nslookup 203.0.113.10

On Windows, PowerShell offers:

PowerShell
Resolve-DnsName 203.0.113.10

Then check the forward direction to confirm they match:

Bash
dig mail.example.com +short

It should return 203.0.113.10.

Getting a PTR record set

  1. Choose the hostname. It should be a name you control, such as mail.example.com or server1.example.com.
  2. Create the A record for that name, pointing at your server's IP, at your DNS provider.
  3. Ask the owner of the IP address to set the PTR record. For a server, open a ticket, select the related service, give the IP address and the hostname you want, and ask whether a PTR record can be set for it.
  4. Set the server's own hostname to the same name.

Tip: Set the A record first. Some providers check that the name resolves to the IP before they set the PTR record.

Check it works

  • dig -x 203.0.113.10 +short returns your chosen hostname.
  • dig mail.example.com +short returns the same IP.
  • On the server, hostname -f (Linux) shows the same name.

Troubleshooting

  • The lookup still shows an old or generic name: DNS caches answers for the record's TTL. Wait, then try again.
  • The PTR and A records do not match: fix whichever is wrong so both point at each other.
  • Mail still goes to spam: rDNS is only one part. Check SPF, DKIM, DMARC and whether the IP is on a blocklist.
  • No output from dig -x: there is no PTR record yet. Ask the IP owner to set one.

Next steps

Was this guide helpful?

Still stuck?

Ask MdmHost AI for a quick answer, or open a ticket and our team will take a look. We are here 24/7.