Reverse DNS (rDNS) maps an IP address back to a domain name, the opposite of a forward DNS lookup which maps a domain to an IP. It uses PTR records stored under the in-addr.arpa domain for IPv4 and ip6.arpa for IPv6.

Why is reverse DNS important for email?

Many email servers check that the sending server's IP address has a PTR record matching its hostname. If the reverse DNS does not match, the receiving server may reject the email as spam or suspicious. This is one of the basic email authentication checks.

How do I set up reverse DNS?

Reverse DNS is controlled by the owner of the IP address block, usually your ISP or cloud hosting provider. You cannot set PTR records yourself unless you own the IP range. Contact your provider and request a PTR record for your IP address pointing to your domain.

Reverse DNS Lookup — What It Is and How to Set It Up

Reverse DNS is the opposite of a normal DNS lookup. Instead of asking "what IP does this domain point to," reverse DNS asks "what domain does this IP point to." It is a way to identify the domain name associated with a given IP address.

Most internet users never think about reverse DNS. It works silently in the background. But if you run a mail server, host services, or manage network infrastructure, reverse DNS matters a lot. Email servers check it. Log analysis tools use it. Security systems rely on it.

This guide explains what reverse DNS is, why it matters, how to check it, and how to set it up correctly.

What Is Reverse DNS (rDNS)?

Reverse DNS uses PTR (Pointer) records to map IP addresses to domain names. These records are stored in a special DNS domain: in-addr.arpa for IPv4 addresses and ip6.arpa for IPv6 addresses. The IP address is reversed and appended to this domain to form the lookup key.

For example, the reverse DNS lookup for 192.0.2.1 would query the PTR record at 1.2.0.192.in-addr.arpa. If configured correctly, this returns a domain like mail.example.com. For IPv6, the nibbles of the address are reversed and appended to ip6.arpa.

The key difference from forward DNS is who controls the records. In forward DNS, you control records for your domain. In reverse DNS, the owner of the IP address block controls the PTR records. This is almost always your ISP or cloud hosting provider, not you.

Why Reverse DNS Matters

Email delivery is the most important use case. When your mail server connects to a receiving server, the receiving server performs a reverse DNS lookup on your server's IP address. It checks whether the returned domain matches the HELO/EHLO hostname your server announced. If the PTR record is missing or does not match, the receiving server may reject your email, mark it as spam, or apply stricter filtering.

This is not a theoretical concern. Major email providers including Gmail, Outlook, and Yahoo all perform rDNS checks. If your mail server's IP lacks a matching PTR record, a significant portion of your outgoing email will fail delivery or land in spam folders.

Log analysis and security tools also use reverse DNS. When your firewall or web server logs an IP address, performing a reverse DNS lookup identifies the source. This helps with incident response, abuse investigation, and traffic analysis. SSH servers often enable reverse DNS lookups on incoming connections as an additional verification step.

Some network services require rDNS to function correctly. FTP servers, IRC servers, and certain authentication systems check reverse DNS as part of their connection handling. Without proper rDNS, these services may add delays or reject connections.

How to Check Reverse DNS

You can check reverse DNS using our reverse DNS lookup tool. Enter an IP address and the tool returns the associated PTR record if one exists.

On the command line, use dig with the -x flag: dig -x 192.0.2.1. This performs the reverse lookup automatically, reversing the IP address and querying the in-addr.arpa domain. If a PTR record exists, dig shows it in the answer section.

You can also use the host command: host 192.0.2.1. This is simpler than dig and works on most systems. The output shows the domain name associated with the IP, or a message indicating no PTR record was found.

How to Set Up Reverse DNS

Setting up reverse DNS is not something you can do from your DNS provider's control panel. PTR records are managed by whoever owns the IP address block. For most people, this is their ISP or cloud hosting company.

If you have a static IP address from your ISP, contact their support and request a PTR record. Provide the IP address and the domain name you want associated with it. Some ISPs do this for free. Others charge a fee or only offer it on business plans.

If you use a cloud hosting provider like AWS, DigitalOcean, or Linode, you can usually configure rDNS through their control panel. AWS uses Elastic IPs with reverse DNS support. DigitalOcean allows you to set PTR records for your Droplet IPs in their networking settings. Google Cloud and Azure also offer rDNS configuration through their consoles.

For best email delivery, the PTR record should match the hostname your mail server uses in its HELO/EHLO greeting. For example, if your mail server identifies as mail.example.com, the PTR record for its IP should point to mail.example.com. This consistency is what receiving mail servers check.

Reverse DNS Best Practices

Always set a PTR record for any IP address that sends email. This is not optional. Without it, your email deliverability will suffer. The PTR record should match the hostname your mail server uses in its EHLO greeting. Mismatched rDNS is a common reason for email being flagged as spam.

For web servers, rDNS is less critical but still recommended. It helps with log analysis and makes your server easier to identify in diagnostics. Set the PTR to the same hostname your server uses for reverse lookups (the result of the hostname command).

If you manage multiple IP addresses, each one should have its own PTR record. Do not point multiple IPs to the same domain unless they serve the same service. Some reverse DNS checks are strict about one-to-one mappings.

Test your rDNS configuration after setting it up. Use dig or our lookup tool to confirm the PTR record returns the correct value. Also verify that forward-confirms-reverse works: the PTR record should point to a domain that resolves back to the original IP address.