PTR Record Setup Tutorial (2026): Configure Reverse DNS for a VPS or Dedicated Server and Verify Mail & Hostname

Your outbound email can pass SPF and DKIM and still land in spam if reverse DNS doesn’t match what your server claims to be. This PTR record setup tutorial shows how to set a correct PTR record (reverse DNS), align it with your hostname and forward DNS, and verify everything with real commands on a VPS or dedicated server.

This guide assumes you control the server IP (VPS/dedicated). On shared hosting, you usually can’t change reverse DNS yourself.

You’ll need your host to set it.

What a PTR record really does (and why mail servers care)

A PTR record is reverse DNS. It maps an IP address back to a hostname. Mail providers treat it as a credibility check.

In 2026, the usual expectation looks like this:

Your server IP has a PTR record (rDNS) that points to a hostname you control.
That hostname has an A record (or AAAA for IPv6) pointing back to the same IP.
Your mail server presents a matching name in its SMTP banner and HELO/EHLO.

If you skip this alignment, you’ll see errors like “No PTR record”, “Reverse DNS mismatch”, or “HELO name does not resolve”. These often correlate with spam-folder placement or outright SMTP rejection.

Before you change anything: gather your IP, hostname, and DNS plan

Pick the hostname that will represent this server long-term. Common choices are mail.example.com or server1.example.com.

Avoid names you might later repoint to a load balancer or CDN.

Confirm your main public IPv4:
```
curl -4 ifconfig.me
ip -4 addr show
```
Pick a server hostname: Example: mail.example.com
Confirm you control DNS for the domain: You’ll need to create/adjust an A record.

If your domain is registered in one place and DNS is hosted in another, confirm where you will actually edit records.

If you need to move DNS or register a domain, use HostMyCode Domains so you keep clear ownership of DNS and records.

PTR record setup tutorial: configure reverse DNS with your hosting provider

You don’t create PTR records inside your normal DNS zone. Reverse DNS is controlled by the owner of the IP block.

That owner is usually your VPS/dedicated provider.

Set rDNS in the provider panel. If they don’t expose it, open a support ticket and ask them to set it.

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

Create an A record for your chosen hostname that points to your server’s IPv4.

Name: mail
Type: A
Value: 203.0.113.10 (example)
TTL: 300–3600 seconds is fine for changes; you can raise it later.

If you also send mail over IPv6, add an AAAA record and request an IPv6 PTR too.

If you’re not using IPv6, don’t publish it “just because”. A half-configured IPv6 setup is a reliable way to create confusing delivery failures.

Step 2: Set reverse DNS (PTR) for the IP

In your provider’s IP management, set the PTR (rDNS) value to the exact hostname you created. For example:

PTR value: mail.example.com

Be exact and use the fully-qualified name.

Avoid pointing PTR at the bare domain (example.com) if that domain resolves to a website on a different host.

Step 3: Wait for propagation (and know what “propagation” means here)

Reverse DNS changes still rely on resolver caches. Many updates appear within minutes.

Some networks lag for a few hours. Plan for this if you’re doing a migration cutover.

If you suspect caching problems after moving providers, keep this internal reference close: DNS propagation troubleshooting tutorial.

Verify PTR, forward-confirmed reverse DNS (FCrDNS), and mail banner

This is where many “we set rDNS” fixes fall apart. Don’t stop at “the panel says it’s set.”

Verify the full chain from multiple angles.

Check the PTR record from the server

# Replace with your server IP
IP=203.0.113.10

# PTR lookup
dig -x $IP +short

Expected output should be your hostname, such as mail.example.com.

Check the forward record points back to the same IP

HOST=mail.example.com

dig A $HOST +short
# Optional IPv6 check
dig AAAA $HOST +short

Your A record should return the same IPv4 you set in the PTR.

This round-trip consistency is forward-confirmed reverse DNS (FCrDNS), and many anti-spam systems score it.

Validate using getent (uses system resolver)

getent hosts mail.example.com
getent hosts 203.0.113.10

If getent disagrees with dig, you’re likely seeing caching differences or local resolver settings.

Check your SMTP banner / HELO name

If this server runs SMTP (Postfix/Exim), confirm what it presents on port 25. Run this from another machine:

nc -vz 203.0.113.10 25
printf "QUIT\r\n" | openssl s_client -starttls smtp -crlf -connect 203.0.113.10:25 -servername mail.example.com 2>/dev/null | head -n 20

You want the server to identify itself as mail.example.com (or the exact name you configured).

If you see localhost or a generic provider hostname, fix the MTA/hostname settings next.

Align the server hostname on Ubuntu/Debian and AlmaLinux/Rocky

Reverse DNS is only half the story. If the machine’s hostname doesn’t match your DNS plan, you’ll keep failing HELO checks and banner checks.

This matters most on mail servers.

Ubuntu/Debian: set hostname the modern way

sudo hostnamectl set-hostname mail.example.com
hostnamectl status

Then make sure /etc/hosts is reasonable. Don’t map your public IP here.

Keep loopback mappings so services behave during boot and network transitions:

sudo nano /etc/hosts

127.0.0.1   localhost
127.0.1.1   mail.example.com mail

AlmaLinux/Rocky: set hostname and confirm

sudo hostnamectl set-hostname mail.example.com
hostnamectl

Some cloud images ship with aggressive /etc/hosts defaults. If local name resolution looks “creative,” simplify it.

Your hostnames should resolve predictably.

