Admin tip: set rDNS / PTR on a crypto VPS

Mail and some APIs want a PTR that matches the HELO. Ticket the hostname. You run Postfix.

Published 2026-08-30 · Updated 2026-10-21 · BitCloudVPS Editorial

Why PTR shows up in tickets

Receiving MTAs and a few payment APIs check reverse DNS. Postfix documentation will not save you if the PTR is a generic allocator name. This is the usual first ticket after someone buys a mail VPS with crypto.

What to send

1. The IPv4 (and IPv6 if you use it).
2. The FQDN you already pointed A/AAAA at.
3. Invoice code if the panel is new.

Then harden OpenSSH manual and keep port 25 for mail you actually operate. We do not run the MTA.

Short answer: what a PTR record is and who can actually change it

A PTR record maps an IP address back to a hostname - the reverse of the A record - and it lives in special in-addr.arpa (IPv4) or ip6.arpa (IPv6) zones. Because the zone belongs to whoever holds the network block, not to you, the owner of the IP must set it. This is the one DNS record you cannot publish yourself on a typical VPS: you can add TXT, MX, and SPF on your own domain all day, but the reverse zone for 203.0.113.7 is delegated to the hosting network, so the change happens in the provider's panel or through their support.

On BitCloudVPS every VPS comes with one IPv4 address and a /64 IPv6 block, and the PTR for the IPv4 is editable from the control panel without a ticket. That matters more than it sounds: providers who route PTR changes through support add a day of latency to a five-minute job, and mail operators feel every hour of it, because receiving servers check the PTR before anything else about your sender.

The three rules that make a PTR correct: it must resolve (the hostname it points to must itself resolve back to the same IP - forward-confirmed reverse DNS); it should be stable, because mail reputation accumulates on the hostname; and it should look like a host name, not a generic label. mail.example.org passes; 203-0-113-7.clients.isp.net is what half the blacklists were built to recognize. Everything below is the practical sequence: prerequisites, the edit itself, verification, IPv6, and the failure modes.

Prerequisites before you request a PTR

A PTR edit fails for boring reasons - a hostname that does not resolve, a record still in propagation, a mail test run too early. Get the inputs together first and the rest of the sequence is one panel visit.

Decide the hostname before you touch anything. If the box will send mail, use the name your SMTP server presents in its banner - mail.example.org - because mismatch between the EHLO banner and PTR is a spam-score hit that no amount of SPF will offset. If it is a web or VPN box, any stable subdomain works. One hostname per IP, chosen once, kept for the life of the server: the receiving side builds history on that string.

Setting the PTR in the panel, step by step

1. Create the forward record first. In your DNS zone for example.org, add mail A 203.0.113.7. Do this before the PTR, because the first thing every checker does is resolve the hostname the PTR names.
2. Wait for the A record to answer. dig +short mail.example.org should return 203.0.113.7 from a public resolver. If your registrar's DNS is slow, you are about to set a PTR to a name that does not resolve yet - the classic self-inflicted failure.
3. Open the BitCloudVPS panel, select the server, and find the network or IP section. The IPv4 address is listed there with an editable reverse DNS field.
4. Enter the full hostname with the trailing dot convention in mind - mail.example.org - and save. The panel applies it to the reverse zone for the network block; this is the step other providers make you ticket.
5. Verify from outside: dig +short -x 203.0.113.7 should return mail.example.org., and dig +short mail.example.org returns the IP. Both directions, that is forward-confirmed.
6. If the server already runs a mail daemon, restart or reload it so the EHLO banner matches the new hostname, then run a single outbound test to a service that reports the checks it performed (mail-tester class tools) and read the PTR line before anything else.

Total time is about ten minutes including DNS waits. The only step people skip is the last verification from an external resolver - checking on the server itself reads the local resolver's cache and can show a stale or empty answer that the rest of the internet stopped serving an hour ago.

Verifying the record from your own machine

Verification means three lookups, and each tool shows a different layer. From any Linux or macOS machine:

dig +short -x 203.0.113.7 - queries the reverse zone directly. Expected output: mail.example.org. (note the trailing dot). Empty output means the PTR is not set or has not propagated to the resolver you are using; try @1.1.1.1 as the resolver argument to bypass local caching.

host 203.0.113.7 - the same query through BIND's friendlier frontend; useful as a second opinion because it also shows any additional PTR records. An IP should have exactly one PTR: multiple values are technically legal and universally mishandled, so if you see two, that is a bug to ticket.

