DNS you know runs forward: mail.example.com → 203.0.113.7. Reverse DNS runs the other way: a query for 7.113.0.203.in-addr.arpa returns a PTR record naming the host. Because PTR records live in zones delegated along with the IP space itself, only whoever controls the address block — your hosting provider, not your domain registrar — can publish them. That obscure plumbing has one famous consequence: email. Receiving gateways treat the PTR as a first-pass honesty check, and a missing or generic one (static-1-2-3-4.provider.net) is among the strongest spam signals there is. If you run mail, rDNS is not optional; if you wonder why a host’s “custom rDNS” support matters, this page is the answer.
How the mechanism works
IPv4 reverse zones hang off in-addr.arpa with the octets reversed: the PTR for 203.0.113.7 lives at 7.113.0.203.in-addr.arpa. IPv6 uses ip6.arpa with reversed nibbles. Regional registries delegate these zones to whoever holds the address space; the holder (your host) runs the nameservers and publishes PTRs. That is why setting rDNS is a control-panel action with your VPS provider, while forward DNS stays wherever your domain is managed. Best practice pairs them: the PTR points to a hostname (mail.example.com), and that hostname’s A/AAAA record points back to the same IP — forward-confirmed reverse DNS (FCrDNS), the loop that proves whoever controls the IP and whoever controls the name agree.
Why mail lives and dies by it
SMTP is ancient and trust-starved; rDNS is one of the few checks available before a single byte of message content. Real-world gateway behaviour in 2026: no PTR → many large providers refuse the connection outright (Gmail says so in its sender requirements); generic PTR → scored as probable botnet/consumer-line traffic; FCrDNS matching your HELO name → baseline pass that lets SPF, DKIM and reputation do the rest. rDNS does not get you into the inbox — IP reputation and authentication do the heavy lifting — but its absence keeps you out before the contest starts. Our mail VPS checklist accordingly puts PTR setup in step one.
Beyond mail: the minor benefits
Traceroutes and logs become legible (edge.yourproject.net instead of a bare address), some SSH and IRC services resolve connecting peers for display or coarse filtering, and a coherent PTR is a small professionalism signal anywhere your IP shows up. None of these are critical; mail is the load-bearing use.
Setting custom rDNS on a VPS
The flow is the same everywhere: pick the hostname (say mail.example.com), create its forward A/AAAA record pointing at your VPS IP first, then have the PTR set to the same name — here, request it from your client area and it propagates within the hour, IPv4 and IPv6 both. Verify the loop with dig -x <your-ip> +short (expect your hostname) and dig <hostname> +short (expect your IP). Two gotchas: one PTR per address is the norm (multiple PTRs confuse gateways — pick one canonical mail name), and IPv6 needs its own PTR if you send mail over it; if you cannot keep v6 rDNS straight, send mail over IPv4 only rather than over a bare v6 address.
