A mail server rejects your messages with "no reverse DNS" or "PTR does not match". A firewall log is full of bare IP addresses and you want to know which provider or host they belong to. Both cases need the reverse direction of DNS: from an IP address to a hostname.
The Reverse DNS tool looks up the PTR record of a public IPv4 or IPv6 address and shows the hostname it maps to, together with the exact in-addr.arpa or ip6.arpa name that was queried. Use it to check a mail server before sending, to identify addresses in logs, or to confirm that a provider has applied a reverse DNS change.
What is Reverse DNS?
In simple terms
Normal DNS answers "which IP does this name have?". Reverse DNS answers "which name does this IP have?". The answer is a PTR record set by whoever controls the IP address, usually your internet or hosting provider. Many addresses have one (dns.google for 8.8.8.8, for example), many have none, and the name it gives is only as trustworthy as the person who set it.
Technical background
Reverse lookups use ordinary DNS queries against special zones (RFC 1035, section 3.5, and RFC 3596 for IPv6):
- IPv4: the four octets are reversed and
in-addr.arpais appended.8.8.8.8becomes8.8.8.8.in-addr.arpa;198.51.100.25becomes25.100.51.198.in-addr.arpa. Reversing puts the most significant part on the right, matching DNS's hierarchy, so blocks can be delegated like domains. - IPv6: the full 128-bit address is written as 32 hexadecimal nibbles, reversed, separated by dots and followed by
ip6.arpa.2001:db8::1becomes1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.8.b.d.0.1.0.0.2.ip6.arpa.
The reverse zones are delegated by the regional internet registries to the organizations that hold the address blocks, and from there often to customers. That is why the PTR for your server's IP is managed in the provider's panel, not in your domain's zone.
A PTR record by itself proves nothing: anyone who controls a reverse zone can point it at any name, including someone else's domain. That is why mail servers and security tools use forward-confirmed reverse DNS (FCrDNS): the PTR hostname must have an A or AAAA record that points back to the same IP.
Why use Reverse DNS?
- Mail delivery. Check that a sending IP has a PTR record before mail providers reject it, and that the name matches what the server announces in HELO/EHLO.
- Log analysis. Turn addresses from firewall, web server or SSH logs into recognizable names (
crawl-…,…cloud…,…dsl…). - Verify provider changes. After asking a host to set a PTR, confirm that public resolvers return it.
- Identify infrastructure. Router, CDN and cloud hostnames often encode the location or service.
- Sanity-check traceroute hops. Reverse names explain which networks a path crosses.
Who should use it?
- Mail server administrators preparing or troubleshooting outbound delivery.
- Network and security engineers reading logs or investigating traffic.
- Hosting and VPS customers setting up reverse DNS for a new server.
- Support staff who need to identify an address quickly.
How Reverse DNS works
The browser sends the IP address to the NetTools.tech server in Latvia. The server:
- Validates the address. It must be a syntactically valid, public IPv4 or IPv6 address. Private (RFC 1918), loopback, link-local, documentation and other reserved ranges are rejected, since public resolvers have nothing for them.
- Builds the reverse name (
…in-addr.arpaor…ip6.arpa) and shows it in the output, so you can repeat the query yourself withdig -x. - Queries the PTR record through the public resolvers Cloudflare 1.1.1.1 and Google 8.8.8.8 (1.1.1.1 first, 8.8.8.8 as fallback), with a 3-second timeout per attempt and an 8-second limit for the whole request.
- Returns the hostnames, up to 20. "Name not found" and "no data" are both reported as "no PTR record"; timeouts, SERVFAIL and refusals are reported as errors.
The tool does not perform the forward check (FCrDNS) automatically. To verify it, look up the returned hostname with Nslookup and compare the A or AAAA records with the IP.
How to use the NetTools.tech Reverse DNS
- Open Reverse DNS.
- Enter a public address in the IP address field, for example
8.8.8.8or2606:4700:4700::1111. - Press Run Reverse DNS, or click the
8.8.8.8example chip. - Read the hostname line and the query line below it. Use Copy to copy the result, or Open in terminal to run
/reversedns 8.8.8.8(aliases/ptrand/rdns) in the NetTools terminal.
Understanding the results
| Result | Meaning | What to look for |
|---|---|---|
IP → hostname | The PTR record(s) for the address | Matches the name your server uses (for mail, the HELO/EHLO name) |
| Several hostnames, comma-separated | More than one PTR record exists | Mail servers expect exactly one; remove extras |
| "No PTR record for IP" | The reverse name exists without a PTR, or does not exist at all | Normal for many addresses; a problem for mail servers |
| "Query … in-addr.arpa / ip6.arpa" | The exact reverse name queried | Use it with dig or to confirm the provider's delegation |
| "resolver 1.1.1.1, 8.8.8.8" | The public resolvers used | Answers are cached for the PTR record's TTL |
| Error: timeout or SERVFAIL | The reverse zone's servers did not answer correctly | Broken delegation of the reverse zone at the provider |
| Error: not a public address | Input was private, reserved or invalid | Use the public address, e.g. from What Is My IP |
Generic names such as 198-51-100-25.dsl.example.net are typical for residential and dynamic addresses. Many mail providers treat such names as a sign of a consumer connection, even when the PTR technically exists.
Example: checking a mail server before go-live
A new mail server sends as mail.example.com from a VPS address. In this example the address is shown as 198.51.100.25, a documentation address standing in for a real one (the tool itself only accepts real public addresses).
First lookup:
No PTR record for 198.51.100.25.
Query 25.100.51.198.in-addr.arpa · resolver 1.1.1.1, 8.8.8.8The admin sets the reverse DNS to mail.example.com in the hosting provider's panel. Later:
198.51.100.25 → mail.example.com
Query 25.100.51.198.in-addr.arpa · resolver 1.1.1.1, 8.8.8.8Then the forward check with Nslookup: mail.example.com, type A, returns 198.51.100.25. PTR and A agree, so the address is forward-confirmed, and the server's EHLO name should be set to mail.example.com as well.
A real, well-known case for comparison: 8.8.8.8 returns 8.8.8.8 → dns.google.
Common use cases
- Setting up and verifying reverse DNS for outbound mail servers.
- Checking why a provider such as a large mailbox host rejects your mail.
- Resolving addresses from firewall, IDS, web and SSH logs.
- Confirming that a reverse DNS change requested from a provider is live.
- Identifying the operator of an address before a Whois lookup.
Troubleshooting
No PTR record for my server's IP
Set it at the provider that owns the address: most hosting and cloud panels have a "reverse DNS" or "PTR" field per IP, sometimes only after the forward A record exists. Adding a PTR to your own domain's zone has no effect, because that zone is not authoritative for in-addr.arpa.
The PTR is set but the tool still shows the old name
Resolvers cache PTR answers for the record's TTL. Wait for it to expire and check again. If nothing changes after a day, ask the provider whether the reverse zone is delegated to the server where you made the change.
Mail servers still complain about reverse DNS
Check the forward direction: the PTR hostname must resolve back to the same IP. Also make sure the hostname is not generic, and that your server's HELO/EHLO name matches it. MX Lookup and Blacklist Check help with the rest of the mail picture.
SERVFAIL or timeout
The reverse zone is delegated to name servers that do not answer correctly, often after a customer delegation (common for /24 blocks and IPv6 prefixes) that was never configured. Ask the address holder to fix the delegation.
IPv6 address shows no PTR although IPv4 has one
IPv6 reverse DNS is separate and often not set automatically. Configure it for each address that sends mail or needs a name.
Common mistakes
- Creating a PTR record in your own domain's DNS zone instead of at the IP's provider.
- Setting a PTR that points to a name without a matching A or AAAA record.
- Trusting a PTR name as identity. It is set by the address holder and can claim any name.
- Using a generic or provider-default hostname for a mail server.
- Forgetting IPv6 when the server sends mail over IPv6.
- Entering a private address from your LAN; only public addresses have public reverse DNS.
Limitations
- PTR only. No automatic forward confirmation; check the returned name with Nslookup.
- Public resolvers. Answers come from 1.1.1.1 or 8.8.8.8 as seen from Latvia and may be cached; the tool does not query the reverse zone's authoritative servers directly.
- No ownership data. A PTR name does not tell you who holds the address block; use Whois or IP Lookup for that.
- Self-declared names. PTR records are not verified by anyone and can be misleading.
- Up to 20 hostnames are shown for one address.
- Single addresses only. No range or bulk lookups.
Security & privacy
The IP address you enter is sent to the NetTools.tech server, which queries the PTR record through Cloudflare and Google public resolvers. Those resolvers, and the name servers of the reverse zone, see a query for that address from the NetTools.tech server, not from you. Only public addresses are accepted, so internal reverse zones cannot be probed. Looking up an address does not contact the host behind it. No credentials are needed.
Related tools
- Nslookup – forward lookups to confirm a PTR hostname; guide: DNS lookup.
- Whois – who holds an IP block, via RDAP; guide: Whois lookup.
- MX Lookup – mail servers of a domain with their reverse DNS; guide: MX lookup.
- Blacklist Check – whether a sending IP is listed; guide: Email blacklist check.
- IP Lookup – network, ASN and location data for an address; guide: IP lookup.
- What Is My IP – your public address and its reverse DNS name.
- Category overview: DNS & domain tools.
Summary
Reverse DNS maps an IP address to a hostname through PTR records under in-addr.arpa and ip6.arpa, managed by whoever holds the address block. The NetTools.tech tool converts a public IPv4 or IPv6 address to its reverse name, queries the PTR through public resolvers and lists the hostnames or reports that none exist. For mail servers, combine it with a forward lookup of the returned name to confirm that both directions match.
Frequently asked questions
What is a PTR record?
A PTR (pointer) record maps an IP address back to a hostname. It is published under a special name derived from the address, such as 8.8.8.8.in-addr.arpa for IPv4 or a nibble-reversed name under ip6.arpa for IPv6.
Who can set the reverse DNS of my IP address?
Whoever the reverse zone for that address block is delegated to, which is almost always the ISP, hosting or cloud provider that owns the addresses. You change it in the provider's control panel or by asking their support, not in your own domain's DNS zone.
Why does my IP have no reverse DNS?
Many addresses simply have no PTR record, because the provider never created one or does not offer custom reverse DNS for that product. The tool then reports that no PTR record exists, which is normal for many client and cloud addresses.
Why does reverse DNS matter for email?
Receiving mail servers commonly check that the sending IP has a PTR record and that the hostname resolves back to the same IP. Mail from addresses without valid reverse DNS is often rejected or scored as spam.
What is forward-confirmed reverse DNS (FCrDNS)?
It means the PTR hostname of an IP has an A or AAAA record pointing back to the same IP. This tool shows the PTR result only; look up the returned hostname with Nslookup to confirm the forward direction.
Can an IP address have more than one PTR record?
Yes, DNS allows several PTR records for one name, and the tool lists all returned hostnames (up to 20). Mail servers and most software use only one, so a single PTR per address is the usual practice.
Can I look up private addresses like 192.168.1.10?
No. Only public IPv4 and IPv6 addresses are accepted, because the lookup goes through public resolvers that have no data for private ranges. Use your internal DNS server for private reverse zones.