You already know the forward direction, even if you've never called it that. You type a name, DNS hands back an address: serverrecords.com becomes an IPv4 address like 192.0.2.1, or an IPv6 address like 2001:db8::1. That answers a simple question — where is this domain hosted?
Reverse DNS asks the opposite. You hand it an address and it hands back a name. The record that makes this work is the PTR (pointer) record, and the question it answers is "who does this IP claim to be?" That claim turns out to matter a great deal for email, security tooling, and anyone reading server logs at 2am trying to figure out where a connection came from.
If you just want to see what an address resolves to right now, the PTR record lookup takes an IP — v4 or v6 — and returns the PTR hostname on file for it. The rest of this piece is about what that hostname means and why it's worth checking.
Why you can't just look up an IP directly
DNS is built around names, and names read right to left. In www.serverrecords.com, .com is the top of the tree, then serverrecords, then www. IP addresses run the other way — 192.0.2.1 gets more specific as you read left to right. Those two orderings don't line up, so you can't drop a raw address into the DNS hierarchy and expect it to resolve.
The workaround is a pair of special-purpose domains that exist only for reverse lookups: in-addr.arpa for IPv4 and ip6.arpa for IPv6. To query an address, you rewrite it as a name that fits the tree.
For IPv4, you reverse the four octets and append the suffix. Take 198.51.100.42:
IPv6 works the same way with more digits. An address is 128 bits written in hex; you reverse it one nibble (4 bits) at a time, put a dot between each, and append ip6.arpa. So 2001:db8::1 expands out to 1.0.0.0.….0.8.b.d.0.1.0.0.2.ip6.arpa. It's tedious to do by hand, which is most of the reason a lookup tool exists — you give it the address, it builds the reversed name and fetches the record.
The mistake everyone makes: who controls the PTR
Here's the trap. You set your A records in your registrar's DNS panel, so it feels natural to look for PTR records in the same place. They aren't there, and you can't add them there.
Forward DNS belongs to whoever owns the domain — that's you, through your registrar. Reverse DNS belongs to whoever owns the IP block, and that's almost never you. It's your ISP, your data center, or your cloud provider: AWS, DigitalOcean, Hetzner, Linode, and the rest. They hold the reverse zone for the addresses they lease out.
So setting a PTR means going somewhere else entirely. You either set it in your provider's network or server console (most cloud dashboards have a "reverse DNS" or "PTR" field on the instance or IP), or you ask them to delegate the reverse zone to you or set the string on your behalf. If you've been hunting for a PTR option in your registrar dashboard and coming up empty, this is why.
Not sure who owns the block in the first place? An IP ownership / ASN lookup tells you which provider and network an address belongs to, which is usually enough to figure out whose portal you need.
Why mail servers care so much
The reason PTR records get attention at all is outbound email. Gmail, Outlook, Yahoo, and every serious spam appliance run a check called Forward-Confirmed Reverse DNS, or FCrDNS, on incoming connections. It's a cheap, effective way to weed out the sort of hosts that spew spam — compromised boxes and throwaway cloud instances rarely have their reverse DNS set up properly.
The check is two steps, and the trick is that it goes both directions.
Passing means the reverse record and the forward record agree: the IP names a host, and that host points back to the same IP. Either half can fail you. If the PTR is missing entirely, or it returns a generic provider hostname like host-198-51-100-42.static.provider.net, or it points to a name that resolves somewhere else, a strict receiver won't accept the mail. What you get back is a rejection along the lines of 550 5.7.1, and your message never lands.
That generic-hostname problem catches a lot of people. A fresh cloud IP comes with a default PTR that looks machine-generated, because it is. It technically resolves, but it doesn't match your mail hostname, and it screams "I did not configure this server for mail." Providers treat it accordingly.
What the lookup tells you, and what to check next
The PTR record lookup does the reverse resolution for you: feed it an IPv4 or IPv6 address, it builds the in-addr.arpa or ip6.arpa query, and shows you the PTR hostname that comes back — including whether it looks like a generic provider default rather than a real mail name.
One thing worth being precise about: the lookup shows you the reverse (PTR) direction. It does not, on its own, re-query that hostname to confirm the forward direction and complete the FCrDNS match — that's the check a receiving mail server performs, not something the tool does automatically. To confirm the round trip yourself, take the hostname the PTR returns and run it through an A/AAAA record lookup. If that resolves back to the same IP you started with, you've verified by hand exactly what a mailbox provider would verify: the two records agree.
A couple of related habits close the loop. If mail is bouncing and you're not certain the receiving side can even find you, check your MX record lookup points where you expect before you blame reverse DNS. And because a clean PTR is worth nothing if your IP has a bad history, a blacklist lookup tells you whether the address is already on a DNSBL — a separate problem that FCrDNS won't fix.
The short version
Reverse DNS is the direction most people forget until their mail starts bouncing. Set the PTR through whoever owns your IP, not your registrar; give it a real hostname, not the provider's default; and make sure that hostname resolves back to the address it came from. Check the reverse record with the lookup, confirm the forward record yourself, and you'll know your server looks trustworthy before a receiving server has to decide for you.