PTR Record Setup Tutorial (2026): Configure Reverse DNS for a Hosting VPS to Fix Email Rejections

Email can fail even when SPF, DKIM, and DMARC look perfect. Some strict receivers still bounce mail when reverse DNS is missing or inconsistent.

This PTR record setup tutorial shows how to set a PTR record on a hosting VPS, verify forward-confirmed reverse DNS (FCrDNS), and fix the most common bounce messages.

What you’ll set up (and why it matters for SMTP)

A PTR record maps your server’s IP address back to a hostname. This is reverse DNS.

Most mailbox providers want one clean, consistent identity:

Your VPS IP → PTR → mail.yourdomain.com
mail.yourdomain.com → A/AAAA → the same VPS IP (FCrDNS)
Your SMTP banner/HELO matches that hostname, or is at least consistent

If those checks fail, you’ll see bounces like 550 Reverse DNS required or Client host rejected: cannot find your reverse hostname. Sometimes mail “delivers,” but lands in spam.

If you host web and email on the same VPS, set reverse DNS early. It’s a quick fix, and it prevents wasted time in the wrong logs.

Prerequisites checklist (5 minutes)

A VPS or dedicated server with a static public IPv4 (IPv6 is optional but recommended).
A domain name you control (you’ll create an A/AAAA record).
Root or sudo access to the server.

If you’re still choosing infrastructure, start with a HostMyCode VPS. You get a clean static IP and full DNS control for mail and web.

Step 1: Pick a reverse DNS hostname that won’t bite you later

Use a dedicated hostname for mail. Common, safe choices:

mail.example.com (best default)
smtp.example.com (also fine)
vps1.example.com (okay, but less semantically clear)

Avoid using your website apex (example.com) as the PTR target unless you deliberately share DNS and TLS for web and mail.

Keeping mail on mail. reduces edge cases with redirects, CDN proxies, and multiple A records.

Step 2: Confirm your current public IP (IPv4 and IPv6)

On your VPS, run:

curl -4 ifconfig.me
curl -6 ifconfig.me 2>/dev/null || true

Write down the IPv4 address. If you have IPv6, record that too.

Step 3: Create forward DNS (A/AAAA) for the PTR hostname

Set forward DNS first. Many receivers check reverse DNS and then verify the forward match (FCrDNS).

In your DNS zone, add:

A: mail.example.com → <your_ipv4>
AAAA (if IPv6): mail.example.com → <your_ipv6>

If your domain is registered elsewhere, you can still manage it cleanly using HostMyCode domains and DNS. This keeps mail records, web records, and future migrations in one place.

During setup, use a lower TTL (like 300 seconds) so changes validate faster. Once everything checks out, raise it to something calmer (3600–14400).

Step 4: Request the PTR record from your hosting provider

You can’t create a PTR record in your normal DNS zone. PTR records live in the reverse zone owned by the IP provider (your host).

In your hosting panel or a support ticket, request:

IPv4: <your_ipv4> → PTR → mail.example.com
IPv6: <your_ipv6> → PTR → mail.example.com (optional, but recommended)

Keep the identity consistent.

If your PTR points to one name but your server announces another in HELO, you invite reputation trouble.

Step 5: Verify reverse DNS and FCrDNS from the command line

After your provider confirms the change (or after 15–60 minutes), verify it. You can run these checks from your VPS or any Linux/macOS shell.

Check the PTR record

dig -x <your_ipv4> +short

You want output like:

mail.example.com.

Check forward DNS matches the same IP (FCrDNS)

dig mail.example.com A +short
# if you use IPv6:
dig mail.example.com AAAA +short

The A/AAAA results must match your server IPs exactly.

One-liner FCrDNS sanity check

ip=<your_ipv4>; host $ip; hn=$(host $ip | awk '{print $NF}' | sed 's/\.$//'); echo "PTR=$hn"; host $hn

If the final host lookup doesn’t point back to the same IP, fix forward DNS first.

Step 6: Make Postfix announce the right hostname (common fix for rejections)

Reverse DNS helps. Many receivers also compare the SMTP banner/HELO against rDNS.

With Postfix, set the hostname explicitly so it matches what you published.

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

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

Apply changes:

sudo postfix check
sudo systemctl reload postfix

If you’re debugging active delivery failures or a growing queue, keep this handy: Mail Queue Troubleshooting Tutorial (2026) for Postfix.

Step 7: Align TLS certificate names with your mail hostname

If your SMTP server presents a certificate for a different name than it announces in HELO, some receivers will log TLS name mismatches. Delivery may still work, but you lose an easy trust signal.

For many VPS mail setups, the simplest option is a Let’s Encrypt certificate for mail.example.com. If you want a clean SSL workflow, follow: Let’s Encrypt setup guide tutorial (2026).

Step 8: Test SMTP from the outside (what receivers actually see)

