Reverse DNS Lookup
Perform reverse DNS lookups (PTR records) using HTTPS resolvers.
Reverse DNS Lookup
Queries a real public DNS-over-HTTPS resolver (Cloudflare) for the address's actual PTR record — the same live-lookup pattern as the DNS Lookup tool.
Runs entirely in your browser
This tool executes locally using standard browser APIs (for example window.crypto.getRandomValues or crypto.subtle where applicable). Your input is not transmitted to or stored on a ScriptPulse server. See How Calculations Work.
What This Tool Does
- Reverse DNS Lookup resolves an IP address back to a hostname — the opposite direction of a normal (forward) DNS lookup, which resolves a hostname to an IP address. It works through PTR (pointer) records, stored under the special in-addr.arpa domain for IPv4 addresses and ip6.arpa for IPv6 addresses, which is queried the same way as any other DNS record but with the IP address's components reversed and appended to that special zone.
- The single most common practical reason to run a reverse lookup is mail deliverability: most receiving mail servers check that a sending IP's PTR record resolves to a hostname, and that hostname's own forward A record resolves back to the same IP — a match called forward-confirmed reverse DNS (FCrDNS). A missing or mismatched PTR record is one of the most common, and most overlooked, reasons legitimate outbound mail gets rejected or flagged as spam, independent of the actual message content.
- Beyond mail, reverse lookups are useful for basic network investigation: turning an unfamiliar IP address seen in logs into a human-readable hostname often immediately reveals what kind of system it is (a cloud provider's generic naming pattern, an ISP's residential range, a known CDN, and so on).
How It Works
- The IP address is converted into its reverse-lookup domain name form: for IPv4, the octets are reversed and appended to in-addr.arpa (e.g. 8.8.8.8 becomes 8.8.8.8.in-addr.arpa); for IPv6, the address is fully expanded, each hex digit is reversed, and appended to ip6.arpa.
- A standard DNS query for a PTR record is sent for that reverse domain name.
- If a PTR record exists, its value — a hostname — is returned.
- For mail-deliverability checks specifically, the tool can also verify the returned hostname's own forward A/AAAA record resolves back to the original IP, confirming a full forward-confirmed reverse DNS match rather than just the existence of a PTR record.
Usage
- Enter the IP address you want to resolve.
- Run the reverse lookup.
- Review the returned hostname from the PTR record, if one exists.
- For mail-deliverability troubleshooting specifically, also check that the returned hostname's forward A record resolves back to the same original IP — a mismatch here is the actual problem, not just the PTR record's mere existence.
Examples
- Reverse-resolving 8.8.8.8 to confirm its PTR record returns a hostname under Google's own domain, consistent with it being a Google-operated public DNS resolver.
- Diagnosing rejected outbound mail by discovering the sending server's IP has no PTR record at all — the single most common root cause of this specific failure mode.
- Reverse-resolving an unfamiliar IP from a web server's access log and finding it belongs to a known search-engine crawler's PTR naming pattern.
- Verifying a newly-provisioned mail server's PTR record was configured correctly by the hosting provider before going live.
Real-World Use Cases
- Diagnosing why outbound mail from a server is being rejected or marked as spam by checking whether its sending IP has a correct, matching PTR record.
- Turning unfamiliar IP addresses seen in server access logs or firewall logs into readable hostnames as a first investigative step.
- Verifying that a mail server, VPN endpoint, or other service you operate has the PTR record it's supposed to have, as part of a deployment checklist.
- Confirming whether a given IP belongs to a residential ISP range, a data center, or a known cloud provider, based on the naming pattern of its PTR record.
Best Practices
- If you operate a mail server, verify PTR record correctness (and forward-confirmed reverse DNS) as a standard step before going live, not after mail starts getting rejected.
- Request PTR record configuration from your hosting or cloud provider at provisioning time — most providers require a support request or console setting to assign a custom PTR record to an IP, since the reverse zone is normally controlled by whoever owns the address block, not the customer.
- Don't rely on PTR records alone as proof of an IP's identity or trustworthiness — treat a reverse lookup as one input among several (alongside ASN and WHOIS data) when investigating unfamiliar traffic.
- When troubleshooting mail deliverability, check both directions explicitly: does the IP have a PTR record, and does that PTR hostname's forward record actually point back to the same IP — a passing check requires both.
Common Mistakes
- Assuming every IP address has a PTR record — many, especially residential and dynamically-assigned ranges, simply don't, and that absence itself can be a deliverability or trust signal depending on context.
- Confusing a PTR record's existence with a full forward-confirmed match — a PTR record can point to a hostname whose own forward record resolves to a completely different IP, which most strict mail servers treat as equivalent to having no PTR record at all.
- Assuming you can set your own PTR record the same way you manage your domain's other DNS records — PTR records for the in-addr.arpa/ip6.arpa zones are controlled by whoever owns the IP address block, typically your hosting or cloud provider, not your own DNS provider.
- Treating a reverse-lookup hostname as fully authoritative identity information — like any DNS record, PTR records are set by whoever controls that reverse zone and can be configured to say anything, including misleading values.
Limitations
- Not every IP address has a PTR record configured — a missing result may simply mean none exists, which is itself useful information for mail-deliverability contexts but not an error in the lookup itself.
- Setting or changing a PTR record isn't something this tool can do — it can only look up what's currently configured; changing it requires access to whoever controls the address block's reverse DNS zone, typically your ISP or cloud provider.
- A successful reverse lookup confirms what hostname is configured, not that the entity operating that hostname is trustworthy — treat it as one investigative signal, not a verdict.
Technical Reference Guide
- The reverse-mapping domains (in-addr.arpa for IPv4, ip6.arpa for IPv6) and PTR record mechanics are defined as part of the core DNS specification, RFC 1035.
- Forward-confirmed reverse DNS (FCrDNS), the practice of checking that a PTR-resolved hostname's own forward record matches the original IP, is a widely-adopted anti-spam heuristic though not itself a single formal RFC — many mail server implementations document their specific FCrDNS requirements independently.
- IPv6 reverse mapping under ip6.arpa uses the fully expanded, nibble-reversed address form, distinct from IPv4's octet-reversed in-addr.arpa convention.
FAQ
Why does my outbound mail get rejected even though my domain's SPF and DKIM are set up correctly?
Check the sending IP's PTR record first — many receiving mail servers reject or heavily penalize mail from IPs with no PTR record or a PTR record that doesn't forward-resolve back to the same IP, independent of SPF/DKIM/DMARC configuration.
Can I set my own PTR record through my domain's DNS provider?
No — PTR records live in the reverse DNS zone controlled by whoever owns the IP address block, which is typically your hosting or cloud provider. You'll usually need to request it through their support channel or console, not your domain registrar.
What does it mean if an IP has no PTR record at all?
It means reverse DNS simply isn't configured for that address — common for residential and dynamic IP ranges. For mail-sending IPs specifically, this absence is itself a negative deliverability signal to many receiving servers.
Is reverse DNS the same thing as a PTR lookup?
Yes — 'reverse DNS lookup' and 'PTR lookup' describe the same operation: resolving an IP address back to a hostname via a PTR record under the in-addr.arpa (IPv4) or ip6.arpa (IPv6) zone.
What is forward-confirmed reverse DNS (FCrDNS)?
It's the practice of checking two things together: that an IP's PTR record resolves to a hostname, and that hostname's own forward A/AAAA record resolves back to the exact same IP. Passing both checks is a stronger trust signal than a PTR record alone.
Can a PTR record point to any hostname, even a misleading one?
Yes — like any DNS record, a PTR record's value is simply whatever whoever controls that reverse zone configured it to be. It's a useful signal, especially combined with a forward-confirmation check, but not cryptographic proof of identity.
Part of this Developer Hub
This utility is part of our comprehensive Domain Name System (DNS) topic workspace.
Explore foundational guidelines, technical specifications, and other interactive utilities related to this workflow.
Related Tools
Explore related utilities inside the Network Operations Lab workshop for complementary engineering workflows.
View all Network Operations Lab tools