My VPS provider does not let me set PTR records. Can you still help?

Sometimes yes, sometimes no. Most major providers (Hetzner, OVH, DigitalOcean, Vultr, Linode) allow custom PTR via control panel or support ticket. Some shared hosting and cheap VPS providers do not allow it at all. We check your provider before accepting the order and refund if blocked.

PER-IP · 24 HOURS

Reverse DNS, configured per IP and FCrDNS-verified.
Without it, every receiver flags you on connection.

Custom rDNS is the PTR record that maps your sending IP back to a hostname under your domain. Receivers query it during the SMTP handshake before they look at SPF, DKIM, or DMARC. A missing PTR triggers suspicion. A generic-provider PTR (like 185-220-101-23.hetzner.cloud) triggers more suspicion. Aligned with your HELO and your forward A record? Receivers see a sender who knows what they're doing.

We set it correctly, verify the FCrDNS loop closes both directions, and confirm the HELO declaration matches under SMTP-level testing. One IP, €19, validated within 24 hours. Per-IP pricing at scale, with discounts past 8 IPs.

Order on Telegram → Check provider compatibility

price €19 / IP

delivery 24 hours

verification FCrDNS + HELO + SMTP

bulk discount past 8 IPs

why receivers care about rDNS

It's the first thing checked. Before SPF, before DKIM, before content.

The SMTP handshake goes like this. Your server connects to the receiver's MX. The receiver does a reverse DNS lookup on the connecting IP, what hostname does this IP claim to be? Then your MTA sends EHLO with a hostname declaration, what hostname does your sender claim to be? Then the receiver does a forward lookup on the EHLO hostname, comparing it to the connecting IP. All of this happens before MAIL FROM, before DATA, before SPF or DKIM are even considered. That's how early in the conversation rDNS is.

When the PTR record is missing, the receiver sees an IP claiming to be a mail server but unable to identify itself. That signal alone drops most enterprise filters and consumer receivers into spam. Some receivers reject the connection outright, Microsoft 365 has rejected mail from IPs without PTR records for years; Gmail considers it a strong negative signal; Yahoo treats it as "untrustworthy infrastructure" in their reputation scoring.

When the PTR record exists but points to the provider's generic hostname (the 185-220-101-23.hetzner.cloud pattern, or the ec2-54-something.compute.amazonaws.com equivalent), the receiver sees an IP that hasn't been configured for sending. Generic provider hostnames signal "this is a server doing something else that happens to send mail" rather than "this is a dedicated mail server." Reputation weighting differs accordingly. Most receivers tolerate generic PTR for low-volume; throttling escalates fast as volume increases.

When the PTR record exists, points to a hostname under your sending domain, that hostname has a forward A record back to the same IP, and your EHLO declaration matches: receivers see a properly identified sending infrastructure. FCrDNS-verified. The connection gets the same treatment as any well-configured corporate mail server. Reputation can build. SPF and DKIM matter at this point; before this, they don't get to vote.

what FCrDNS actually verifies

The loop that has to close in both directions.

Click any step to see what happens at that point and what fails when it doesn't match. All four steps must pass for a sender to be considered FCrDNS-verified.

→ → →

step 1

Connection arrives at receiver MX

Your MTA opens a TCP connection to the receiver's MX server on port 25. The receiver sees the connecting IP address. This is the only authentication signal available at this point, the receiver hasn't heard anything from your sender yet, hasn't seen any headers, hasn't read any content.

The IP address is what gets used to drive the next three steps. Everything we configure in this service is about ensuring those next three steps return clean answers.

your provider, our compatibility

Where custom rDNS works, where it doesn't.

Filter by tier to see which providers allow custom PTR records and how. We verify your provider before accepting the order. If your provider blocks rDNS, we tell you upfront and refund.

