VPSbitWhat is reverse DNS?
Reverse DNS maps an IP back to a hostname through a PTR record. How the mechanism works, why mail filters demand it, and how to set custom rDNS on a VPS.
Reverse DNS maps an IP address back to a hostname via a PTR record set by the IP's owner, and mail receivers at Gmail and Outlook check it at every connection — missing or mismatched rDNS is a classic spam signal.
The definition, precisely
Reverse DNS (rDNS) is the lookup that maps an IP address back to a hostname, stored in the DNS as a PTR record. Forward DNS answers "which IP does mail.example.com point to"; reverse DNS answers the mirror question: which name does 203.0.113.10 answer for. The record belongs to the address, not to the domain — a distinction that causes most of the confusion around setting it, because it means the PTR for your VPS IP has no default entry anywhere in your domain's DNS panel.
The lookup is ordinary DNS under the hood: resolvers query special reverse zones, and the answer is a hostname string. Nothing about it is exotic, and nothing about it is optional if the server sends mail. For every other workload it is quiet infrastructure — occasionally useful, rarely urgent, and cheap to set correctly once you know who controls the record.
VPS from $4.80* — Core on the annual term (list $6/mo), one invoice for 12 months, no auto-charges. Dedicated with IPMI from $39.20/mo. Crypto invoice, no KYC.
Launch nowHow the mechanism works
IPv4 reverse zones live under in-addr.arpa, with the address octets reversed: the PTR for 203.0.113.10 sits at 10.113.0.203.in-addr.arpa. IPv6 does the same under ip6.arpa, one hexadecimal nibble per label, which makes the records long but the logic identical. Whoever holds the address block controls the zone — the hosting provider or its upstream carrier, never your registrar and never your domain's DNS host. That is why PTR is a hosting-side setting.
The quality bar receivers apply is forward-confirmed rDNS, or FCrDNS: the hostname the PTR points to must itself resolve back to the same IP. A record that points into the void, or to a name that resolves elsewhere, scores like a missing record. The chain has three links — PTR exists, forward lookup confirms it, and the name is one you control — and all three are checked automatically at every mail handshake.
Delegation explains the control structure: the regional registry delegates each block's reverse zone to the block holder, the same way a registrar delegates a forward domain to its nameservers. That is also why moving a server does not move the record — the PTR stays with the address, and a migration that forgets to reset it leaves your mail announcing the previous provider's name for weeks.
Why mail lives and dies by it
Receiving filters at Gmail, Outlook and every mainstream MTA run the same opening checks when a connection arrives: does a PTR exist for the sending IP; is it forward-confirmed; does it plausibly match the name the server announced in HELO/EHLO. A missing or generic record is one of the oldest spam signals in the book — RFC 1912 has recommended PTR-to-HELO consistency since 1996, and Google's sender guidelines state the requirement plainly for anyone sending at volume. Mail from an address with no rDNS does not always bounce, but it starts every conversation with a strike against it.
The honest framing is necessary, never sufficient. Correct rDNS clears the identity check; the message itself still needs SPF, DKIM and DMARC alignment, a reasonable sending history and content that scores well, and the underlying IP needs a clean reputation independent of its name. Reverse DNS on a burned address produces mail that is properly introduced and still junked — hygiene, not repair.
The checks also run in a strict order at handshake time, and the PTR verdict lands first: a connection can be refused on the strength of a missing record before the message itself is parsed. Anyone running mail on a Monero-paid VPS should treat the record as day-one setup rather than a later fix, because the first weeks of a new address are exactly when filters weigh its introductions most heavily.
Beyond mail: minor benefits
Outside mail, the wins are small but cumulative. Logs become readable when tools resolve addresses to names, which shortens incident triage. Some anti-bot and abuse-heuristic systems — IRC networks, game servers, registration forms — treat a forward-confirmed record as a mild trust signal, because throwaway infrastructure rarely bothers. Geolocation and network-attribution lookups also sanity-check against PTR names, so a sensible record reduces misclassification of where your server lives.
One honest caveat points the other way: a PTR is public, readable by anyone who reverses your address. The label tells the world which domain the IP associates with, so pick a neutral hostname when the domain name itself is not something you want published on the address. A generic name like srv-203-0-113-10.example.net carries the technical benefits while exposing nothing, which is why our own opsec guidance keeps PTR records deliberately bland. See the limits of no-KYC anonymity for the fuller picture, because a PTR is one more published correlator between an identity and an address — the record is readable by design, so the label you publish should be chosen, not defaulted.
Setting custom rDNS on a VPS
On our panel the PTR record is editable per address, for the IPv4 and for addresses inside the /64 IPv6 every plan carries. The sequence: choose a hostname you control, create the matching forward A or AAAA record at your DNS host, then set the PTR on the hosting side to that same name and give propagation minutes to a few hours. Verify from the server with dig -x 203.0.113.10, host or nslookup, and confirm the forward direction resolves back to the address.
Then close the loop on the mail side: set the MTA's HELO/EHLO name to the hostname the PTR carries, since filters compare the two. On dedicated units the picture extends — with your own ranges on a dedicated server, we can delegate the reverse zone to your nameservers so you manage PTR records in bulk yourself. On a VPS the panel edit is the whole job, and there is no fee attached to it.
On the mail stack itself, the name has to agree in three places. In Postfix it lives in myhostname; in Exim, in PRIMARY_HOST_NAME; and the certificate the MTA presents should carry the same name, so TLS reporting agrees with the greeting. Five minutes of alignment at setup prevents the mismatched-HELO rejections that otherwise surface weeks later, embedded in delivery logs nobody is reading yet.
Who controls the PTR record for my IP address?
The holder of the address block, which for a VPS is the hosting provider rather than your domain registrar. You cannot set the record at your DNS host; on our panel it is editable per address instead, for both IPv4 and IPv6.
Do I need reverse DNS if I run no mail server?
Not strictly, and most idle addresses work fine without one. It still improves log readability, helps a few anti-bot heuristics and costs nothing to maintain, so setting a neutral record is cheap insurance even for non-mail workloads.
What hostname should a PTR record point to?
A hostname you control that resolves forward to the same IP, typically a subdomain such as mail.example.com. Keep the label neutral when the domain itself should not be visible to anyone who reverses your address, since PTR records are publicly readable.
How fast do PTR changes take effect?
The record itself propagates within minutes to a few hours, depending on TTLs and receiver caching. Mail reputation recovery after a fix takes longer, because filters score behaviour over days and weeks rather than trusting a single lookup.
Does reverse DNS affect SEO or website performance?
No for ranking and essentially none for speed. Search engines rank domains rather than PTR records, and page delivery does not depend on reverse lookups. The effects live in mail delivery, log legibility and third-party trust heuristics instead.
Ready to launch?
Build the box — VPS or bare metal — create the password, pay the invoice that follows.