Reverse DNS Setup Tutorial (2026): Fix PTR Records for VPS Email, SSL, and Better Deliverability

Most “mystery” email bounces on a VPS don’t come from your SMTP config. They come from reverse DNS.

This reverse DNS setup tutorial shows how to set a correct PTR record (rDNS), match it to your A/AAAA records, and confirm forward-confirmed reverse DNS (FCrDNS). When those match, providers stop treating your server like an unverified host.

This guide is for VPS and dedicated server operators. It also fits anyone running cPanel/DirectAdmin/Plesk mail or a simple Postfix relay.

You’ll run a few DNS checks, pick a clean hostname, request one PTR change, and validate everything with real commands.

What you’ll fix (and how to tell rDNS is the problem)

A PTR record maps your server IP address back to a hostname (for example, mail.example.com). Many receivers check three basics:

Your sending IP has a PTR record (rDNS exists).
The PTR hostname resolves back to the same IP (FCrDNS).
Your SMTP banner/HELO uses a reasonable, resolvable hostname.

Broken or missing rDNS usually shows up like this:

Outbound mail bounces with errors such as “No PTR record”, “reverse DNS lookup failed”, or “hostname does not resolve”.
Messages land in spam even though SPF/DKIM/DMARC look correct.
TLS handshakes or certificate validation warnings when services expect a stable hostname.

If you’re also setting up SPF/DKIM/DMARC, pair this with our internal guide on email authentication setup.

rDNS is the step people skip. Mail providers notice.

Prerequisites: pick the “right” hostname before you touch PTR

The easiest way to create a deliverability headache is to pick a random PTR name now and change it later.

Choose a hostname you can keep for the life of the server.

Use a dedicated hostname for mail: mail.example.com or smtp.example.com.
Make sure you control DNS for example.com (at your DNS provider or in your control panel).
Use one hostname per sending IP. If you send from multiple IPs, assign one hostname per IP.

If you need a domain first (or you’re moving DNS away from a registrar that keeps breaking records), HostMyCode’s domains and DNS makes it easier to manage A/AAAA/MX/TXT records alongside your hosting.

Step 1: Identify your sending IP (IPv4 and IPv6)

Run these on the server that sends mail. Control panels don’t change what receivers evaluate.

Receivers look at the public outbound IP.

# IPv4
curl -4s https://ifconfig.co

# IPv6 (only if you actually send mail over IPv6)
curl -6s https://ifconfig.co

Also list the server’s configured addresses:

ip -br a

Decision point: If IPv6 is enabled but you’re not ready to maintain AAAA + PTR + correct mail routing, disable outbound SMTP over IPv6 or complete the configuration.

Partially configured IPv6 often causes “sometimes it works” rejections.

Step 2: Create forward DNS records (A/AAAA) for your mail hostname

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

If you will send mail over IPv6, add an AAAA record too.

Example target hostname: mail.example.com

A: mail.example.com → 203.0.113.10
AAAA (optional): mail.example.com → 2001:db8::10

Verify from your laptop or another network outside the server. That avoids misleading results from local caching.

dig +short A mail.example.com
dig +short AAAA mail.example.com

If the domain or records are brand new, you may need to wait for propagation.

During changes, keep TTL reasonable (300–900 seconds). That gives you time to correct mistakes quickly.

If you’re planning a provider change, finish the DNS side first. Then do a controlled cutover.

Our DNS propagation tutorial walks through TTL planning and rollback.

Step 3: Set the PTR record (rDNS) with your VPS provider

PTR records aren’t set in your normal DNS zone. The IP owner (your hosting provider) controls them.

On most VPS platforms, you set PTR in the control panel under “Reverse DNS” for the IP address.

Set the PTR value to your chosen hostname:

203.0.113.10 PTR → mail.example.com

Wait 5–60 minutes (provider-dependent), then verify:

dig +short -x 203.0.113.10
# Expected: mail.example.com.

Pitfall: Some panels auto-append a trailing dot. That’s normal DNS formatting.

A PTR target of mail.example.com. is correct.

Step 4: Verify forward-confirmed reverse DNS (FCrDNS)