Postfix and Exim: set HELO/EHLO and avoid common mismatches

This isn’t an email-authentication deep dive. The goal is consistency.

Your DNS name, PTR, server hostname, and SMTP identity should all agree.

Postfix: set myhostname and mydomain

Edit /etc/postfix/main.cf:

sudo postconf -n | egrep '^(myhostname|mydomain|myorigin)'
sudo nano /etc/postfix/main.cf

Minimum sane values:

myhostname = mail.example.com
mydomain = example.com
myorigin = $mydomain

Apply:

sudo systemctl restart postfix
sudo systemctl status postfix --no-pager

Exim (common on cPanel/WHM): check primary hostname in WHM

On cPanel servers, the “System Hostname” drives many defaults. In WHM, set a fully-qualified hostname that resolves to the server IP and matches the PTR target.

If you’re running a cPanel VPS for client mail, pair this with a basic security pass. Start with firewall rules so you don’t block AutoSSL or mail ports by accident: cPanel firewall setup guide.

Quick diagnostics: problems you’ll actually see and how to fix them

Most reverse DNS failures come from mismatches. Fix the mapping once, verify it, and you’re done.

Problem: PTR points to a hostname that doesn’t resolve

Symptom: dig -x returns mail.example.com, but dig A mail.example.com returns nothing.
Fix: Create/repair the A record at your DNS provider. Keep it on the same IP.

Problem: PTR points to the bare domain, but the A record is a website on a different IP

Symptom: dig -x returns example.com; forward A for example.com points to a CDN or shared host.
Fix: Change PTR to a dedicated hostname like mail.example.com and point it to your mail server IP.

Problem: You have IPv6 enabled but no IPv6 PTR

Symptom: Some receivers try IPv6 first; mail fails with reverse-DNS complaints.
Fix: Either request/set IPv6 PTR + AAAA properly, or disable IPv6 for SMTP until you can support it cleanly.

Problem: SMTP banner says “localhost” or an old hostname

Symptom: TLS test shows localhost or an unrelated host in greeting.
Fix: Set myhostname in Postfix or the primary hostname in WHM; restart services.

Hardening add-ons that make reverse DNS “stick” in real life

Once PTR and hostname are correct, two habits keep you from redoing this during the next change window.

1) Lock down TLS so your mail/web identity is consistent

It’s common to fix rDNS and then get flagged for weak TLS settings. If the same server hosts websites, tighten HTTPS too.

Use this internal guide for modern ciphers and safe settings: TLS hardening tutorial.

2) Monitor logs so you catch deliverability regressions quickly

Reverse DNS breakage usually happens after an IP swap, restore, or provider migration.

Basic log monitoring and alerts will surface “PTR missing” and “HELO invalid” messages before users complain: VPS log monitoring tutorial.

Checklist: PTR + hostname alignment for a VPS/dedicated server

Pick mail.example.com (or server1.example.com) as the canonical server name.
Create A record: mail.example.com → your IPv4.
Set PTR for the IPv4 to mail.example.com.
Confirm FCrDNS: dig -x IP returns name; dig A name returns same IP.
Set server hostname via hostnamectl to the same FQDN.
Confirm SMTP banner/HELO is consistent (Postfix/Exim).
Repeat for IPv6 only if you actually use IPv6 for SMTP.

Where HostMyCode fits: pick the right server for stable rDNS and mail identity

PTR is simplest when you control the IP and keep the server lifecycle stable.

If you run business email, transactional mail, or host client sites, use a VPS or dedicated plan. That avoids shared hosting rDNS constraints.

For predictable IP ownership and Linux admin flexibility, use a HostMyCode VPS.

If you want the OS, security baseline, and ongoing upkeep handled without babysitting every change, managed VPS hosting is the better option.

If you’re setting up mail or migrating customer sites, reverse DNS is one of the first signals other networks use to judge your server’s identity. HostMyCode provides stable VPS and dedicated infrastructure where rDNS and hostname alignment are straightforward to manage.

Start with a HostMyCode VPS, or move faster with managed VPS hosting if you want help handling the operational details.

FAQ: PTR records and reverse DNS on hosting servers

Do I need a PTR record if I’m not running email?

If the server never sends mail directly to the internet, PTR matters less. Still, some security scanners and APIs flag missing rDNS as a weak identity signal.

It’s worth setting.

Can I set a PTR record from my DNS provider?

Usually no. PTR records live in reverse zones controlled by the IP owner (your hosting provider). You set it in the provider panel or by support request.

Should the PTR point to the same name as my website domain?

Often it shouldn’t. If example.com points to a different server/CDN, you’ll create a mismatch.

Use a dedicated hostname like mail.example.com that points to the mail server IP.

How long does a PTR change take to show up?

It depends on resolver caches and TTLs in reverse zones. Many changes appear within minutes.

Allow a few hours before declaring it broken.

What if I changed IPs during a migration?

Update the A record, set the new PTR on the new IP, and verify both directions again.

For a broader cutover plan (DNS, SSL, rollback), use this server migration tutorial.

Summary: a clean PTR record is a trust signal you can control

A correct PTR record won’t guarantee inbox placement, but it removes an easy reason to distrust your server.

Set forward DNS first, set reverse DNS second, then verify the round-trip and your SMTP identity.

If you need stable IPs and a solid environment for mail and hosting services, start with a HostMyCode VPS and keep rDNS, hostname, and certificates aligned from day one.