Provider	Method	Notes	Status
Hetzner	Cloud Console (one-click) or robot.your-server.de	Self-service via web UI, instant. Both Hetzner Cloud and Hetzner Robot dedicated.	self-service
OVH / SoYouStart / Kimsufi	Manager web UI, IP Reverse panel	Self-service, takes effect within 4 hours. All OVH brands supported.	self-service
DigitalOcean	Auto-set from droplet hostname	Set the droplet hostname to your desired rDNS; PTR follows automatically.	self-service
Vultr	Control panel → Settings → IPv4	Self-service web UI, instant.	self-service
Linode / Akamai	Cloud Manager → Networking → IPs	Self-service, requires forward A record to exist first.	self-service
AWS EC2	Support ticket via Console	Requires elastic IP, AWS account in good standing, request form. Takes 24-72h.	ticket
Google Cloud	Support ticket	Requires premium support tier; self-service unavailable for most accounts.	ticket
Azure	Support ticket + sending limits removal	Default-blocked for outbound 25; needs unblock request before rDNS makes sense.	ticket
Contabo	Support ticket	Allowed but requires ticket; takes 24-48h. Sometimes refused for high-volume sending.	ticket
Hostinger / Namecheap VPS	Support ticket, often refused	Allowed in theory; in practice frequently denied for VPS plans. Verify before ordering.	often refused
GoDaddy / Bluehost / shared	Not supported	Shared hosting and most cheap VPS plans do not allow custom rDNS at all. Migrate to a dedicated/VPS provider.	blocked
Cloudflare (proxied)	N/A	Cloudflare proxies HTTP, not SMTP. rDNS is set on your origin server provider, not on Cloudflare.	N/A

Provider list updated quarterly. If your provider isn't listed, we check it during intake. About 8% of orders we receive turn out to be on providers that block rDNS; we refund and recommend a migration target if you want to proceed with sending. The €19 per IP price is contingent on your provider allowing the change.

expected deliverability impact

What adding custom rDNS will get you.

Set your current authentication state. The calculator estimates inbox-placement impact based on what we observe across audits and monitoring data, where we can isolate the rDNS variable.

Number of sending IPs 1 IP

Each sending IP needs its own PTR record. Multi-IP setups need consistent rDNS across the pool.

Current rDNS state

Most senders fall into "generic provider hostname" without realising it. That's the default state on most VPS.

Other authentication state

rDNS impact is multiplicative with other authentication. The full stack benefits more from rDNS than a partial stack.

current state

Generic provider hostname

Estimated inbox placement 68-78%

Receiver penalty Moderate

Generic provider hostname signals "this server isn't dedicated to mail." Most receivers tolerate at low volume; throttling escalates as you scale.

with custom rDNS

Custom rDNS, FCrDNS verified

Estimated inbox placement 85-93%

Receiver penalty None

Properly identified sending infrastructure. SPF, DKIM, and DMARC start to matter; they don't carry weight without the rDNS prerequisite.

expected gain

Inbox-placement uplift

Median improvement +15-20%

Total cost €19

For a single IP. Bulk pricing past 8 IPs (€15/IP), past 16 (€12/IP), past 32 (custom quote).

Estimates calibrated against 200+ audits where rDNS was the primary remediation variable. The largest gains come from "missing PTR" or "generic provider hostname" baselines. If you already have custom rDNS and FCrDNS verified, the calculator will tell you so and recommend skipping this service. About 12% of senders who think they need rDNS already have it set correctly.

honest fit assessment

Who orders this, and who shouldn't.

good fit

New sending IP on a major VPS provider (Hetzner, OVH, DigitalOcean, Vultr, Linode) and you don't want to fight with the control panel for an hour.
AWS, Google Cloud, or Azure deployment where rDNS requires a support ticket. We've filed thousands; the ticket gets answered faster when written correctly.
Multi-IP pool needing consistent rDNS across 4-32 IPs. Per-IP pricing scales clean.
Audit surfaced rDNS as a gap and you want it fixed without a larger engagement. Standalone scope, single fee.
Migrated infrastructure where the new IPs need rDNS aligned with your sending domain before first send.
Compliance requirement for documented infrastructure setup. The deliverable doubles as audit evidence.

poor fit

