Reverse DNS Lookup
Look up the PTR record for an IP address to find its associated hostname. Used by mail servers, network monitoring tools, and security analysts to identify IP owners.
What Is Reverse DNS?
Reverse DNS (rDNS) translates an IP address back to a hostname. While forward DNS maps names to IPs (A records), reverse DNS maps IPs to names using PTR records stored in the special in-addr.arpa zone. For IPv6, the equivalent zone is ip6.arpa. For more background, see our explainer on how DNS works.
Why PTR Records Matter
| Use Case | Why Reverse DNS Is Checked |
|---|---|
| Email delivery | Mail servers verify PTR records - Missing rDNS often causes email to be marked as spam |
| Security auditing | Identifies server operators and helps attribute network activity |
| Network troubleshooting | Makes ping, traceroute, and log file entries human-readable |
| Abuse reporting | Helps identify ISPs responsible for abusive IP ranges |
Forward vs Reverse DNS
| Type | Direction | Record type | Example |
|---|---|---|---|
| Forward DNS | Hostname → IP | A / AAAA | example.com → 93.184.216.34 |
| Reverse DNS | IP → Hostname | PTR | 93.184.216.34 → example.com |
Why Reverse DNS Matters
Reverse DNS has real-world consequences for deliverability, security, and reputation. The most critical use case is email: major email providers like Gmail, Microsoft 365, and Yahoo will reject or spam-folder email from IPs without a valid PTR record that matches the sending hostname (FCrDNS - Forward-Confirmed Reverse DNS).
Email Rejection Rate by PTR Status
Approximate rejection rate for email sent from IPs with each PTR configuration
Figures are illustrative estimates for educational purposes, not measured data.
How PTR Records Are Structured
PTR records are stored in a reversed IP address format within the in-addr.arpa zone. For IP 1.2.3.4, the PTR query is made to 4.3.2.1.in-addr.arpa. This reversal allows the existing DNS delegation hierarchy to be used for IP space management, since IP blocks are allocated by prefix (left to right) while the DNS tree is read right to left.
Why Reverse DNS Is Not Just Forward DNS Backwards
A forward lookup is controlled by whoever owns the domain. A reverse lookup is controlled by whoever owns the IP address block - almost always the hosting provider or ISP, not you. That asymmetry causes most of the confusion around PTR records.
- You can point any domain at any IP address without permission. You cannot create a PTR record for an address you do not control.
- PTR records live in a special reverse zone (in-addr.arpa for IPv4, ip6.arpa for IPv6) delegated down the address hierarchy.
- An address can have many domains pointing at it but conventionally has exactly one PTR record.
- If you need a specific PTR value, you request it from your hosting provider - it is not something you can set in your own DNS panel.
Forward-Confirmed Reverse DNS
Mail servers do not merely check that a PTR record exists - they check that it round-trips. This is the test that actually gates deliverability:
- The receiving server takes the connecting IP address and looks up its PTR record, getting a hostname.
- It then looks up the A or AAAA record for that hostname.
- If the result matches the original connecting address, the check passes. If it does not, the message is treated as suspicious.
A PTR pointing at a hostname that does not resolve back is worse than no PTR at all, because it looks like a misconfiguration or an impersonation attempt.
Frequently Asked Questions
PTR records are controlled by whoever holds the IP address allocation - Typically your hosting provider or ISP, not your domain registrar. Contact your server host and request that they set a PTR record for your IP pointing to your mail server's hostname. Many cloud providers (AWS, DigitalOcean, Vultr) allow self-service PTR record management in their dashboards.
Forward-Confirmed Reverse DNS (FCrDNS) means the PTR record for an IP resolves to a hostname, and that hostname's A record resolves back to the same IP. This bidirectional consistency is a strong signal that the IP is legitimately operated, and is required by some receiving mail servers.
Technically yes, but it is strongly discouraged. Most implementations only use the first PTR record returned, and multiple PTR records can cause unpredictable behavior in email delivery and security tools. Best practice is one PTR per IP.
Most residential ISPs do not configure PTR records for dynamic home IP addresses. This is normal and expected. A missing PTR is only a problem for servers - Particularly mail servers - That need to be recognized as legitimate senders.
Related Tools
Sources & Further Reading
The technical claims on this page are drawn from the primary specifications and vendor documentation below.