From a remote shell (or your laptop), connect to your server’s SMTP port. Replace the IP and use the port you actually run.

Use 25 for server-to-server delivery, and 587 for submission:

nc -vz <your_ipv4> 25
openssl s_client -starttls smtp -connect <your_ipv4>:25 -servername mail.example.com

Check for three things:

The banner includes mail.example.com (or your chosen hostname).
The certificate subject/SAN includes mail.example.com.
No obvious TLS verification errors.

Step 9: Add mail DNS records that work with rDNS (SPF, DKIM, DMARC)

Reverse DNS is one signal. Authentication is another.

When you combine them, you usually see fewer 5xx bounces and fewer “accepted but spam-folder” deliveries.

SPF includes your sending IP or hostname.
DKIM signs outbound mail.
DMARC enforces alignment and gives you reports.

For a practical, modern configuration flow, use: DMARC setup tutorial (2026).

Step 10: Common bounce messages and what to fix

“Reverse DNS required” / “PTR record missing”

PTR not set, or set on the wrong IP.
Fix: set PTR for the exact outbound IP (check NAT if applicable).

“Client host rejected: cannot find your reverse hostname”

Receiver can’t resolve your PTR target to an A record.
Fix: create mail.example.com A record and confirm it points to your sending IP (FCrDNS).

“HELO/EHLO name does not resolve” or “HELO mismatch”

Postfix announces a hostname not present in DNS.
Fix: set myhostname to your PTR hostname and reload.

Mail sends, but lands in spam

Reverse DNS exists, but authentication or reputation is weak.
Fix: SPF/DKIM/DMARC alignment, gradual sending ramp, and clean lists.

If you suspect reputation issues after PTR and authentication are clean, this is the right next step: Email Blacklist Removal Tutorial (2026).

Step 11: Troubleshoot “it’s set, but I still see the old PTR”

Reverse DNS updates can look inconsistent while resolvers cache older answers.

Run through this list before you assume the provider didn’t apply the change:

Check authoritative answers: dig -x <ip> +trace (watch where it changes).
Query public resolvers: dig -x <ip> @1.1.1.1 +short and dig -x <ip> @8.8.8.8 +short.
Confirm your outbound IP: some VPS setups send mail via a different interface/IP.
Confirm your firewall isn’t blocking DNS: if you’re troubleshooting UFW rules, see UFW firewall troubleshooting tutorial (2026).

If you recently changed hostnames, restart mail services. This refreshes banners and clears cached identity in the service process:

sudo systemctl restart postfix

Step 12: Production checklist (copy/paste)

[ ] A record: mail.example.com → VPS IPv4
[ ] AAAA record (optional): mail.example.com → VPS IPv6
[ ] PTR for IPv4 points to mail.example.com
[ ] PTR for IPv6 (if used) points to mail.example.com
[ ] FCrDNS passes: PTR hostname resolves back to the same IP
[ ] Postfix myhostname matches PTR hostname
[ ] SMTP TLS cert includes mail.example.com
[ ] SPF, DKIM, DMARC configured and aligned
[ ] You’ve tested an external SMTP handshake and banner

Summary: a clean PTR setup removes avoidable deliverability failures

Reverse DNS is a baseline check, and receivers treat it that way.

Pick one stable mail hostname. Make forward DNS match it. Then configure your MTA to announce the same name.

Done right, you’ll avoid many “blocked for policy reasons” bounces. You’ll also reduce slow spam-folder drift.

If you want predictable IP ownership and a straightforward path to mail + web hosting on one server, choose HostMyCode VPS or step up to HostMyCode dedicated servers when you need dedicated IP ranges and higher-volume sending control.

If you run email and websites on the same machine, you need stable DNS, a static IP, and reliable server access. Start with HostMyCode VPS for full control, or choose managed VPS hosting if you want help with mail identity, security updates, and routine operational checks.

FAQ

Can I set a PTR record myself in Cloudflare or my DNS zone?

No. PTR records live in the reverse DNS zone owned by the IP provider. You request it from your VPS/dedicated server host. You still must create the forward A/AAAA record in your normal DNS.

Should my PTR point to my website domain or a mail subdomain?

Use a mail subdomain like mail.example.com. It keeps your web stack (CDN, redirects, multiple A records) from creating FCrDNS or TLS mismatches.

Do I need reverse DNS for IPv6 too?

If you send mail over IPv6, yes. If you only send over IPv4, IPv6 PTR is optional. Still, setting it is good hygiene if the address is assigned and reachable.

How long does PTR propagation take?

Often 15–60 minutes, sometimes a few hours depending on resolver caches and the reverse zone TTL. Verify with multiple public resolvers using dig -x.

What if my provider sets PTR correctly but mail still bounces?

Check FCrDNS (forward record), then your HELO/banner, then SPF/DKIM/DMARC alignment. If you’re seeing timeouts or TLS errors rather than policy bounces, troubleshoot the transport separately.