Provider doesn't support custom rDNS at all. Shared hosting, GoDaddy, Bluehost, most cheap VPS plans. We can't override the provider's policy. Migration is the only path forward.
You ordered our PowerMTA + MailWizz Setup (€299). Custom rDNS is included in that scope. You're paying for it twice if you order separately.
You want everything managed forever. This is one-time configuration. After handover, it stays configured indefinitely (rDNS doesn't drift). Ongoing management is for DKIM rotation, monitoring, and similar.
Single low-volume sender (under 1,000 monthly emails) where the deliverability difference is hard to measure. Generic PTR rarely causes problems at that scale.
You want guaranteed inbox placement as a result. rDNS is necessary but not sufficient. Reputation, content, and list quality matter alongside.

scope of work

What's in the €19.

Provider compatibility check

Verify your provider allows custom rDNS before committing to the work. About 8% of orders involve providers that block PTR customisation. We tell you upfront and refund if blocked.

If your provider supports it via self-service control panel (Hetzner, OVH, DigitalOcean, Vultr, Linode), we use that path. If your provider requires a support ticket (AWS, GCP, Azure, Contabo), we file the ticket on your behalf with the technical justification they need to approve quickly.

Hostname design

Each sending IP gets a hostname under your sending domain. Conventions matter: mta01.<yourdomain>, send01.<yourdomain>, or numbered subdomains for multi-IP pools. We avoid generic patterns that look like shared hosting and avoid descriptive patterns that leak architectural details (so not powermta-server-01 but rather mta01).

For reseller / agency setups with per-customer isolation, hostname convention can be brand-specific. We discuss naming at intake.

Forward A record publication

For the FCrDNS loop to close, the hostname must resolve to the IP via a forward A record. We publish this at your DNS provider (assuming you have access; if not, we can guide you). The A record TTL is set to 3600 seconds, long enough for caching but short enough for fast updates if you ever change IPs.

PTR record configuration

The PTR record lives at the IP's reverse zone, owned by the IP block holder (your provider). We submit the change via the provider's appropriate channel, control panel for self-service providers, support ticket for ticket-based ones. Most changes propagate within 4 hours; AWS sometimes takes 24-72.

HELO/EHLO alignment

Your MTA needs to declare the correct hostname during the SMTP handshake. PowerMTA configures this via VMTA-level helo-name. Postfix uses smtp_helo_name. MailWizz inherits from the underlying MTA. We update the relevant configuration if we have access; if not, we provide the exact change for you or your engineer to apply.

End-to-end FCrDNS verification

After all three records are in place, we run end-to-end verification. Sample SMTP send to a verifying receiver. Header inspection of the receiver-side response. dig forward and reverse queries from multiple resolvers to confirm propagation. Output: documented proof that the FCrDNS loop closes for each IP, with timestamps.

Documentation handover

For each IP configured: hostname, forward A record location, PTR record location, EHLO configuration line, and verification timestamps. Useful for compliance audits, future migrations, or simply confirming nothing drifted six months later.

Bulk pricing

€19 per IP for 1-7 IPs. €15 per IP for 8-15. €12 per IP for 16-31. Past 32 IPs, custom quote (often less per IP because multi-IP pools share intake and verification work). We bill once at intake regardless of count; no surprise additions.

how the day unfolds

From order to verified rDNS.

Hour 0

Compatibility check

Telegram intake. Confirm your provider supports rDNS, the IPs in scope, the hostname convention. We verify provider compatibility within 30 minutes; refund if blocked.

Hours 0-4

Records submitted

Forward A records published at your DNS. PTR submitted at the provider, self-service for major providers, ticket for AWS/GCP/Azure/Contabo. EHLO configuration prepared.

Hours 4-20

Propagation + EHLO

PTR propagation completes (4 hours typical, up to 72 for ticket-based providers). EHLO/HELO declaration updated in your MTA configuration.

Hours 20-24

Verification + handover

FCrDNS verified end-to-end with sample SMTP send. dig queries from multiple resolvers confirm propagation. Documentation delivered. Telegram handover with summary of every IP configured.

questions before you order

Frequently asked.

My VPS provider doesn't let me set PTR records. Can you still help?

Sometimes yes, sometimes no. Most major providers (Hetzner, OVH, DigitalOcean, Vultr, Linode) allow custom PTR via control panel or support ticket. Some cheap VPS providers and most shared hosting do not allow it at all. We check your provider before accepting the order. If blocked, we refund and recommend migration targets.

About 8% of orders we receive turn out to be on blocked providers. The pre-check takes 15 minutes; we don't start the work until we've confirmed compatibility.

How is rDNS different from SPF or DKIM?

SPF and DKIM authenticate the message, they prove this message comes from an authorised sender. rDNS authenticates the connecting IP, it identifies what infrastructure the connection originates from. Receivers query the connecting IP's reverse DNS during the SMTP handshake before they look at SPF or DKIM. Missing rDNS triggers immediate suspicion at major receivers, often before SPF or DKIM even get evaluated.

All three layers matter. rDNS is the foundation; without it, SPF and DKIM don't get to vote.

Can I have a single PTR for multiple IPs?

No. PTR records are per-IP by definition. Each sending IP needs its own PTR pointing to a unique hostname under your domain. For multi-IP pools, we typically use numbered hostnames (mta01, mta02, mta03...) so the convention scales cleanly.

Forward A records can also be unique per IP (each hostname resolving to its own IP) so the FCrDNS loop closes independently per IP.

What happens if I change IPs later?

Both records need to update. The PTR at the new IP allocation and the forward A record at your DNS. We don't auto-monitor this; if you change IPs, you order again at €19/IP for the new addresses. For ongoing IP changes, our PowerMTA + MailWizz Setup or Recovery Pack bundles include rDNS as part of the broader scope.

Does rDNS affect IPv6?

Yes, and IPv6 PTR is more complex. IPv6 PTR lives in the ip6.arpa zone with reversed nibble notation. Most VPS providers either support IPv6 PTR via control panel (Hetzner does this cleanly) or via ticket (AWS, GCP). Cloud providers vary.

If your sending uses both IPv4 and IPv6, we configure both for the same per-IP fee. Mention IPv6 at intake; we verify the specific provider supports it.

What if my provider charges extra for custom rDNS?

Our €19 fee covers the configuration work, not your provider's charges. Most major providers don't charge for custom rDNS; it's a free feature. A handful charge a small fee per IP for the privilege. AWS bills nothing for elastic IP rDNS but the elastic IP itself is billable. Provider-side fees are passed through to you at cost.

How do I verify it's working after handover?

Standard verification commands work from any Linux/Mac terminal:

dig +short -x <your-IP> returns your hostname
dig +short A <your-hostname> returns your IP
Send test mail to a Gmail address; check headers for "Received: from <your-hostname> (<your-hostname> [<your-IP>])"

If all three pass, FCrDNS loop is closed and the configuration is correct. The handover document includes the same commands with your specific values for easy verification.

Will rDNS alone fix my deliverability?

Not alone. rDNS is necessary but not sufficient. If your deliverability is poor, you probably also have SPF/DKIM/DMARC gaps, content issues, list quality problems, or reputation issues from past sending. The Audit (€299) identifies all contributing factors. rDNS standalone is the right product when audit (or other diagnosis) has identified rDNS specifically as the gap.

How does payment work?

Standard: full payment on intake (€19 × IP count) since the work is short-cycle. Payable in any of our 11 supported cryptocurrencies. Self-hosted BTCPay, no third-party processor, no KYC. If your provider blocks rDNS, we refund the full amount within 24 hours.

also relevant

Related services and references.

Custom rDNS pricing tiers and what each covers

Custom rDNS configuration is included in dedicated IP allocations at our standard pricing tier. The standard configuration: customer specifies the hostname they want associated with each sending IP, we configure the PTR record in the reverse DNS zone for the IP range, customer publishes the corresponding A record in their domain DNS, FCrDNS validates correctly. The setup typically completes within 24-48 hours of customer request.

Premium custom rDNS at EUR 49 monthly per IP adds operational sophistication for senders with specific requirements: per-campaign rDNS rotation (different hostnames for different campaigns to support source attribution in customer analytics), geographically-aware rDNS (different hostnames presented based on sending region for operators with multi-region infrastructure), audit-grade rDNS documentation (records of every PTR change with timestamps and operator attribution for compliance evidence).

Enterprise custom rDNS at EUR 199 monthly covers ESP-style operations with many customer domains and IP allocations: multi-tenant rDNS coordination, customer-facing rDNS management interfaces, integration with customer account systems, batched rDNS operations across many IPs simultaneously. The tier amortizes well across ESP customer bases above approximately 50 customer domains.

For operators uncertain which tier fits their operation, the structural question is whether they need rDNS coordination capabilities beyond standard per-IP configuration. Most senders with single-pool operations stay at standard tier indefinitely; senders with multi-pool or multi-region operations benefit from premium; ESP operations need enterprise tier.

rDNS configuration patterns for production reliability

Production rDNS configuration patterns matter because the rDNS record is part of the senders public infrastructure that receivers evaluate. Configuration patterns that look correct but produce subtle issues are common enough to warrant explicit guidance.

Pattern 1: matching hostname conventions across the sending pool. All sending IPs should use the same hostname pattern (e.g., mail01, mail02, mail03 under the same parent domain) rather than mixed conventions. Receivers performing pattern analysis treat consistent patterns as professional infrastructure and mixed patterns as suspicious infrastructure. The configuration discipline matters across the deployment.

Pattern 2: parent domain alignment with authentication. The rDNS hostname should align with the parent domain that handles authentication. Sending IPs with PTR pointing to one domain while SPF and DKIM use a different domain produces alignment issues that receivers note in their classification. The structural fix is using a single parent domain across rDNS, authentication, and From-header content.

Pattern 3: forward record consistency. The forward A record corresponding to the PTR must point back to the same IP for FCrDNS to validate. Operators sometimes set the PTR correctly but forget the forward record, or set the forward record but to a different IP than the PTR indicates. The rDNS tester on this site catches both patterns; production deployments should verify FCrDNS rather than just PTR.

Pattern 4: TTL alignment for rDNS records. The PTR record TTL and the corresponding A record TTL should match. Mismatched TTLs produce situations where one record updates but the other persists in caches, breaking FCrDNS during the propagation window. Standard production pattern is 3600 seconds (one hour) for both during normal operations, with shorter TTL during planned changes to accelerate propagation.

Custom rDNS for multi-jurisdictional sending operations

Operators running sending infrastructure across multiple jurisdictions face rDNS questions that single-jurisdiction operations do not. The reverse DNS zones live in the jurisdictions where the IPs are allocated; coordinating rDNS across jurisdictions requires understanding the per-jurisdiction operational model.

Our infrastructure operates IP allocations in seven jurisdictions; each jurisdiction has its own reverse DNS zone delegated to our nameservers for the IPs we control. Custom rDNS configuration works uniformly across all jurisdictions through our management interface; customers see consistent configuration capabilities regardless of which jurisdiction their IPs are allocated in.

Per-jurisdiction rDNS coordination matters for senders whose audience composition varies by region. Sending IPs in Bulgaria typically perform better for EU recipients; sending IPs in Panama typically perform better for Latin American recipients; sending IPs in Singapore typically perform better for Asian recipients. Custom rDNS supports the geographic alignment by allowing different hostname conventions per region (e.g., mail-eu-01, mail-latam-01, mail-asia-01 with consistent suffix patterns).

For senders with specific compliance requirements affecting rDNS data residency, our infrastructure supports jurisdiction-locked configuration where the rDNS records for IPs in a specific jurisdiction are managed only by infrastructure operating within that jurisdiction. The configuration is operationally transparent to receivers but produces the data-residency properties that some compliance frameworks require.

Custom rDNS deployment timeline and verification

Custom rDNS deployment typically completes within 24-48 hours of customer request for standard tier. The mechanical pattern: customer specifies the desired hostnames per IP through our management interface or support ticket, our infrastructure team configures the PTR records in the reverse DNS zones, customer publishes the corresponding A records in their domain DNS, propagation completes within standard DNS TTL windows.

Verification matters because rDNS configuration mistakes are common during initial deployment. The standard verification: run the rDNS tester on this site against each sending IP after deployment, confirm both PTR resolution and FCrDNS validation pass, send test messages from each IP to verify HELO presentation matches the new rDNS hostname.

For operators with complex configurations (many IPs, multiple parent domains, specific naming conventions), the deployment can extend to 3-5 days to accommodate the additional coordination. The extended timeline does not produce additional charges; we prioritize correct configuration over fast deployment.

Ready to get rDNS configured properly?

Telegram intake takes 15 minutes. Provider compatibility check first; we refund if blocked. If approved, 24-hour delivery with end-to-end FCrDNS verification.

Order on Telegram → Submit ticket

# Median Telegram response: 12 minutes during operating hours