nslookup 203.0.113.7 on Windows reads through the Windows resolver - the right test before blaming the server, because it shows what your own network path sees. Expected: a name = mail.example.org line under the non-authoritative answer.

Then close the loop in the forward direction: dig +short mail.example.org must return 203.0.113.7. The pair of answers together is what receiving mail servers call FCrDNS, and it is the state that actually earns reputation - a PTR whose hostname does not resolve back is treated as a generic dynamic address no matter how respectable the domain is. If either side answers with the wrong value, you have a TTL problem, not a configuration problem: wait out the old record's TTL and re-check.

Forward-confirmed reverse DNS: making the A record match

FCrDNS is the state where IP -> hostname and hostname -> IP agree. It exists because the reverse tree is the only part of DNS the address holder controls, so checking both directions is the cheapest way for a receiving server to establish that whoever set the PTR also controls the forward zone - a weak but real signal that the sender is a managed host rather than a hijacked residential line. Most anti-spam systems check it before they check anything you carefully configured, and several will not even accept a connection to evaluate your SPF when it fails.

The practical discipline: whenever either side changes, fix both sides the same hour. Moved the mail service to a new box? The new IP gets its PTR set to the same hostname, the A record is repointed, the old box's PTR is cleared or renamed so the pair does not dangle. Renamed the service? Same rule in reverse. The record that must never dangle is the one on your sending IP, because mail reputation systems key on the hostname string - a server that has sent clean mail as mail.example.org for a year carries that history with it, and every rename resets it to zero.

One subtlety on IPv4 NAT-free VPS plans like these: since you hold a dedicated IPv4 (1x IPv4 plus a /64 of IPv6 is standard on every plan from Nano up), there is no shared-IP landlord overwriting your PTR and no NAT pool breaking FCrDNS. That is precisely why cheap NAT-based offers cannot do proper reverse DNS at all - the address is shared, so the PTR can only name the provider. It is a quiet spec-line item that decides whether a small mail setup can work at all.

PTR for the IPv6 /64

Every BitCloudVPS plan includes a /64 IPv6 block - about 18 quintillion addresses - and the same PTR logic applies, in a zone under ip6.arpa. The difference is scale: with IPv4 you set one record; with a /64 you need a convention, because each address you actually use should get its own reverse entry. The standard approach is to pick hostnames per service - the mail daemon on 2001:db8::25 gets a PTR to mail.example.org, the web frontend on ::443 to www.example.org - and leave unused addresses blank, which is fine, since only addresses that send traffic need answers.

The mechanics mirror IPv4. The reverse name for 2001:db8::25 is the full 32-nibble expansion reversed under ip6.arpa - which is why nobody writes it by hand and the panel handles the encoding. Verify with dig +short -x 2001:db8::25, and confirm the forward side with an AAAA record: dig +short AAAA mail.example.org. FCrDNS applies symmetrically - the hostname must resolve back over AAAA to the same address.

Two IPv6-specific traps. First, outbound address selection: a server with a /64 may pick an arbitrary source address for outgoing mail rather than the one you gave a PTR, so bind the mail daemon explicitly to its named address. Second, some receiving systems treat IPv6 senders more strictly than IPv4 ones, so a missing IPv6 PTR costs more than a missing IPv4 one. Set both before the first send, and if you only remember one rule: the PTR should exist for every address that opens an outbound connection.

Troubleshooting PTR: symptom, cause, fix

PTR problems present as other people's rejections, so the table maps what you observe back to the record that caused it.

Order of operations is the meta-fix: forward record, reverse record, external verification, then first send. Nearly every case in this table is that sequence run in the wrong order, with the box already mailing generic while the records caught up.

What a correct PTR changes for mail and scanners

The payoff of the sequence above is concrete. For mail, a passing FCrDNS check removes the largest automatic penalty a small sender carries: receiving systems stop treating the box as a dialup line and start evaluating its actual reputation - SPF and DKIM then have a clean hostname to attach to. Deliverability guides disagree about many things, but not about this one: no reverse DNS or mismatched reverse DNS on the sending IP is a near-universal rejection or spam-folder trigger.

Outside mail, the same record quietly works for you. Scanners and threat-intel feeds label addresses by their PTR; a named host on your domain reads as operated, while a blank or generic reverse entry reads as commodity infrastructure, which attracts both abuse reports keyed to the provider and the collateral blocking that follows them. SSH banners, monitoring dashboards and log analysis all become readable when reverse lookups resolve to names you chose instead of provider defaults.

