Reverse DNS (PTR)
Lookup Tool.
Look up the PTR record for any IPv4 or IPv6 address to find its associated hostname. Or perform a forward lookup to resolve a hostname to its IP addresses. Essential for email sender verification, server identification, and network diagnostics.
What Is Reverse DNS?
The Domain Name System works in two directions. Forward DNS translates a hostname into an IP address. Reverse DNS does the opposite: given an IP address, it finds the hostname assigned to it.
How Reverse DNS Works
Reverse lookups use a special DNS zone. For an IPv4 address like 8.8.8.8,
the resolver queries 8.8.8.8.in-addr.arpa — the octets reversed, with
.in-addr.arpa appended. For IPv6, the equivalent zone is ip6.arpa.
The DNS record that answers reverse queries is called a PTR record (pointer record).
Unlike A records (which you manage in your domain registrar's control panel),
PTR records are managed by the owner of the IP address block — typically your ISP or
hosting provider. Even if you own example.com, you cannot set
the PTR record for your server's IP yourself; you must request it from whoever
allocated the IP to you.
Forward vs. Reverse DNS
When Are PTR Records Required?
Email Deliverability (FCrDNS)
Most receiving mail servers perform a Forward-Confirmed Reverse DNS (FCrDNS) check. They look up the PTR record for your sending IP, then verify the resulting hostname resolves back to the same IP. If this check fails — or if no PTR exists — many servers reject the message or assign a high spam score. Any server sending email must have a correct PTR record.
Server Identification in Logs
Web servers, firewalls, and load balancers log connecting IP addresses. When a PTR record exists, tools like traceroute and network monitoring dashboards can show hostnames instead of raw IPs, making it far easier to identify infrastructure and diagnose routing issues.
Spam and Fraud Detection
Reverse DNS checks are a fast signal for anti-fraud systems. An IP with no PTR record, or whose PTR record doesn't match the claimed sending domain, is a strong indicator of a misconfigured or potentially malicious sender. Many threat intelligence feeds incorporate PTR data alongside IP reputation scores.
How to Configure a PTR Record
PTR records are not set at your domain registrar — they are controlled by whoever owns the IP address block. Here is how to set one up based on your environment:
mail.example.com).
A correct setup requires both checks to pass. Run these after your PTR record is configured:
Reverse DNS API
Resolves an IP address to its PTR record and hostname. Returns structured JSON — no DNS parsing required on your end.
GET /api/v1/dns/reverse/{ip}
curl "https://ip-api.io/api/v1/dns/reverse/8.8.8.8" \
-H "Authorization: Bearer YOUR_API_KEY"
{
"ip": "8.8.8.8",
"hostname": "dns.google",
"ptr_record": "8.8.8.8.in-addr.arpa",
"ttl": 300
}
GET /api/v1/dns/reverse/{ip}
const response = await fetch(
"https://ip-api.io/api/v1/dns/reverse/8.8.8.8",
{ headers: { Authorization: "Bearer YOUR_API_KEY" } }
);
const data = await response.json();
console.log(data.hostname); // "dns.google"
console.log(data.ptr_record); // "8.8.8.8.in-addr.arpa"
console.log(data.ttl); // 300
{
"ip": "8.8.8.8",
"hostname": "dns.google",
"ptr_record": "8.8.8.8.in-addr.arpa",
"ttl": 300
}
GET /api/v1/dns/reverse/{ip}
import requests
response = requests.get(
"https://ip-api.io/api/v1/dns/reverse/8.8.8.8",
headers={"Authorization": "Bearer YOUR_API_KEY"}
)
data = response.json()
print(data["hostname"]) # dns.google
print(data["ptr_record"]) # 8.8.8.8.in-addr.arpa
print(data["ttl"]) # 300
{
"ip": "8.8.8.8",
"hostname": "dns.google",
"ptr_record": "8.8.8.8.in-addr.arpa",
"ttl": 300
}
GET /api/v1/dns/reverse/{ip}
require "net/http"
require "json"
uri = URI("https://ip-api.io/api/v1/dns/reverse/8.8.8.8")
req = Net::HTTP::Get.new(uri)
req["Authorization"] = "Bearer YOUR_API_KEY"
data = JSON.parse(Net::HTTP.start(uri.host, uri.port, use_ssl: true) { |h| h.request(req) }.body)
puts data["hostname"] # dns.google
puts data["ptr_record"] # 8.8.8.8.in-addr.arpa
{
"ip": "8.8.8.8",
"hostname": "dns.google",
"ptr_record": "8.8.8.8.in-addr.arpa",
"ttl": 300
}
Forward DNS API
Resolves a hostname to all its A and AAAA records. Useful for confirming FCrDNS checks and verifying email sender configuration.
GET /api/v1/dns/forward/{hostname}
curl "https://ip-api.io/api/v1/dns/forward/dns.google" \
-H "Authorization: Bearer YOUR_API_KEY"
{
"hostname": "dns.google",
"addresses": [
{
"type": "A",
"address": "8.8.8.8",
"ttl": 300
},
{
"type": "A",
"address": "8.8.4.4",
"ttl": 300
}
]
}
GET /api/v1/dns/forward/{hostname}
const response = await fetch(
"https://ip-api.io/api/v1/dns/forward/dns.google",
{ headers: { Authorization: "Bearer YOUR_API_KEY" } }
);
const data = await response.json();
data.addresses.forEach(a =>
console.log(a.type, a.address)
);
{
"hostname": "dns.google",
"addresses": [
{
"type": "A",
"address": "8.8.8.8",
"ttl": 300
},
{
"type": "A",
"address": "8.8.4.4",
"ttl": 300
}
]
}
GET /api/v1/dns/forward/{hostname}
import requests
response = requests.get(
"https://ip-api.io/api/v1/dns/forward/dns.google",
headers={"Authorization": "Bearer YOUR_API_KEY"}
)
data = response.json()
for addr in data["addresses"]:
print(addr["type"], addr["address"])
{
"hostname": "dns.google",
"addresses": [
{
"type": "A",
"address": "8.8.8.8",
"ttl": 300
},
{
"type": "A",
"address": "8.8.4.4",
"ttl": 300
}
]
}
GET /api/v1/dns/forward/{hostname}
require "net/http"
require "json"
uri = URI("https://ip-api.io/api/v1/dns/forward/dns.google")
req = Net::HTTP::Get.new(uri)
req["Authorization"] = "Bearer YOUR_API_KEY"
data = JSON.parse(Net::HTTP.start(uri.host, uri.port, use_ssl: true) { |h| h.request(req) }.body)
data["addresses"].each do |addr|
puts "#{addr['type']}: #{addr['address']}"
end
{
"hostname": "dns.google",
"addresses": [
{
"type": "A",
"address": "8.8.8.8",
"ttl": 300
},
{
"type": "A",
"address": "8.8.4.4",
"ttl": 300
}
]
}
Reverse DNS Lookup FAQs
Everything you need to know about PTR records, reverse DNS, and email deliverability.
What is a reverse DNS (rDNS) lookup?
A reverse DNS lookup (rDNS) is the process of resolving an IP address back to its associated hostname.
While normal DNS translates a domain name into an IP address, reverse DNS does the opposite — it queries
the in-addr.arpa (IPv4) or ip6.arpa (IPv6) DNS zone to find the PTR record
for an IP address. The result is the fully qualified domain name (FQDN) assigned to that IP by its owner.
What is a PTR record?
A PTR (pointer) record is the DNS record type used exclusively for reverse lookups. It maps an IP address
to a hostname and lives in a special DNS zone: in-addr.arpa for IPv4 and ip6.arpa
for IPv6. For example, the PTR record for 8.8.8.8 lives at
8.8.8.8.in-addr.arpa and points to dns.google.
Unlike A records (which you set at your domain registrar), PTR records must be configured by the owner of the IP address block — your ISP or hosting provider.
Why do email servers need PTR records?
Most receiving mail servers perform a Forward-Confirmed Reverse DNS (FCrDNS) check: they look up the PTR record for the sending IP address, then verify that the resulting hostname has an A record pointing back to the same IP. If the check fails — or if no PTR record exists at all — many servers reject the message outright or mark it as spam.
This is why any server used for sending email must have a properly configured PTR record that
matches its mail hostname (HELO/EHLO name).
How do I set up reverse DNS for my server?
PTR records are controlled by the owner of the IP address block, not by your domain registrar. Here is how to set one up:
- AWS EC2: Go to EC2 → Elastic IPs → Actions → Update reverse DNS.
- Google Cloud: Edit the network interface for your instance and set the DNS PTR record field.
- Azure: Edit the Public IP resource and set the DNS name label.
- Dedicated servers / VPS: Contact your hosting provider or ISP and request a PTR record for your IP.
After setting it up, use the tool above to verify the IP resolves to your hostname, then check the Hostname → IPs tab to confirm the hostname resolves back to the same IP.
What's the difference between a PTR record and an A record?
An A record maps a hostname to an IP address (forward DNS). A PTR record maps an IP address to a hostname (reverse DNS). They point in opposite directions:
- A record:
mail.example.com → 203.0.113.5— managed at your domain registrar. - PTR record:
203.0.113.5 → mail.example.com— managed by your ISP/hosting provider.
For email deliverability, both should be consistent: the PTR for your sending IP should point to your mail hostname, and that hostname should have an A record pointing back to the same IP.
Why doesn't my IP return a hostname?
Many IP addresses have no PTR record configured. This is common for residential IPs assigned by consumer ISPs, cloud instances that have never had reverse DNS set up, and IP addresses from large DHCP pools. A missing PTR record does not necessarily mean the IP is malicious, but for any server sending email or running public-facing services, it is considered a misconfiguration.
To add a PTR record, contact your ISP or cloud provider — you cannot add it yourself unless you own the IP address block.
Is your reverse DNS lookup API free?
The interactive reverse DNS lookup tool on this page is completely free with no sign-up required. Programmatic API access for developers requires a paid subscription. The API endpoints are:
- PTR lookup:
GET https://ip-api.io/api/v1/dns/reverse/{ip} - Forward lookup:
GET https://ip-api.io/api/v1/dns/forward/{hostname}
Simple, transparent pricing
Start small, scale as you grow. No hidden fees.
Automate DNS lookups at any scale
Resolve PTR records, forward lookups, and hostname-to-IP mappings programmatically via a simple REST API.