FCrDNS is what many mail systems actually care about.

The PTR points to a hostname, and that hostname points back to the same IP.

# 1) Reverse lookup (IP -> name)
PTR=$(dig +short -x 203.0.113.10 | head -n1)
echo "$PTR"

# 2) Forward lookup (name -> IP)
dig +short A ${PTR%.}

# Optional: compare automatically
REV_NAME=$(dig +short -x 203.0.113.10 | head -n1 | sed 's/\.$//')
FWD_IP=$(dig +short A "$REV_NAME" | head -n1)
echo "Reverse name: $REV_NAME"
echo "Forward IP:   $FWD_IP"

If the forward IP doesn’t match your sending IP, stop and fix it.

Either correct the A record or change the PTR target. Don’t move on until they match.

Step 5: Align your server hostname and SMTP banner (Ubuntu/Debian and control panels)

A PTR record gets you past basic rejection checks. Consistent identity builds a cleaner reputation over time.

Aim for:

System hostname: mail.example.com (or a stable host like vps1.example.com if you prefer)
Mail service banner/HELO: the same hostname, resolvable, and consistent with rDNS

Ubuntu/Debian: set the system hostname

sudo hostnamectl set-hostname mail.example.com
hostnamectl

Make sure /etc/hosts doesn’t mislead your system. Keep localhost entries for 127.0.0.1.

Only map your public IP to the hostname if you have a clear reason. On most VPS hosts, you don’t need the public IP in /etc/hosts.

Postfix: set myhostname and smtp_helo_name

Open /etc/postfix/main.cf and set:

myhostname = mail.example.com
smtp_helo_name = $myhostname

Reload Postfix:

sudo postfix check
sudo systemctl reload postfix

If you’re not running a full mail server and you only relay app/WordPress mail through Postfix, keep it simple.

Follow our guide on setting up a VPS SMTP relay, then apply the rDNS steps here.

cPanel/WHM: check the hostname (and don’t skip it)

In WHM, go to Networking Setup → Change Hostname and set a fully-qualified hostname (FQDN) you control (for example, server1.example.com).

Then ensure that hostname has an A record pointing to the server IP. Keep your PTR consistent with what your server uses for outbound mail.

WHM behavior depends on whether mail leaves from the main shared IP or dedicated IPs per account.

If deliverability is broadly bad, fix the server-level identity first. Then tune per-domain settings.

Step 6: Add SPF, DKIM, and DMARC (quick baseline)

rDNS won’t get you consistent inbox placement by itself. It mainly prevents hard rejections and removes “unknown host” signals.

In 2026, authentication is the baseline for business mail.

At minimum, add:

SPF: authorize your sending IP(s)
DKIM: cryptographically sign outgoing mail
DMARC: set policy and reporting

Rather than repeating a long workflow here, use our step-by-step: configure SPF, DKIM, DMARC, and rDNS for a VPS mail server.

The PTR and FCrDNS checks from this guide fit directly into that process.

Step 7: Test with real checks (DNS, SMTP banner, and a controlled send)

Run these from a machine outside your VPS network when you can. It’s the fastest way to see what receivers see.

DNS sanity

# Reverse lookup
 dig +short -x 203.0.113.10

# Forward lookup (should return the same IP)
 dig +short A mail.example.com

SMTP banner and EHLO/HELO

This shows what your server presents during the handshake:

openssl s_client -starttls smtp -crlf -connect mail.example.com:587 </dev/null 2>/dev/null | sed -n '1,20p'

If you don’t expose port 587/25 publicly, that’s fine. Test through a tunnel from your workstation instead.

See SSH port forwarding to reach SMTP without opening public ports.

Send a message and inspect the “Received:” headers

Send a message to a mailbox you control (Gmail, Outlook, or your corporate provider), then open the raw headers.

Check for:

Your sending IP
The reverse-resolved hostname matching your PTR
SPF/DKIM/DMARC results (once enabled)

If messages still bounce or queue, the issue is likely in the SMTP path or reputation. It’s not the PTR alone.

HostMyCode has a focused guide for email deliverability troubleshooting that picks up from here.