Set it once, on a host whose name matches the services it runs, and leave it alone - the value is in the stability, not the cleverness of the name. If you are standing up a mail-capable box today, the sequence fits inside an hour end to end: deploy the VPS (about 60 seconds to a root shell from $5.49/mo), create the A record, edit the PTR in the panel, verify both directions, then send your first message. The cheapest place to make the mistakes in the table above is on a monthly Nano or Starter term, before you commit anything annually.

Writing a PTR value that deliverability tools and abuse desks accept

The short answer: a PTR is only useful when it is a real hostname that resolves forward to the same IP, matches the name your mail server introduces itself with, and stays stable. Receivers do not score the record itself - they score the coherence of the whole triangle: reverse, forward, and HELO/EHLO. You can have a perfectly set PTR and still fail, because the A record or the greeting name drifted.

Work through the three legs in order. First the reverse record, set once in the panel for your IPv4 (and per address in the /64 if you send from IPv6). Use a hostname you control, on a zone you can edit - mail.example.com is the classic shape; avoid generic labels like vps-1042 because they read as unmanaged. Second, the forward record: in your DNS zone, add mail.example.com. IN A 203.0.113.10 pointing back at exactly the address the PTR covers. This pairing is called forward-confirmed reverse DNS, and it is the first thing dig -x-based checks verify. Third, configure your MTA to greet as the same name - in Postfix that is smtp_helo_name = mail.example.com in main.cf, in Exim primary_hostname.

How to verify the triangle from your own machine, in three commands: dig -x 203.0.113.10 +short must return mail.example.com.; dig +short mail.example.com must return 203.0.113.10; and nc -v 203.0.113.10 25 should show the banner greeting as mail.example.com. When all three agree, most receiver-side rDNS tests pass on that leg alone.

Troubleshooting the value itself. Symptom: the PTR resolves but mail still gets deferred. Cause: the forward record points at a different IP after a reinstall or plan change - the triangle broke silently. Fix: re-check both legs and update the stale one; this is the single most common rDNS failure in practice. Symptom: a receiver flags a generic hostname. Cause: the PTR still carries the provider's default template. Fix: change it to your own zone - the panel edit takes effect on the DNS side without touching your running instance. Symptom: lookups intermittently return the old value. Cause: DNS caching; the old TTL has to expire, so re-test from several resolvers rather than one.

Keeping rDNS correct across reinstallations, IP changes and the /64

The short answer: PTR hygiene is a recurring task, not a one-time setup, because every reinstall, IP reassignment and DNS zone edit can quietly break forward-confirmed reverse DNS. The operators who never land in spam-jail trouble are the ones who re-verify the triangle after any infrastructure change, and who treat the IPv6 /64 with the same discipline as the IPv4.

Make it a scripted check instead of a memory exercise. A five-line shell snippet does the whole audit: take the address from ip -4 addr show, run ptr=$(dig -x $ip +short), then dig +short ${ptr%.} and compare the result against the address - print OK or BROKEN. Drop the same logic for the v6 address from ip -6 addr show into the script, schedule it weekly from cron, and you will hear about drift the day it happens, not the week deliverability collapses. Keep the script and its output on a different machine than the mail node, so a reinstall of the node does not erase the baseline.

The /64 deserves its own routine. Every VPS on this network ships with one IPv4 and a /64 IPv6 block, which means you can give the mail sender its own stable v6 address and set a matching PTR for it - the panel accepts per-address reverse entries inside the block. Two rules keep it sane: pick a low, fixed address for the sender (e.g. ending in ::10) so scripts and firewall rules never chase a moving target, and never let outbound v6 mail leave from a randomly selected address in the block, because a rotating sender address means a rotating identity to receivers. If your stack does not pin the source address, bind the MTA explicitly to the chosen one.

What this routine does not fix: a bad sending reputation built by earlier content, or blocklist entries earned by a previous tenant of behavior on the same address. PTR correctness is the entry ticket, not the whole score. But it is the cheapest ticket on the board - a panel edit plus one A record - and on plans where a year of Nano runs a flat $36, there is no budget argument for skipping it.

Where the limits are (October 2026)

Keep the threat model precise. Anonymous-adjacent hosting removes the host-side identity trail: token-only signup, optional email, no KYC review, crypto invoices that record a txid rather than a name. It does not blind the host to traffic it must carry, it does not make a logged-in panel session anonymous, and it does not protect workloads that identify themselves — an admin login from your home IP defeats the whole design. Exact limits of no-KYC anonymity. OPSEC guide. Full checklist. Payment-side note: chain analysis happens on public blockchains, not at the host. Coin choice and network choice are your OPSEC knobs, and the checkout keeps 19 of them open.