Reverse DNS Lookup
Find PTR hostnames and check their forward DNS.
What Is a Reverse DNS Lookup?
A reverse DNS lookup finds the hostname associated with an IP address by querying its DNS pointer (PTR) record. Unlike a standard DNS lookup, which converts a hostname into an IPv4 or IPv6 address, reverse DNS starts with the address. It helps administrators investigate mail server configuration, identify hostnames in network logs and check whether a server’s reverse and forward DNS records agree. A PTR result alone does not verify a server’s identity.
Reverse DNS Lookup
Find PTR hostnames and check their forward DNS.
Look up PTR records for a public IP address
Finds reverse DNS (PTR) hostnames and checks whether those names resolve back to the entered IP. Forward-confirmed reverse DNS is informative, but it does not prove that a server is authorized to send email. Private, loopback, link-local and reserved IP addresses are not queried.
Related tools
Explore similar tools from the same category.
DNS Records Lookup
Query public DNS records and review answers and TTLs.
WHOIS and Domain Registration Lookup
Look up public domain registration data using RDAP.
SPF, DKIM and DMARC Checker
Inspect public email authentication DNS records.
SSL Certificate and Expiry Checker
Inspect a public HTTPS certificate and expiry date.
DNS Propagation Checker
Compare current DNS answers from Google and Cloudflare resolvers.
HTTP Security Headers Checker
Review HTTP security headers on public webpages.
Read Reverse DNS Results and Diagnose PTR Record Problems
An unfamiliar IP address appears in a server log. An outgoing mail server starts receiving delivery errors. Or a hosting company asks you to configure reverse DNS before sending email. In each case, a PTR lookup can show which hostname, if any, has been published for that address.
The useful part is interpreting the answer correctly. A returned hostname is not proof of ownership, and an empty answer does not automatically mean that a website or application is broken. For mail systems, the more informative test is often whether the hostname resolves forward to the original sending IP. This guide explains the reverse DNS process, how to interpret common responses, how to diagnose mismatches and who can actually change a PTR record.
Read Full GuideShow Less
Start With an IP Address, Not Just a Domain Name
Reverse DNS begins with the IP address being investigated. For mail servers, identify the actual outbound IP, which may differ from your website IP.
- Identify the relevant public IPv4 or IPv6 address from your server, hosting dashboard, message headers or network logs.
- Enter that address into the Reverse DNS Lookup tool using the format accepted by its interface.
- Run the lookup and examine any returned PTR hostname or DNS error.
- For mail, also check whether the PTR hostname resolves back to the IP.
The tool’s live interface has not been independently verified.
What a PTR Record Says—and What It Does Not
A pointer (PTR) record associates a name in the reverse DNS namespace with a hostname. An A or AAAA record maps a name to an address; PTR maps the other way.
| DNS check | Input | Typical answer | What it establishes |
|---|---|---|---|
| A lookup | Hostname | IPv4 address | A published forward IPv4 mapping |
| AAAA lookup | Hostname | IPv6 address | A published forward IPv6 mapping |
| PTR lookup | IP address | Hostname | A published reverse DNS mapping |
A PTR record does not discover every domain hosted on an address. Multiple websites can share one server IP, and their individual names need not appear in reverse DNS. The hostname also cannot establish website ownership.
How IPv4 and IPv6 Reverse Names Are Constructed
DNS stores reverse mappings below special infrastructure domains. For IPv4, the four decimal address components are reversed and followed by in-addr.arpa. For example, the documentation address 198.51.100.42 is queried as:
42.100.51.198.in-addr.arpa. IN PTR
For IPv6, the complete 128-bit address is expanded into hexadecimal digits, those digits are reversed individually, and ip6.arpa is added. This is a nibble-by-nibble reversal, not a reversal of the colon-separated IPv6 groups.
These rules come from RFC 1035 and RFC 3596. dig -x constructs either reverse query automatically.
Interpret a Successful PTR Answer Carefully
Suppose a lookup for 198.51.100.42 returns mail.example.net. That means a PTR record points to the stated hostname; it does not yet show that the hostname points back to the original address.
This is a documentation-only example, not a tested public mail server.
A trailing hostname dot denotes a fully qualified DNS name, not an error. More than one PTR record is possible, although a single clear hostname is generally easier to maintain for an outgoing mail server.
Check Forward-Confirmed Reverse DNS for Mail Servers
Forward-confirmed reverse DNS (FCrDNS) asks whether an IP’s PTR hostname resolves forward to an address that includes the original IP. It helps reveal inconsistent DNS settings.
- Look up the sending IP’s PTR record:
198.51.100.42→mail.example.net. - Look up that hostname’s A records for an IPv4 sender or AAAA records for an IPv6 sender.
- Check whether the returned address set contains the original sending IP.
In this illustration, an A record containing 198.51.100.42 would complete the match. Other addresses may also exist.
Google’s sender guidelines require valid forward and reverse DNS for sending addresses. However, FCrDNS alone does not establish email legitimacy or guarantee inbox placement. SPF, DKIM, DMARC, reputation and other delivery conditions still matter.
Recognize Missing PTR Records and DNS Errors
Different DNS responses point toward different investigations. A timeout is not the same as a confirmed missing record, and an NXDOMAIN response is not the same as a hostname with an empty PTR answer.
| Observation | Possible meaning | Next step |
|---|---|---|
| PTR hostname returned | A reverse mapping is published | Check the hostname’s forward A or AAAA records |
| NXDOMAIN | The queried reverse DNS name does not exist | Ask the IP operator whether a reverse zone entry is configured |
| NOERROR, no PTR answer | The name exists but no PTR answer was supplied | Inspect the relevant reverse zone and record type |
| SERVFAIL | Resolution or validation failed | Investigate authoritative servers, delegation and DNSSEC |
| Timeout | No timely resolver response | Retry from another resolver and investigate network reachability |
| PTR differs from forward DNS | The two mappings may be inconsistent | Compare the actual sending IP with the hostname’s A or AAAA set |
Some residential, mobile and general-purpose cloud IP addresses have no public PTR record. That does not necessarily affect ordinary web browsing. It matters more when a service or receiving mail server expects a consistent reverse hostname.
Who Can Add or Change a Reverse DNS Record?
The operator responsible for the IP address block and its reverse DNS delegation controls where PTR records are published. In practice, this is often an ISP, cloud provider or hosting company. Owning example.com and editing its normal DNS zone does not automatically give you control over the PTR record of a hosted server IP.
For a dedicated server, find the provider’s PTR settings or request a change. Supply the IP and desired hostname, and verify forward DNS.
Networks with delegated address space can manage reverse zones directly. For smaller IPv4 subnets, RFC 2317 describes a classless delegation technique using CNAME records. This is generally an operator-level configuration, not a change needed by ordinary website owners.
Use Command-Line Checks When Results Are Unclear
Command-line DNS tools make it easier to separate reverse lookups from forward lookups. These commands illustrate the process; the reserved documentation IP will not produce the invented example hostname:
dig -x 198.51.100.42 +short
dig mail.example.net A +short
dig mail.example.net AAAA +short
nslookup 198.51.100.42
dig -x builds a reverse PTR query. The next two commands check forward IPv4 and IPv6 records for a hostname. nslookup provides a reverse-query alternative on many systems. Replace the examples with your actual IP and hostname.
If resolvers disagree, compare authoritative PTR records and cached TTLs.
Don’t Confuse Reverse DNS with Network Ownership or Security Proof
Reverse DNS can make a log entry easier to understand, but a PTR hostname is a DNS configuration statement, not a validated identity certificate. Treat a suspicious hostname as a clue to investigate, not as proof that the named organization generated the traffic.
A shared IP can also host many domains despite having one PTR hostname. To investigate which network announces an IP, use IP registration and ASN information separately. To assess a web server, inspect its HTTPS certificate and HTTP responses instead of assuming its PTR record describes its websites.
Private IP networks can have internal reverse zones, but public DNS tools cannot generally inspect records available only inside an organization’s network.
Frequently Asked Questions About Reverse DNS
Is reverse DNS the same as a reverse IP website lookup?
No. Reverse DNS queries PTR records and typically returns hostnames. A hosted-domain lookup tries to enumerate websites sharing an IP using other information sources.
Can I set a PTR record at my domain registrar?
Usually not unless the registrar also controls the relevant reverse DNS zone. Most users make this request through the ISP or hosting provider that assigned the IP.
Why does my IP have no reverse DNS?
The operator may not have published a PTR record. Check the authoritative reverse zone and whether the address is public, private or reserved.
Does a PTR record improve email deliverability?
A correct PTR record and matching forward DNS help meet mail infrastructure requirements. They do not replace SPF, DKIM, DMARC or healthy sender reputation.
Can an IPv6 address have a PTR record?
Yes. IPv6 reverse DNS uses the ip6.arpa namespace and reverses individual hexadecimal digits from the fully expanded address.
Why did the reverse hostname stay unchanged after an update?
A recursive resolver may have cached the previous PTR answer. Confirm the current authoritative record, check its TTL and requery after the cache period.