Reverse DNS answers the mirror question of every normal lookup: not "which IP does this name point to" but "which name does this IP claim". The answer lives in a PTR record, in a part of the DNS tree most people never touch, controlled by whoever owns the IP rather than whoever owns the domain. That split is the source of nearly every reverse-DNS problem, and it is why this tool does not stop at the PTR: it resolves the answer forward again and tells you whether the two directions agree.
What a reverse lookup is
Type an IPv4 or IPv6 address and two things happen. First, the reverse name is constructed in your browser and shown under the input, so you see the actual DNS name being queried instead of a black box. For 8.8.8.8 that is 8.8.8.8.in-addr.arpa (a palindrome by coincidence); for an IPv6 address it is a 34-label nibble name under ip6.arpa. Then one DNS-over-HTTPS request goes straight from this tab to the resolver you picked, and the PTR answer comes back with its live TTL.
The lookup is exactly what dig -x does, and the matching command is displayed next to the result, ready to copy. Nothing passes through a devholster server on the way; the query goes from your browser to Cloudflare, Google, AliDNS or whichever of the six resolvers you chose.
How the arpa name is built
PTR records cannot live in your domain's zone, because a resolver looking up an IP has no idea which domain to ask. Instead, the DNS tree has two dedicated branches: in-addr.arpa for IPv4 and ip6.arpa for IPv6. The address itself becomes the name, written backwards so that delegation follows the address hierarchy from most significant part down, the same way domains delegate from the TLD down.
For IPv4, the four octets are reversed: 192.0.2.5 becomes 5.2.0.192.in-addr.arpa. The block 192.0.2.0/24 maps to the zone 2.0.192.in-addr.arpa, which the address registry delegates to the block's owner, who can then publish PTR records for each address in it. Delegation works cleanly on octet boundaries (/8, /16, /24); for smaller allocations providers use the CNAME construction from RFC 2317, which is why the PTR for an IP in a /29 sometimes takes a detour through a strangely named intermediate record.
IPv6 works the same way at a finer grain: the full 128-bit address is written as 32 hex nibbles, each nibble becomes one label, and the whole thing is reversed under ip6.arpa. 2001:db8::1 turns into 1.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 zeros that :: compresses away in normal writing all come back, because the reverse name needs every nibble. Building that by hand is error-prone enough that seeing the constructed name is half the reason this tool exists; the other half is the confirmation check.
Forward-confirmed reverse DNS
A PTR record by itself proves very little. The owner of an IP block can point a PTR at any hostname, including one in a domain they have nothing to do with; nothing in the reverse tree stops 203.0.113.7 from claiming to be mail.google.com. What closes the loop is resolving the claimed hostname forward and checking that the original IP is among its A or AAAA records. The reverse record is controlled by the block owner and the forward record by the domain owner, so when both agree, both parties have vouched for the mapping. That two-way agreement is forward-confirmed reverse DNS, FCrDNS.
This tool runs the confirmation automatically. After the PTR answer arrives, each returned hostname (up to three) is resolved forward at the same resolver, over IPv6 when you entered an IPv6 address, and the verdict lands in the findings: green when a forward address matches your IP, amber when the hostname resolves elsewhere or not at all. The comparison normalises IPv6 spelling first, so 2001:DB8:0:0::1 and 2001:db8::1 count as the same address, as they should.
The check is quietly everywhere. Mail receivers run it before trusting a sending server. OpenSSH logs a warning when a connecting client fails it. Rate limiters and abuse systems use it to decide whether a crawler claiming to be Googlebot is real, since Google's crawler IPs all forward-confirm. If you operate anything that talks to other people's servers, FCrDNS is one of the cheapest reputation signals you control.
Who controls the PTR record
The single most useful fact on this page: you cannot set a PTR record in your domain's DNS, no matter what your DNS provider's record editor lets you type. The reverse zones are delegated along the IP hierarchy, from IANA to the regional registries (RIPE, ARIN and the others) to the holder of the address block. For a rented server or cloud VM that is your hosting provider; for an office connection, your ISP.
What that means in practice: the PTR is configured wherever you manage the IP, and the forward record it points to is configured in your DNS zone, and both halves have to be done by you, in two different control panels. The typical broken state is a half-finished pair, a PTR pointing at mail.example.com while nobody created the matching A record, or a correct A record while the IP still carries the provider's default name from the day the VM was created.
Those defaults are recognisable on sight: static-203-0-113-7.provider.net, ec2-52-3-45-67.compute-1.amazonaws.com, 203-0-113-7.dynamic.isp.example. The tool flags PTR names matching these patterns, because for a mail-sending IP a generic reverse name is nearly as damaging as none: it signals that nobody claimed the IP, which is exactly what a snowshoe spammer's IP looks like.
Reverse DNS and mail delivery
Reverse DNS is a mail topic more than anything else, and the requirements have hardened. Google's sender guidelines require that a sending IP has a PTR and that it forward-confirms, and their SMTP servers turn mail away from IPs without valid reverse DNS with a "does not meet IPv6 sending guidelines" style rejection, IPv6 senders being checked especially strictly. Outlook.com weighs missing or generic PTRs heavily in filtering, and plenty of smaller gateways simply refuse connections that fail FCrDNS at the TCP greeting.
The PTR does not need to match your mail domain, a misconception that costs people hours: mail for example.com sent from mailout.hosting-provider.net is fine, as long as that name forward-confirms to the sending IP and your SPF record authorises the IP. What matters is the triangle of IP, PTR and forward record being consistent. The record checks on the sending domain itself (SPF, DKIM, DMARC) are a separate layer, covered by their own guide and check tools; reverse DNS is about the sending machine, not the sending domain.
If you run your own mail, fix the PTR before touching anything else. It is one field in the provider panel plus one A record, it takes effect within the reverse zone's TTL, and it is the difference between being evaluated as a mail server and being dropped as an unclaimed IP.
Reading the verdicts
The findings under the result reduce to a few states worth recognising. Green with forward confirmation: PTR exists, hostname resolves back to your IP, nothing to do. Amber, no PTR: the reverse zone has no entry for this IP; only the block holder can add one, so this is a support ticket or a panel field, never a DNS zone edit on your side. Amber, not forward-confirmed: the PTR exists but its hostname resolves to different addresses or none, so create or fix the forward record in the zone that hostname belongs to. Info, provider-generated name: reverse DNS technically works but still carries the default name, worth replacing on any IP that sends mail.
Two subtleties surface regularly. NXDOMAIN and an empty NOERROR answer both mean "no usable PTR" here, and providers produce both variants depending on how their reverse zones are set up, so the tool treats them the same. And answers are cached like any DNS record: after changing a PTR, resolvers can serve the old value until the TTL runs out, so a re-check right after saving shows the cache, not your change. The TTL next to the answer tells you how long that window still is; the mechanics of why caches behave this way are covered in the DNS propagation guide.
For the forward direction, or to chase where a PTR's hostname actually points, the DNS lookup covers all nine record types with the same resolver choices.
PTR record questions
How do I set a PTR record for my IP address?
Through whoever assigned you the IP, not through your domain’s DNS. Hosting providers usually expose a "reverse DNS" or "PTR" field per IP in their panel; ISPs handle it via support ticket, and for residential connections mostly not at all. Set it to a hostname that resolves back to the same IP, for example mail.example.com, and create that A or AAAA record first, because a PTR pointing at a name that does not resolve fails the forward-confirmation check most receivers run.
Why can I not add a PTR record in my domain’s DNS zone?
Because PTR records do not live in your domain’s zone at all. They live in the reverse zones under in-addr.arpa and ip6.arpa, and those are delegated along the IP address hierarchy: from IANA to the regional registries to whoever holds the address block, which is your hosting provider or ISP. A PTR you add to example.com’s zone is syntactically valid and completely ignored, since no resolver ever looks for reverse data there. Only the block holder can publish the record that resolvers actually find.
What are in-addr.arpa and ip6.arpa?
The two DNS namespaces where reverse mappings live. For IPv4, the address octets are reversed and appended to in-addr.arpa: 8.8.8.8 becomes 8.8.8.8.in-addr.arpa, and 192.0.2.5 becomes 5.2.0.192.in-addr.arpa. The reversal exists so that delegation can follow the address hierarchy, with the most significant octet at the top. For IPv6, every hex nibble of the full 32-digit address becomes one label under ip6.arpa, reversed the same way, which is why those names are 34 labels long and nobody types them by hand.
What is forward-confirmed reverse DNS (FCrDNS)?
A two-step check: look up the PTR for an IP, then resolve the resulting hostname forward and confirm the original IP is among its addresses. Only when both directions agree is the naming considered trustworthy, because the block holder controls the PTR and the domain holder controls the forward record, so agreement means both parties vouch for the mapping. Mail servers, some SSH configurations and various anti-abuse systems run exactly this check. A PTR alone, without the matching forward record, fails it.
Do I need reverse DNS to send email?
In practice yes. Google requires that a sending IP has a PTR record and that it forward-confirms, and rejects mail from IPs without valid reverse DNS on its ports for large senders; Outlook.com and most corporate gateways score heavily against missing or generic PTRs. The PTR does not have to match your From domain, it has to be a real hostname that resolves back to the IP. mail.example.com on a PTR with a matching A record is the standard setup; a leftover default like static-1-2-3-4.provider.net gets your mail into spam folders even when SPF and DKIM are correct.
How do I set reverse DNS on a cloud VM?
Each provider hides it somewhere else. AWS: for EC2 elastic IPs you file the PTR in the Elastic IP settings, and AWS additionally requires it before removing port-25 throttles. Google Cloud: set it on the reserved external address. Azure: the PTR is a property of the public IP resource (-ReverseFqdn). Hetzner, DigitalOcean, OVH: a reverse DNS field next to the IP in the panel, with DigitalOcean deriving it from the droplet name. In every case the forward record in your own zone is your job, and without it the PTR fails confirmation.
How do I do a reverse DNS lookup in the terminal?
dig -x 8.8.8.8 is the canonical command; it builds the in-addr.arpa name for you and queries PTR, and it works for IPv6 addresses the same way. Add +short for just the hostname. host 8.8.8.8 is the compact alternative, and on Windows nslookup 8.8.8.8 does the reverse lookup automatically when you pass an IP. To verify FCrDNS by hand, follow up with dig A on the returned hostname and compare the address, which is the pair of steps this tool automates.
Can one IP address have multiple PTR records?
Technically yes, RFC 2181 explicitly allows it, and you occasionally see it on shared hosting where one IP serves many sites. It is still a bad idea for anything that sends mail: verifying servers pick one PTR, not all of them, and which one they pick is undefined, so your carefully forward-confirmed name may never be the one checked. The safe configuration is one PTR per sending IP, pointing at one hostname with a matching forward record.