Reverse DNS that mail servers and traceroutes trust

Forward DNS maps a name to an address. Reverse DNS maps an address back to a name, and it is the half most people never set. Nothing breaks loudly when it is missing, which is exactly why it stays missing until something important quietly refuses to work.

Three things care:

• Receiving mail servers. Many reject or heavily penalise mail from an address with no PTR, or with a PTR that does not resolve back to the same address.
• Traceroute and diagnostics. A hop that shows a hostname tells whoever is debugging where they are. A bare address tells them nothing.
• Logs and access control. Anything doing reverse lookups on connecting addresses records your PTR, or records nothing.

Addresses below are documentation examples: 203.0.113.10 and 2001:db8:100::10. Use the addresses issued to your VPS.

How reverse DNS actually resolves

A PTR lookup is a normal DNS query against a special name. The address is reversed and placed under a dedicated zone.

For IPv4, 203.0.113.10 becomes:

10.113.0.203.in-addr.arpa

For IPv6, every nibble is reversed and separated by dots under ip6.arpa. The address 2001:db8:100::10 expands to 32 nibbles:

0.1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.1.0.8.b.d.0.1.0.0.2.ip6.arpa

The important consequence: you cannot set a PTR in your own DNS zone. Authority for those names follows the address, not the domain. It belongs to whoever holds the address block, so the record is set through your provider's control panel, or delegated to you if you hold the block yourself.

1. Set the IPv4 PTR

In VPS Control, open the network settings for the server and set the reverse DNS entry for the address to the hostname you want it to report:

203.0.113.10  ->  mail.example.com

One address, one PTR. Multiple PTRs for a single address are legal but cause inconsistent results, because a checker gets whichever answer it happens to read. Pick one canonical name.

The name you choose should be a real hostname in a domain you control, with a matching forward record. mail.example.com is useful. A generic provider-issued name is better than nothing but carries no reputation. A name that does not resolve forward is worse than no PTR at all, because it looks like a misconfiguration to anything checking.

2. Set the IPv6 PTR without counting nibbles

The expansion is mechanical and easy to get wrong by hand. Let a tool do it.

dig will tell you the exact name it would query:

dig -x 2001:db8:100::10 +norecurse | grep ';.*ip6.arpa'

Or compute it directly with Python, which is useful when scripting a batch of records:

python3 -c "
import ipaddress
print(ipaddress.ip_address('2001:db8:100::10').reverse_pointer)
"

That prints the full ip6.arpa name. Set the PTR for the IPv6 address in the control panel the same way you did for IPv4, pointing at the same hostname.

Set both. A dual-stack host that connects over IPv6 and has a PTR only for its IPv4 address will be judged on the address it actually used, and will fail.

3. Make forward and reverse agree

Forward-confirmed reverse DNS, sometimes written FCrDNS, is the check that actually matters. It has two steps:

1. Look up the PTR for the address, getting a hostname.
2. Look up that hostname, and confirm it resolves back to the original address.

Both must succeed and agree. This is what a receiving mail server is doing when it decides whether your connection looks legitimate.

So the forward record has to exist too, in your own zone:

mail.example.com.   A      203.0.113.10
mail.example.com.   AAAA   2001:db8:100::10

The pair has to be symmetric on both protocols. If mail.example.com has an AAAA record pointing at an address whose PTR says something else, the IPv6 path fails the check while IPv4 passes, and you get the maddening result of mail being accepted by some recipients and not others.

4. Verify from outside

Do not trust the control panel's confirmation. Query it.

Check the reverse:

dig +short -x 203.0.113.10
dig +short -x 2001:db8:100::10

Both should print your hostname with a trailing dot.

Check the forward:

dig +short mail.example.com A
dig +short mail.example.com AAAA

Both should print the addresses you started with.

Confirm the round trip in one step:

host 203.0.113.10
host 2001:db8:100::10

For mail specifically, the connecting name also needs to match what your server introduces itself as. Check the HELO or EHLO name your MTA sends:

postconf myhostname

That value, the PTR, and the forward record should all be the same name. A server that greets as localhost.localdomain while its PTR says mail.example.com is announcing an inconsistency to every recipient.

Propagation and caching

Reverse zones are cached like anything else in DNS. After a change, the old answer can persist for the remainder of its TTL, and some resolvers hold negative answers too, so an address that had no PTR at all may keep appearing to have none for a while.

Query an authoritative server directly to see the current truth rather than a cached copy:

dig -x 203.0.113.10 @1.1.1.1
dig -x 203.0.113.10 +trace

The +trace output walks the delegation from the root and shows which nameservers are answering for the reverse zone, which is the fastest way to tell "not published yet" apart from "published, still cached".

Diagnosing reverse DNS

Checklist

• Every public address on the VPS has exactly one PTR.
• IPv4 and IPv6 both have PTRs, pointing at the same hostname.
• That hostname has matching A and AAAA records in a zone you control.
• host <address> completes the round trip on both protocols.
• Your MTA's HELO name matches the PTR.
• You verified against an authoritative nameserver, not a cached answer.

Reverse DNS takes ten minutes and is invisible when correct. The only time you find out it was wrong is when someone else's server has already decided about you.