Control panel notes: dedicated IPs, resellers, and multi-tenant servers

Shared hosting adds a twist: many domains may send from one IP.

That can work, but it makes consistency and IP reputation much more important.

Dedicated IP per domain helps high-volume senders and resellers. It also makes rDNS and HELO alignment simpler.
One PTR per IP means you can’t assign a different PTR to every domain on the same IP. Use a neutral name like mail.yourbrand.tld.
Keep the PTR stable. Frequent PTR changes can look suspicious to some receivers.

If you run a reseller server, document the policy.

Decide who gets dedicated IPs, what PTR naming scheme you’ll use, and what “acceptable use” means for bulk sending.

Troubleshooting: quick fixes for common rDNS failures

PTR exists, but forward lookup doesn’t match

Fix the A record for the PTR hostname so it points back to the sending IP.
If the A record is correct, confirm you’re checking the right IP (main IP vs NAT vs outbound IP).

PTR keeps reverting or won’t set

Some providers restrict PTR format or require the hostname to exist first. Create the A record, then set PTR.
On managed platforms, support may need to apply it on the backend.

IPv6 mail fails even though IPv4 works

Set AAAA + IPv6 PTR (ip6.arpa), then verify FCrDNS for IPv6.
If you don’t need IPv6 for mail, configure your MTA to prefer IPv4 for outbound delivery.

cPanel/WHM shows hostname warnings

Set WHM hostname to an FQDN with an A record.
Confirm your rDNS aligns with the server’s main sending IP.
Run WHM’s built-in checks after changes.

Operational checklist (copy/paste for change tickets)

Choose mail hostname: mail.example.com
Create A (and optional AAAA) records for the hostname
Set PTR for the sending IP to the hostname
Verify: dig -x returns the hostname
Verify: hostname resolves back to the same IP (FCrDNS)
Set server hostname (or at least Postfix myhostname)
Confirm SMTP banner presents a resolvable hostname
Enable SPF/DKIM/DMARC
Send a test email and inspect headers

Where HostMyCode fits (practical hosting guidance)

rDNS is easier to manage when your IPs stay put and your provider exposes reverse DNS controls that actually work.

If you run business email, transactional mail, or a control panel server, stable IP ownership makes a real difference.

HostMyCode offers HostMyCode VPS plans for hands-on admins and managed VPS hosting when you want help cleaning up DNS alignment, hostnames, and the basic deliverability checks.

If you’re rebuilding deliverability or moving clients off a noisy shared IP, start with a clean VPS and a stable PTR from day one. HostMyCode can provision the right-sized server and help you line up DNS, rDNS, and core mail settings without guesswork.

See HostMyCode VPS options or choose managed VPS hosting for a guided setup.

FAQ: Reverse DNS and PTR records

Do I set PTR in my domain’s DNS zone?

No. PTR (reverse DNS) is controlled by the IP owner—your VPS/dedicated provider. You set it in the provider panel (or via support), not in your normal example.com zone file.

Can I have multiple PTR records for one IP?

You can technically publish multiple PTRs, but many receivers expect a single stable identity. For hosting and email deliverability, one PTR per sending IP is the cleanest approach.

What should my PTR be on a shared hosting server?

Use a neutral hostname you control, like mail.yourhostbrand.tld or server1.yourhostbrand.tld, and make sure it forward-resolves back to the main shared sending IP.

How long does it take for rDNS to update?

Often 5–60 minutes, but it depends on provider and caching. Use dig -x repeatedly to confirm what the public internet sees.

Will correct rDNS guarantee inbox placement?

No. It prevents a class of rejections and improves trust signals. You still need SPF/DKIM/DMARC, sensible sending volume, and clean content.

Summary: a clean PTR is a fast win

Set a stable hostname, publish the A/AAAA records, point your PTR to that hostname, and verify FCrDNS.

Then make your SMTP banner and authentication records match. This combination removes one of the most common reasons VPS mail gets rejected.

If you’re planning a move to a server with stable IPs and predictable DNS control, start with HostMyCode VPS and treat rDNS as a go-live item, not a last-minute rescue.