Reverse DNS (PTR) Records: Who Actually Needs Them

Reverse DNS confuses people for a good reason: it is the one common DNS task where you usually cannot fix the problem yourself. The record lives in a zone you do not control, in a namespace that looks like it was designed by a committee — because it was.

Still, reverse DNS is not hard once you understand where it lives and who is allowed to edit it. This article covers what PTR records are for, why email providers care about them, and how to get one set up when you do not own the zone.

Forward and reverse are not the same thing

Forward DNS maps a name to an address. You ask for mail.example.com and get back an IP. That is the direction everyone learns first.

Reverse DNS maps an address back to a name. You ask about an IP and get back a hostname. That is what PTR records do, and they exist because logs, mail servers, and security tooling frequently have an IP address in hand and want a human-readable label for it.

The two directions are stored separately and can disagree. This is important: a PTR record does not have to match the A record for the same host. Nothing in the protocol enforces consistency. When forward and reverse do match, that agreement is called forward-confirmed reverse DNS, and it functions as a weak trust signal — which is exactly why mail providers look for it.

Why you cannot add a PTR in your own DNS panel

Here is the part that trips up almost everyone. PTR records are not stored in example.com. They live under a separate hierarchy, in-addr.arpa for IPv4 and ip6.arpa for IPv6, and that hierarchy is delegated by IP address block, not by domain name.

To look up an IPv4 address, you reverse the four octets and append in-addr.arpa. The address 203.0.113.25 becomes 25.113.0.203.in-addr.arpa. IPv6 gets the same treatment but nibble by nibble, which is why those names look so long.

Because the zone is organised by address block, the PTR record for your server is in the zone of whoever owns that IP block — your hosting provider, your ISP, or your cloud vendor. If you own the block and run your own nameservers, you can create PTR records yourself. If you rent a server from someone else, you generally cannot, and your DNS panel will simply not have a place to put them. Try it on DNS Checkers Reverse DNS

How to actually get a PTR record set

If you do not own the IP block, the path is through your provider. What that looks like depends on who they are.

Managed hosts sometimes expose a "reverse DNS" field directly in their control panel, and you set the hostname right there. Cloud providers often have a dedicated setting per elastic IP. Smaller providers may require a support ticket. Shared hosting usually does not offer PTR control at all, because the IP is shared and a single address cannot sensibly have many reverse names.

When you make the request, give them the exact hostname you want, and make sure it is one that resolves forward to the same IP. Asking for a PTR to a name that does not exist creates a mismatch that is worse than having no PTR at all.

One more caveat: on some networks, the provider sets the PTR for you automatically, usually to a generic hostname like a pool address. That generic name is not what mail providers want to see. If your reverse DNS looks like a random string your host assigned, request the change.

FCrDNS, and why mail servers obsess over it

Mail is where reverse DNS earns its reputation. When a mail server connects to deliver a message, the receiving server often performs a reverse lookup on the connecting IP, then a forward lookup on the resulting hostname to confirm it points back to the same address.

That two-step check is forward-confirmed reverse DNS. Both halves must agree for it to pass. A PTR record alone is not enough, and a forward record alone is not enough. The pair has to line up.

Why does this matter so much? Because a matching forward and reverse lookup is harder for a spammer to fake than either one on its own. It is not a strong guarantee — anyone with control of a legitimate IP block can set it up — but it raises the cost of casual abuse, and inbox providers use it as one signal among many. Failing it does not guarantee your mail is rejected, but it gives receivers a reason to be suspicious. Try it on DNS Checkers MX Lookup

A related detail worth knowing: the HELO name your mail server announces should also resolve, ideally to the same IP. The best practice is to use a hostname for the server, not a bare IP address, and to make forward and reverse agree. If your server says "HELO 203.0.113.25" in its greeting, you have handed the receiver a reason to distrust you before the first byte of the message.

The cloud and VPS gotchas

If you run mail on a VPS or cloud instance, reverse DNS is only part of the story. Two other things routinely break deliverability on cloud IPs.

First, many cloud providers reserve large IP ranges that are effectively pre-flagged as unlikely to send legitimate mail. A brand-new instance on such a range can have perfect SPF, DKIM, DMARC, and reverse DNS and still struggle, because the reputation of the address block precedes you. This is a reputation problem, not a DNS one, and the fix is usually to use a dedicated sending service rather than to keep adjusting records.

Second, some providers let you set reverse DNS only on addresses you have explicitly reserved, not on the ephemeral address the instance boots with. If the PTR option seems missing, double-check you are editing the right address.

Neither of these is a reason to skip reverse DNS. It is a reason to understand that it is one part of a larger picture.

When PTR matters beyond email

Mail gets all the attention, but reverse DNS shows up elsewhere.

When you read a web server access log, the client IPs are just numbers. Reverse lookups can turn some of them into names, which occasionally reveals that a persistent scanner comes from a known cloud range. When you investigate an intrusion, the ability to resolve an address to a hostname can shorten the trail. And some monitoring, authentication, and logging systems use reverse lookups purely for readability.

None of those depend on a perfect match the way mail does. They are conveniences. But if you are already setting up reverse DNS for your mail servers, doing the same for your other infrastructure costs little and makes your logs friendlier to read.

How to check a PTR record

Testing reverse DNS is straightforward, and worth doing after any server change.

Start with the address and ask for its reverse name. Then take that hostname and ask for its forward address. If both resolve and the address matches, you have forward-confirmed reverse DNS. If either step fails or the results disagree, you have something to fix — and now you know which side is wrong.

The DNS Checkers reverse DNS tool does the first lookup directly, and the "what's my IP" tool gives you the address to feed into it if you are unsure what the outside world sees. Try it on DNS Checkers Open DNS Checkers Tools

Do this after every server migration. It takes a minute, and it prevents the slow, confusing kind of deliverability decay where everything looks configured but mail quietly starts bouncing.

IPv6 changes the shape, not the idea

Everything above applies to IPv6, but the mechanics look alien the first time. Instead of reversing four octets, you reverse every hexadecimal digit of the expanded address, separate them with dots, and append ip6.arpa.

An address that reads 2001:db8::1 expands to thirty-two hex digits, and the reverse name is those digits in reverse order, dotted, under ip6.arpa. The result is long enough that nobody types it by hand. That is fine — it is a job for tooling, not for humans.

The important consequence is that IPv6 reverse zones are delegated by prefix, and the prefixes involved are often large. A hosting provider handing you a /64 is giving you an enormous reverse zone, far more space than you will ever populate, but one you are now responsible for. Some providers delegate this automatically; others will set PTR records for you on request. Ask which model applies before you assume.

The other practical trap is that your mail server may be sending over IPv6 without you realising it. If you configured SPF and DKIM for the IPv4 path and the server prefers IPv6, receivers will see a different sending address — one whose reverse DNS may not exist at all. When a domain that looks correctly configured still fails authentication, checking whether the mail actually left over IPv6 is a fast way to find the gap.

None of this is harder than the IPv4 version. It is just less familiar, and it rewards the same discipline: confirm the reverse name, confirm the forward name, and make sure they agree on the address the world actually sees.

The mindset

Reverse DNS feels awkward because it is genuinely different from everything else in this guide. It lives in someone else's zone, it is delegated by address block rather than by domain, and you may need to file a ticket to change it.

But the mental model is simple enough: a PTR answers "what name belongs to this address," it must agree with the forward record to be worth anything, and your provider is the one who can create it. Understand those three facts and you have covered the part that confuses most people — the part where the record you need is nowhere in the panel you are staring at.