Reverse DNS Setup Guide (rDNS Tutorial) for VPS & Dedicated Servers in 2026

Email deliverability issues rarely announce themselves. You may see confusing bounces, messages stuck in “deferred,” or mail that quietly lands in spam.

One fast way to lose trust with major inbox providers is a missing or incorrect PTR record (reverse DNS). This reverse DNS setup guide shows how to set rDNS on a VPS or dedicated server in 2026. It also shows how to verify it using the same checks real mail servers run.

You’ll point a PTR record from your server IP to a hostname. Then you’ll confirm that hostname resolves forward to the same IP (FCrDNS). Finally, you’ll make sure your HELO/EHLO identity matches what you publish.

When you do this right, remote systems can validate who you are. When you don’t, they treat your server like an anonymous risk.

What you’ll need before you touch rDNS

A static public IPv4 (and optionally IPv6) on your VPS or dedicated server
A fully qualified domain name (FQDN) you control, such as mail.example.com
DNS access to create or edit an A record (and AAAA if using IPv6)
Server access (root/sudo) to check hostname and MTA configuration

If you’re building an email-capable server from scratch, lock down the basics before you send mail. Use SSH keys, patch regularly, and keep firewall rules tight.

HostMyCode lays out a practical baseline here: VPS hardening tutorial for Ubuntu hosting.

Reverse DNS in one minute: PTR, forward DNS, and FCrDNS

Reverse DNS is a lookup from an IP address to a hostname. In DNS terms, that’s a PTR record. It lives in a reverse zone owned by the IP holder (usually your hosting provider).

Most mail systems also check FCrDNS (Forward-Confirmed reverse DNS):

Reverse (PTR): 203.0.113.10 → mail.example.com
Forward (A): mail.example.com → 203.0.113.10

If these don’t match, expect higher spam scores and more deferrals. You may also see outright SMTP rejections.

For outbound email, rDNS is baseline hygiene.

Step 1: Pick the right mail hostname (don’t use your root domain)

Give your server a dedicated hostname for mail identity. A common, clean pattern is:

mail.example.com for email sending/receiving
server1.example.com for general server identity (optional)

Avoid using example.com as the PTR target. Many receivers expect a host-style name, not the bare apex domain.

Keeping web and mail separated also makes DNS easier to maintain.

Step 2: Create the forward DNS record (A/AAAA)

Set forward DNS first. Then FCrDNS can pass as soon as the PTR is updated.

Add an A record (IPv4)

Name: mail
Type: A
Value: your server IPv4 (example: 203.0.113.10)
TTL: 300–3600 seconds is fine

Add an AAAA record (optional IPv6)

Name: mail
Type: AAAA
Value: your server IPv6 (example: 2001:db8::10)

If you’re also adding SPF, DKIM, and DMARC, keep your DNS tidy. Keep notes, too.

It saves time later during deliverability debugging or migrations.

Step 3: Request or set the PTR record (rDNS) with your hosting provider

PTR records don’t usually live at your domain registrar. The reverse zone belongs to whoever controls the IP block.

On a VPS, you’ll typically set rDNS in the provider control panel or via a support ticket. Dedicated servers usually follow the same process.

On a HostMyCode VPS or a dedicated server, request:

IP: 203.0.113.10
PTR (rDNS): mail.example.com

Rule of thumb: one IP → one PTR → one hostname used for SMTP identity.

If you send mail for multiple domains, you can still use a single PTR. Handle multi-domain authentication with SPF/DKIM/DMARC, not by rotating PTRs.

Step 4: Verify rDNS and FCrDNS from your workstation

Give it a little time. Provider TTLs and caching vary.

Test from outside your server’s network.

Check PTR with dig

dig -x 203.0.113.10 +short

Expected output:

mail.example.com.

Check forward DNS points back to the same IP

dig mail.example.com A +short

Expected output:

203.0.113.10

One-liner: confirm FCrDNS quickly

host 203.0.113.10
host mail.example.com

If host 203.0.113.10 returns a different hostname, fix the PTR. If host mail.example.com returns a different IP, fix the A record.

Don’t move on until both agree.

Step 5: Set your server hostname to match the PTR (Ubuntu/Debian + Alma/Rocky)

Receivers often compare your SMTP banner/HELO and sometimes your system hostname against DNS. Keep them consistent to reduce suspicion.

This also makes logs easier to read.

Ubuntu/Debian: set the hostname

sudo hostnamectl set-hostname mail.example.com
hostnamectl

Confirm /etc/hosts is sane

Edit /etc/hosts. Make sure you’re not mapping your public FQDN to 127.0.1.1 on a production mail server.

sudo nano /etc/hosts

A safe, common layout:

127.0.0.1   localhost
# Optional: if your distro uses 127.0.1.1 for short hostname, keep it short only
127.0.1.1   mail

Don’t add your public IP here unless you have a specific reason. Public name-to-IP mapping belongs in authoritative DNS.

Step 6: Make Postfix present the same identity (recommended defaults)

Postfix is common for transactional mail, password resets, and contact forms.

If Postfix announces a different hostname than your PTR, some receivers will score you down.

On Ubuntu/Debian:

sudo postconf -n | egrep 'myhostname|mydomain|myorigin|smtpd_banner'

Set the key values explicitly:

sudo postconf -e 'myhostname = mail.example.com'
sudo postconf -e 'mydomain = example.com'
sudo postconf -e 'myorigin = $mydomain'
sudo postconf -e 'smtpd_banner = $myhostname ESMTP'
sudo systemctl restart postfix

Quick SMTP banner check:

nc -vz 203.0.113.10 25
printf '' | nc 203.0.113.10 25

