# Set rDNS / PTR on a crypto VPS | FYRHost

> Send the IP, the matching FQDN and the invoice code; align HELO, SPF and DKIM; warm the address. Port 25 open, no KYC, from $3/mo annual-eff. No ID at signup.

Source: https://fyrhost.com/guides/admin-tips-rdns-ptr/

[Home](https://fyrhost.com/) / [Guides](https://fyrhost.com/guides/) / Set rDNS / PTR on a crypto VPS Admin tips

# Admin tip: set rDNS / PTR on a crypto VPS — the ticket, the alignment, the warm-up

![FYRHost panel abstract: ticket card linked to a rack](https://fyrhost.com/img/theme-support.png) Send the IP, the matching FQDN and the invoice code; align HELO, SPF and DKIM; warm the address. Port 25 open, no KYC, from $3/mo annual-eff.

Published 2026-08-30 · Updated 2026-10-09 · FYRHost Editorial · 14 min read

**Short answer** Send the IP, the matching FQDN and the invoice code; align HELO, SPF and DKIM; warm the address. Port 25 open, no KYC, from $3/mo annual-eff.

FYRHost: VPS from $3/mo and dedicated from $30.80/mo annual. The map spans forty locations — Reykjavik (Iceland) and Zurich (Switzerland) among them, plus Singapore, Dubai, Cape Town and fourteen others. Signup is email plus a 12-character password, or token-only. No KYC. Checkout is crypto-only across BTC, XMR, ETH, BNB, SOL, LTC, TRX, XRP, DOGE, DASH, ADA, GRAM (TON), and USDT (TRC-20/ERC-20/BEP-20/SPL). No payload or guest traffic logs; connection metadata ≤24h. DDoS included. One SKN company, one crypto checkout. Deploy at https://fyrhost.com/deploy/.

## Why PTR shows up in the first ticket

Nothing is broken when the first mail ticket of your new VPS arrives — that is the counter-intuitive part. Receiving mail servers score your address before they read a word of your message, and a generic allocator name as the pointer record, like `203-0-113-10.ipv4.pool.example`, is the oldest spam signature in the book. The [guidance dates back to RFC 1912](https://datatracker.ietf.org/doc/html/rfc1912): every internet-reachable address should have a reverse entry that matches the name the host presents.

The mechanism is cheap for receivers and expensive for you. A receiver costs one lookup to fetch the `PTR` for your IP and one more to confirm the name resolves back — the forward-confirm-reverse pair. Mismatch or absence is a cheap signal of a throwaway sender, so it gets weighted early in connection decisions. Your message content, which cost you hours of care, never gets read if the plumbing fails first.

Port `25` is open by policy on every plan here, so the network path is not your obstacle — the missing record is. That is why the request arrives as a support ticket rather than a panel toggle: reverse zones belong to the network operator, and the pointer for a delegated address is set by the desk, not by the customer. The split is standard across the industry, not a limitation of this platform.

The typical mistake is blaming the MTA configuration first and spending an afternoon in `main.cf` while the real gap sits upstream of the mailer entirely. Check the pointer before you touch any config file — one `dig` call settles it in ten seconds.

What exactly to put in that ticket is the whole procedure, and it is shorter than most people expect.

VPS from $3* (fund $50+), storage 1–5 TB NVMe from $24/mo annual-eff, dedicated with IPMI from $30.80/mo. Crypto invoice, no KYC.

[Launch now](https://fyrhost.com/deploy/?kind=vps&plan=business/)

## What the desk needs from you

Three strings close your ticket in one pass: the IPv4 to be pointed, the FQDN that already resolves to it, and the invoice code if the panel session is fresh. The IPv6 goes into the same ticket the moment its `AAAA` record is published — receivers check both families, and an unpaired AAAA is its own deliverability penalty you do not want to inherit.

The FQDN must already exist because the property being established is bidirectional: `mail.example.org` resolves to `203.0.113.10`, and the same address must resolve back to the same name. Either direction alone tests nothing; together they are what receivers check. Set your A and AAAA records at your DNS provider first, confirm with `dig +short A mail.example.org`, and only then ticket the reverse half — a ticket with a name that resolves nowhere gets bounced back for clarification, costing a round trip.

Verify your own side from the box with commands that read exactly what the internet reads: `dig -x 203.0.113.10 +short` for the pointer, `dig +short AAAA mail.example.org` for the v6 half, `ip -br addr` to list what addresses the machine actually holds. A generic [ICANN lookup](https://lookup.icann.org/en/lookup?name=example.org) does the same confirmation in a browser if you are away from a terminal. Reverse-zone mechanics themselves live in [RFC 1035](https://datatracker.ietf.org/doc/html/rfc1035), but the desk abstracts all of it into one edit for you.

The failure mode here is inversion: ticketing the pointer before the forward record exists. The desk can technically set it, but you would be creating a mismatch worse than the missing record you started with — and your first real mail test would fail confusingly.

One record pair down, four names still have to tell the same story — that agreement is the next layer you owe your receivers.

## The four names that must agree

The pointer is one of four strings a receiver cross-checks, and your score comes from the agreement: reverse DNS, the SMTP `HELO/EHLO` name, the sending domain’s SPF record and the DKIM selector’s signature. The SMTP greeting itself is specified in [RFC 5321](https://datatracker.ietf.org/doc/html/rfc5321), and receivers treat a HELO that disagrees with the PTR as a mismatch regardless of which record is technically correct.

Set the hostname on the box to the same FQDN before you start the MTA: `hostnamectl set-hostname mail.example.org` persists it on systemd distributions, and the file format behind it is described in [hostname(5)](https://man7.org/linux/man-pages/man5/hostname.5.html) with the runtime tool in [hostname(1)](https://man7.org/linux/man-pages/man1/hostname.1.html). SPF then authorizes your IP to send for the domain — the macro and qualifier syntax lives in [RFC 7208](https://datatracker.ietf.org/doc/html/rfc7208) — and DKIM signs each message under a selector your DNS publishes per [RFC 6376](https://datatracker.ietf.org/doc/html/rfc6376). A `_dmarc` record per [RFC 7489](https://datatracker.ietf.org/doc/html/rfc7489) tells receivers what to do when any of the above disagree, and its reporting turns silent failures into visible ones for you.

The order matters less than the completeness. A perfect PTR with a missing SPF fails alignment checks the same as a perfect SPF with a generic pointer; receivers score your chain, not your strongest link. Do all four in one sitting, in one change window, and re-test the whole chain afterward rather than one record at a time.

The classic mistake is renaming later without replaying the whole chain: hostname moved to `mx2.example.org`, pointer re-ticketed, SPF and DKIM forgotten — deliverability drops and the cause looks like reputation damage when it is misalignment you introduced.

Before you touch the MTA at all, verify what the delegation actually serves the world — from outside, with the tools receivers use on you.

## Verify the delegation yourself

Trust the lookup, not the ticket confirmation. From any machine outside your own network, run `dig -x 203.0.113.10 +short` and read the returned name; then run `dig +short A` on that name and confirm your address comes back. That two-step, repeated after any change, is the entire verification — everything else is someone’s dashboard telling you what it believes.

Understand what you are querying, because the reverse tree is delegated separately from the forward tree: your IP appears under `10.113.0.203.in-addr.arpa` for IPv4, and the network operator owns that branch’s zone. The resolver chain that answers your query is configured on the box in `/etc/resolv.conf`, documented in [resolv.conf(5)](https://man7.org/linux/man-pages/man5/resolv.conf.5.html), and caching at every hop means a fresh edit surfaces at different times for different observers — the record’s own TTL governs the window, so re-check from a different resolver rather than hammering the same one.

IPv6 delegates through `ip6.arpa` the same way, with each nibble of your address in the label chain — long names, same idea, and the desk handles the formatting; your part is still just publishing the matching `AAAA`. For IPv4 interfaces at boot, distributions drive the address config from files described in [hostname(5)](https://man7.org/linux/man-pages/man5/hostname.5.html) on systemd systems or [hostname.if(5)](https://man.openbsd.org/hostname.if) on OpenBSD, so the address your pointer targets is stable across reboots by configuration, not by luck.

The mistake to avoid is verification by self-lookup only: querying the resolver on your own box reads its cache and tells you nothing about what Gmail’s or Outlook’s resolvers see. External check, both families, both directions — four lookups, one minute of your time.

With the plumbing true, the remaining variable is time: your fresh address has no reputation anywhere, and that physics has no shortcut.

## Warm-up and the physics of a fresh IP

Your newly pointed address has no reputation anywhere — not good, not bad, a blank — and no provider can sell you a shortcut around that, because reputation is stored at the receiving networks, not at the host. The ramp is earned in weeks, not days, and a vendor who promises otherwise is describing an address other than the freshly pointed one.

The mechanics reward patience with numbers you can plan around: start at a volume your engagement can absorb — tens of messages a day, not thousands — toward recipients who actually open your mail. Hold hard bounces under `3%`, prune unengaged addresses aggressively, and grow volume roughly `×2` every few days rather than tenfold overnight. Receivers model exactly these curves; a spike from a young address is the second-oldest spam signature after the generic pointer, and your domain pays for it.

Domain and IP are scored separately, and the split cuts both ways for you. A domain with years of clean history carries goodwill onto a new address, which is why rebranding an established domain onto fresh infrastructure usually hurts less than you would expect. A fresh domain on a fresh address has zero of everything, which is why combining both new at once is the slowest possible start — stage them when your schedule allows.

The failure mode is impatience at week one: importing your full list the day the pointer lands, seeing the `temp-fail` wave, and concluding the platform is the problem. The address was behaving exactly as physics predicts; the schedule was the bug, and you own it.

If one address must carry too many jobs at once, the fix is division of labor — more addresses, each with one story to tell your receivers.

## When one address is not enough

Splitting roles across addresses keeps one job’s reputation from taxing another’s: your web traffic on the primary IP, mail egress on its own address with its own pointer, bulk or notification sending on a third if volume justifies it. A marketing blast that lands in spam folders then drags only the mail address, and your web certificate and API calls keep the clean primary.

Extra IPv4s are a `$3.50`/month add-on here, each with its own settable pointer — order the extra address before dedicated metal, because that is the cheap fix by an order of magnitude. Each address gets its own ticket, its own FQDN, its own warm-up curve; point one at your MTA, leave the web address generic-or-branded as you like, and the stories never contaminate. The same logic scales up: at list, a Ranger at `$12.50` (`$10.00` annual-eff) plus two extra addresses still prices far under any metal tier for a mail-centric stack of yours.

Dedicated tiers carry the same PTR workflow — from Shield at `$38.50` list (`$30.80` annual-eff) with IPMI on every tier, up the [dedicated line](https://fyrhost.com/dedicated/) — and the pointer for each of the metal’s addresses is set by the same desk request as any VPS. Bulk archives and log stores that grow alongside your mail belong on the storage line, not on the mail box’s system disk; the sizing math is in the [mail server guide](https://fyrhost.com/guides/self-hosted-mail-server-vps/).

The mistake in the other direction is address sprawl: every address needs alignment — PTR, HELO, SPF, DKIM — and its own warm-up, so your five half-configured addresses deliver worse than two complete ones. Add an address when a role genuinely needs isolation, not speculatively.

What a mail stack on this platform looks like end to end — and what the platform itself guarantees you — is the remaining piece.

## A mail stack this platform runs well

The platform guarantees the parts beneath your mailer: port `25` open by policy on every plan, no payload or guest traffic logs, connection metadata kept at most `24` hours, and the KVM-on-ECC foundation under every tier. The mailer itself is yours — any MTA runs, from Postfix to [OpenSMTPD](https://man.openbsd.org/smtpd), whose daemon page is the tersest complete reference in the genre and rewards an afternoon of your reading.

Size for the relay’s real job: queue plus spam filtering plus logs. A low-volume personal or small-business relay sits comfortably on a Sentry at $7.50 list ($6.00 annual-eff) with `2 vCPU` and `4 GB` — take Sentry for that case and add the preferred filtering on top. Busier domains with webmail, multiple domains and greylisting want Warden-class memory at 16 GB; storage growth for your archives goes to the storage line, not the system disk. The support interaction model itself — tickets, response windows, what the desk can and cannot touch — is described in the [support ticket guide](https://fyrhost.com/guides/how-to-open-support-ticket/).

Abuse hygiene is part of your stack, not an optional extra: publish working `postmaster@` and `abuse@` addresses per [RFC 2142](https://datatracker.ietf.org/doc/html/rfc2142), because receivers test them when your sending patterns look spiky. Lock the box down the same afternoon — key-only SSH per the [hardening checklist](https://fyrhost.com/guides/vps-security-hardening-checklist/) — since a compromised mail server is the fastest known way to convert your clean address into a blocklist entry.

The platform-side mistake to avoid is assuming the desk warms, sends or tunes anything for you: the pointer is the last thing the desk touches; everything from `HELO` onward is operator work, which is exactly what your root access is for.

Most of this page’s failure stories trace to a handful of recognizable slips — worth collecting in one place before you order.

## Where PTR requests go wrong

Four slips account for most of the back-and-forth you would otherwise live through. First, the inverted ticket: pointer requested before the forward `A`/`AAAA` record exists, which creates a forward-confirm-reverse failure worse than the original gap. Second, the forgotten family: IPv4 pointed, IPv6 left generic, and your domain publishes an `AAAA` that receivers penalize on sight. Third, the stale session: a ticket opened from a new panel session without the invoice code, which the desk must then verify manually before touching anything of yours.

Fourth, and most expensive for you: the partial rename. Hostname moves to `mx2.example.org`, the pointer is re-ticketed, but SPF still authorizes only the old topology and DKIM still signs under the old selector — alignment drops, temp-fails follow, and the symptom masquerades as reputation damage when it is a four-record disagreement. Replaying the whole chain after any rename costs you ten minutes; diagnosing the partial version from the outside costs an afternoon.

Timing expectations belong here too, because they generate most unjustified complaints: the desk edit itself is quick, but resolvers across the internet hold the previous answer until the record’s TTL expires — different receivers see the new value at different times, and no support team can purge a cache it does not operate. Verify from multiple external resolvers rather than re-ticketing because one lookup looked stale to you.

The meta-mistake is treating the pointer as a one-time chore. It is part of the DNS identity of your box — alive as long as the address is — and it belongs in the same change discipline as certificates and MX records: renamed together, tested together, documented together.

All of it compresses into one running order, from your order form to a warmed address.

## The PTR setup, in the order to run it

Run the whole sequence in one sitting where the schedule allows. One: size and order the box for the relay’s real job — a Sentry-class slice for a modest relay, more memory when filtering and webmail join — and note the IPv4 and any IPv6 from your panel. Two: set the hostname to the mail FQDN with `hostnamectl set-hostname` so HELO has a stable value, and publish the matching A and AAAA records at your DNS provider; confirm both with `dig +short` before anything else, because the desk ticket that follows depends on them resolving.

Three: open the ticket with the IP, the FQDN, and the invoice code if the panel session is fresh — both address families in one ticket, never split, since a second ticket doubles the verification work on both sides. Four: after the desk confirms, verify from outside your box: `dig -x` on each address, forward lookups on each returned name, both families, and repeat the four lookups from a second resolver to clear the caching question before concluding anything is wrong.

Five: complete the alignment chain while propagation settles — SPF authorizing the address, DKIM keys published under their selector, a `_dmarc` policy with reporting so disagreements become visible instead of silent — and send your test mail to the major receivers that publish feedback loops, so rejections come back with reasons you can act on. Six: warm in the shape receivers expect — low volume to engaged readers, bounces under a few percent, growth every few days rather than overnight — and add an extra IPv4 the day a second role genuinely needs its own reputation instead of pushing a shared one.

The sequence ends with your address boring: pointed, aligned, warmed, documented. That is the finished state — not a shortcut, just the shortest honest path, and every step of it is one you can re-run from scratch on any future box in under an hour.

Do I set the PTR myself in the panel? No. Reverse zones belong to the network operator, so the pointer is set by the desk from a ticket. Your part is publishing the matching forward A/AAAA record first and including the IP, the FQDN and the invoice code in the request.

How fast does the PTR change land? The desk edit is quick, but resolvers worldwide hold the previous answer until the record's TTL expires, so different receivers see the new value at different times. Verify from two external resolvers rather than re-ticketing because one lookup looked stale.

Does a web server need a PTR record? Rarely — browsers and search crawlers do not score reverse DNS. Mail receivers, some FTP mirrors and a handful of API gateways do check it, so set it once anyway: it costs one ticket and removes a variable from every future debug session.

Can the PTR change again later? Yes — re-ticket the IP with the new FQDN whenever the hostname moves. Update HELO, SPF and DKIM in the same change window, because receivers verify the agreement between the records, not any single string in isolation.

Does rDNS alone fix deliverability? No — it removes one known penalty. Content quality, volume ramp, list hygiene and the authenticated trio SPF, DKIM and DMARC carry the rest, and a perfectly pointed address stays clean only as long as the mail it sends stays wanted.

## Primary sources

- [RFC 1912: Common DNS Operational Errors](https://datatracker.ietf.org/doc/html/rfc1912)
- [RFC 7489: DMARC](https://datatracker.ietf.org/doc/html/rfc7489)
- [ICANN Lookup](https://lookup.icann.org/en)

## Related guides

- [Minimum-data no-KYC checkout](https://fyrhost.com/guides/anonymous-vps-crypto-no-kyc/)
- [Buy a VPS with crypto](https://fyrhost.com/buy-vps-with-crypto/)
- [No-KYC VPS: requirements and limits](https://fyrhost.com/no-kyc-vps/)
- [Pay with Monero](https://fyrhost.com/monero-vps/)
- [Offshore VPS](https://fyrhost.com/offshore-vps/)
- [VPS vs dedicated bare-metal](https://fyrhost.com/guides/vps-vs-dedicated/)
- [Best no-KYC VPS 2026](https://fyrhost.com/best-no-kyc-vps-2026/)
- [FAQ: crypto VPS](https://fyrhost.com/guides/faq-crypto-vps/)

## More ways to pay

[Pay with Bitcoin](https://fyrhost.com/bitcoin-vps/) · [Pay with Monero](https://fyrhost.com/monero-vps/) · [Pay with USDT (TRC-20/ERC-20/SPL)](https://fyrhost.com/usdt-vps/) · [Pay with XRP](https://fyrhost.com/xrp-vps/) · [Pay with TRX](https://fyrhost.com/tron-vps/) · [Pay with Dogecoin](https://fyrhost.com/dogecoin-vps/) · [Pick the jurisdiction first](https://fyrhost.com/jurisdiction/).

## Checkout facts

- **Price** VPS from $3/mo. Dedicated from $30.80/mo.
- **Identity** No KYC. Token-only (no email) or email plus a 12-character password. No passport, phone, or card.
- **Payment** Nineteen ways to settle, none of them a card: XMR and BTC lead, ETH, SOL, LTC, BNB and TRX follow, then XRP, DOGE, DASH and ADA, GRAM (TON) for Telegram-adjacent rails, and USDT on seven networks — TRC-20, ERC-20, BEP-20, SPL, Polygon, Arbitrum, Optimism. Live-rate invoice.
- **Logs** No payload / no guest traffic logs. Billing and panel actions retained. Connection metadata ≤24h.
- **Platform** KVM on ECC and local NVMe. DDoS filtering included. Facilities in 40 cities across four continents — the locations table lists each one's tier, uplink and governing law. Need Iceland or Switzerland plus no KYC? Those two carry a published premium (+20% / +35%); every other flag stays at base list. Pay BTC, USDT, XMR, BNB, XRP, GRAM (TON) or 10 more. Open deploy to pick a plan.

## Ready to launch?

Build the box — VPS, storage or bare metal — create the password, pay the invoice that follows.

[Launch now](https://fyrhost.com/deploy/?kind=vps&plan=business/)[Dedicated](https://fyrhost.com/dedicated/)