Most people are familiar with the idea of looking up a domain name to find its IP address. Reverse DNS lookup does the exact opposite: given an IP address, it returns the associated hostname. This single mechanism quietly underpins email deliverability, server authentication, security logging, and network diagnostics worldwide. If your mail server is landing in spam folders, if your server logs are full of raw IP addresses instead of hostnames, or if a remote system is rejecting your connections, a missing or misconfigured reverse DNS record is often the culprit. Understanding how rDNS works and how to fix it can save hours of head-scratching.
What Reverse DNS Lookup Actually Does
A standard forward DNS lookup resolves a hostname to an IP address. For example, querying mail.example.com might return 203.0.113.45. A reverse DNS lookup goes the other direction: querying 203.0.113.45 returns mail.example.com. The mechanism that makes this work is the PTR record (Pointer record), stored in a special zone called the in-addr.arpa domain for IPv4 addresses, or ip6.arpa for IPv6.
The address is written in reverse-octet format before appending .in-addr.arpa. So to look up the PTR record for 203.0.113.45, a resolver queries:
That zone is delegated to the organization that owns the IP block, typically your hosting provider or ISP. This is a critical point: unlike forward DNS records, which you control through your domain registrar or DNS host, PTR records are set by whoever owns the IP address allocation. If you rent a VPS from a cloud provider, they control the reverse DNS zone, and you typically configure rDNS through their control panel rather than your domain's DNS dashboard.
Why Reverse DNS Lookup Matters
Email Deliverability
This is where misconfigured rDNS causes the most pain. When your mail server sends an email, the receiving mail server performs a reverse DNS lookup on the connecting IP address. If no PTR record exists, or if the PTR record does not match the server's SMTP greeting hostname (the HELO/EHLO name), the receiving server will almost certainly mark the message as spam or reject it outright.
Major providers including Gmail, Microsoft 365, and Yahoo check rDNS as a baseline trust signal. The rule is simple: the IP address of your mail server must have a PTR record, and that PTR record must resolve to a hostname that forward-resolves back to the same IP. This bidirectional check is called forward-confirmed reverse DNS (FCrDNS), and failing it is one of the fastest ways to get your mail flagged.
Security and Access Control
Many intrusion detection systems, firewalls, SSH configurations, and remote services use rDNS to add context to log entries or to make access control decisions. TCP wrappers, for instance, can allow or deny connections based on the resolved hostname of the connecting IP. Without a valid PTR record, those systems fall back to the raw IP, which some configurations will reject by default or flag as suspicious.
Network Diagnostics and Logging
Tools like traceroute, ping, and nmap perform reverse lookups to show human-readable hostnames alongside IP addresses. When rDNS is properly configured, a traceroute output reveals the network topology in plain language: you can see which carrier's backbone you are traversing, which datacenter a hop lives in, and where a packet is being dropped. Without rDNS, you get a screen full of raw IPs that tell you almost nothing at a glance.
Trust and Professionalism
If you run any kind of server infrastructure, properly configured rDNS signals that you are a competent operator. Spam blacklists like Spamhaus and Barracuda actively penalize IP addresses with no PTR record. API providers, partner networks, and enterprise customers sometimes perform automated rDNS checks before allowing integrations. A missing PTR record can silently block business relationships before they even start.
How to Perform a Reverse DNS Lookup
The fastest way to perform a reverse DNS lookup from the command line is with dig, nslookup, or host.
Using dig (Linux, macOS, Windows with BIND tools installed):
Using nslookup (available on Windows, macOS, Linux):
Using host (Linux, macOS):
You can also use our DNS Lookup tool to perform PTR record lookups directly from your browser without any command-line access. Simply enter the IP address and select PTR as the record type.
How to Set Up a PTR Record
Because PTR records live in zones controlled by the IP address owner, the process differs by provider. Here is how to do it on the most common platforms.
Amazon Web Services (EC2)
AWS does not allow self-service PTR record editing. You must submit a request through the AWS Support Center. Go to Support > Create Case > Service Limit Increase > Elastic IP Addresses and request rDNS assignment. Include your Elastic IP and the desired hostname. AWS typically responds within 24 hours.
DigitalOcean
DigitalOcean automatically sets the PTR record for a Droplet's IP to the Droplet's name when you create or rename it. To update rDNS, rename the Droplet to match your desired hostname: go to Droplets > Settings > Rename. If you need a fully qualified domain name, name the Droplet exactly as the FQDN including the dot at the end (e.g., mail.example.com). Changes propagate within a few minutes.
Linode / Akamai Cloud
Log in to the Linode Cloud Manager. Navigate to Linodes > [Your Linode] > Network. Under the IP Addresses section, click the three-dot menu next to the relevant IP address and select Edit rDNS. Enter the desired hostname and save. The forward DNS for that hostname must already resolve to the IP before Linode will accept the change.
Vultr
In the Vultr control panel, go to your instance, then click Settings > IPv4. There is a dedicated field for reverse DNS. Enter the desired hostname and click Update. Same requirement applies: forward DNS must resolve first.
Hetzner
In the Hetzner Cloud Console, navigate to your server, click Networking, then click the pencil icon next to the IP address. Enter the desired PTR hostname and save.
OVHcloud / SoYouStart / Kimsufi
Log in to the OVH Manager. Go to Bare Metal Cloud > IP. Find the IP block, expand it, locate the IP, and click the gear icon. Select Modify Reverse, enter the hostname, and confirm. OVH also requires forward DNS to be in place first.
Comcast / ISP Business Lines
For business internet connections with static IPs, contact your ISP support directly and request PTR record changes. Residential connections typically do not allow custom PTR records at all.
Verifying Your PTR Record Configuration
After setting a PTR record, verify it from an external vantage point. Do not test from the same server because local resolver caching can give false results.
All three must be consistent. The PTR points to the hostname, the hostname's A record points back to the IP, and the SMTP EHLO/HELO greeting announces that same hostname. Any mismatch is a problem.
Common Reverse DNS Problems and Fixes
No PTR Record Exists
The most common scenario. The IP has never had a PTR record configured. Fix: follow the provider-specific steps above. If you do not know who controls the IP, run whois 203.0.113.45 to identify the Regional Internet Registry (ARIN, RIPE, APNIC) and the organization assigned the block. That organization is your contact point.
PTR Record Points to the Wrong Hostname
A previous server or tenant left a stale PTR record. Update it through the same provider panel. If you recently acquired the IP from a different customer, contact the provider to have the old record cleared.
PTR Record Does Not Forward-Confirm
The PTR record exists but the hostname in it does not have an A record pointing back to the IP. This is often caused by setting up rDNS before creating the corresponding A record. Fix: create the forward A record first, wait for it to propagate, then set or re-save the PTR record.
IPv6 Reverse DNS
IPv6 PTR records use the ip6.arpa zone with the address written in fully expanded, nibble-reversed format. For the address 2001:db8::1, the full PTR query is:
Most cloud providers now support IPv6 rDNS through the same control panel interfaces. Check the IPv6 section specifically, as it is often a separate field from IPv4 rDNS.
Reverse DNS in Email Authentication Context
rDNS works alongside, not instead of, SPF, DKIM, and DMARC. A properly configured mail server needs all four. Think of rDNS as the TCP-layer trust check that happens before the SMTP conversation even begins. SPF, DKIM, and DMARC operate at the email message level. Both layers are evaluated by major mail providers. Passing rDNS checks alone does not guarantee delivery, but failing rDNS will often cause rejection before any message-level authentication is even attempted.
Preventing Future Reverse DNS Issues
- Always set rDNS before going live. Add PTR record configuration to your server provisioning checklist alongside firewall rules and SSL certificate installation.
- Name servers and Droplets after their function. Use descriptive FQDNs like mail.yourdomain.com or mx1.yourdomain.com rather than generic hostnames. This makes rDNS meaningful for logging and diagnostics.
- Document IP-to-hostname mappings. Keep an internal record of which IPs map to which PTR records, especially if you manage multiple servers across different providers.
- Re-verify after IP changes. If you change a Floating IP, re-IP a server, or migrate between providers, PTR records do not follow automatically. They must be re-configured on the new IP.
- Monitor with automated tools. Include rDNS checks in your server monitoring stack. A missing PTR record on a mail server can silently degrade delivery rates for days before anyone notices a problem in spam reports.
Reverse DNS is one of those infrastructure fundamentals that receives almost no attention until something breaks. Getting it right the first time is far less painful than diagnosing mysterious email rejections or opaque connection failures weeks later.