You should see your server identify as mail.example.com.

Step 7: Open only the ports you actually need (and test them)

Mail servers attract constant scanning. Keep the surface area small.

25/tcp: server-to-server SMTP (usually required for direct outbound/inbound)
587/tcp: submission (authenticated clients)
465/tcp: SMTPS (optional; still widely used by clients)

On Ubuntu with UFW:

sudo ufw allow 25/tcp
sudo ufw allow 587/tcp
sudo ufw allow 465/tcp
sudo ufw status

If you want a hosting-focused firewall baseline first, start here: UFW firewall setup for hosting on Ubuntu.

Then add only the mail ports you need.

Common rDNS failure patterns (and how to fix them fast)

PTR points to a hostname you don’t control

This is common with recycled IPs. Fix: ask your provider to update the PTR to mail.example.com.

Then confirm you don’t have stale forward DNS records in your own zone.

Forward DNS doesn’t match the PTR (FCrDNS fails)

Fix: update the A record for mail.example.com to the exact same IP.

Avoid CNAMEs for the mail host unless you’re certain the receiver accepts them.

PTR uses an apex domain or a generic provider string

Fix: use a real hostname. “server-10-113-0-203.provider.net” is a weak trust signal.

Use mail.example.com and keep it consistent across HELO and banner.

Multiple IPs, one hostname, messy DNS

If you send from multiple public IPs, each IP should have a PTR pointing to a hostname that resolves back to that same IP.

If you can’t keep that clean, reduce outbound IPs until you can.

Practical checklist: rDNS done right for outbound mail

Forward DNS: mail.example.com has an A record to your public IPv4
Reverse DNS: the IP has a PTR record to mail.example.com
FCrDNS passes: dig -x matches dig A
Server hostname: hostnamectl shows mail.example.com
MTA identity: Postfix myhostname and banner match the same FQDN
Firewall: only required SMTP/submission ports are open
Optional but recommended: SPF/DKIM/DMARC added for your sending domain(s)

Migration tip: preserve rDNS when moving mail to a new server

If you migrate mail to a new VPS, rDNS is a small detail that can cause disproportionate pain.

Put it on the cutover checklist:

If your IP changes, request the new PTR before you cut over SMTP sending.
Lower your DNS TTL a day before (e.g., 300 seconds), then restore later.
Keep old outbound sending disabled once the new server is live, to avoid reputation split.

For the wider move (web + DNS + validation), follow a near-zero downtime approach: server migration tutorial with near-zero downtime.

Quick diagnostics: confirm your server looks legitimate to remote mail systems

Once rDNS is correct, check the usual suspects that get mislabeled as “PTR issues.”

Check your public IP (from the server)

curl -4 https://ifconfig.me
# If you use IPv6
curl -6 https://ifconfig.me

Confirm your server can resolve its own hostname

getent hosts mail.example.com
getent hosts $(hostname -f)

Validate the reverse lookup from the server

sudo apt-get update && sudo apt-get install -y dnsutils
host 203.0.113.10

If DNS checks out but mail still bounces, you’re usually dealing with authentication or reputation.

rDNS is required, but it won’t compensate for missing SPF/DKIM/DMARC or poor sending practices.

Where HostMyCode fits: choose the right hosting for mail-capable servers

Outbound mail is sensitive to IP reputation, noisy neighbors, and small configuration mistakes.

If you need predictable control over rDNS, firewall rules, and your mail stack, a VPS is usually the minimum sensible starting point.

Start with a HostMyCode VPS, or choose managed VPS hosting if you don’t want to stay on top of mail tuning and security updates.

If you host client sites with mailboxes and want clean separation between tenants, a dedicated server gives you stronger isolation.

It can also provide steadier outbound behavior, which helps protect a business domain’s reputation.

If you’re sending outbound email from your own server, nail the fundamentals first: a stable IP, correct rDNS, and a locked-down baseline. A HostMyCode VPS gives you the control you need for PTR alignment and straightforward mail troubleshooting. If you want fewer operational chores, managed VPS hosting is a safer fit for production mail and hosting workloads.

FAQ: Reverse DNS setup guide (real-world questions)

How long does a PTR (reverse DNS) change take to propagate?

It’s often visible within minutes, but some resolvers cache longer. Plan for up to a few hours before you judge results, especially during a migration.

Can I set reverse DNS from my domain registrar?

Usually no. Your registrar controls your domain’s forward zone; the IP provider controls the reverse zone.

You typically set PTR in the hosting panel or via support.

Do I need unique rDNS for every domain I send mail for?

No. One IP normally has one PTR.

For multiple sending domains, use SPF/DKIM/DMARC and keep the server identity consistent (HELO/banner/PTR).

Will fixing rDNS stop my emails from going to spam?

It removes a common red flag, but spam placement also depends on SPF/DKIM/DMARC alignment, sending volume patterns, content, and IP/domain reputation.

What if my ISP or VPS blocks port 25?

Many providers restrict outbound port 25 on new servers to reduce abuse.

If you genuinely need direct SMTP, ask your provider for an unblock process, or use authenticated submission on 587 to a relay while you build reputation.

Summary: the “clean identity” baseline for email on a VPS

Correct rDNS isn’t optional. It’s one of the first checks remote mail servers perform.

Set the A record first. Align the PTR next.

Then make sure your server hostname and Postfix identity match what you publish.

After that, focus on SPF/DKIM/DMARC and reputation instead of chasing avoidable bounces.

If you want a stable foundation for mail-capable hosting in 2026, start with a HostMyCode VPS where you can control rDNS and server configuration end to end.