Email deliverability can fail quietly when your PTR (reverse DNS) is wrong. One missing record can turn a “works on my server” setup into rejected SMTP sessions, junk-folder placement, or throttling. This reverse DNS setup tutorial shows how to set PTR correctly for a VPS or dedicated server, verify it end-to-end, and avoid the gotchas that still waste hours in 2026.
What you’re setting up (and why mail providers care)
Reverse DNS maps an IP address back to a hostname using a PTR record. Most receiving mail servers compare three items and expect them to match:
- The connecting IP → PTR hostname (reverse lookup)
- The server’s HELO/EHLO hostname
- The hostname’s A/AAAA record → back to the same IP (forward lookup)
If they don’t line up, you’ll see errors like 450 4.7.1 Client host rejected, “no PTR”, or “HELO does not resolve”. Some providers still accept the message, but treat it as lower-trust mail. That usually shows up as inconsistent inbox placement.
If you run your own mail stack (Postfix, Exim, cPanel/WHM), set PTR before you warm up the sending IP. If you send through a third-party relay, PTR matters less for delivery.
It can still help with server identity and troubleshooting.
Prerequisites checklist (do this before touching PTR)
Reverse DNS is simple, but it’s easy to configure it inconsistently. Before you change anything, collect:
- Your sending IP (the IP that will connect to other SMTP servers)
- The desired hostname (example:
mail.example.com) - Access to IP control (VPS panel, provider portal, or ticket process)
- DNS control for the domain (to set the matching A/AAAA records)
On the server, confirm the real outbound IP.
Don’t rely on interface names if you’re behind NAT or you have multiple addresses:
curl -4 https://ifconfig.co
curl -6 https://ifconfig.co # only if you send mail over IPv6Then confirm your current hostname and FQDN:
hostnamectl
hostname -fIf you’re building a new mail host and want fewer surprises, start from a clean VPS with predictable networking.
A HostMyCode VPS gives you direct control of IP settings (including rDNS), which is often the blocker on budget providers.
Reverse DNS setup tutorial: set PTR correctly (IPv4 and IPv6)
The rule that keeps you out of trouble: pick one stable FQDN you control. Use it everywhere—PTR, forward DNS, and HELO/EHLO.
Step 1: Pick a sane mail hostname
Choose a hostname that exists in DNS and won’t change during routine maintenance or migrations. Common options:
mail.example.com(most common)mx1.example.com(useful if you run multiple MTAs)server123.example.com(works, but doesn’t read as “mail”)
Avoid setting PTR to a random provider hostname (like vps-123.provider.net) if you send as @example.com. It can work, but it raises the odds of stricter filtering and confusing diagnostics.
Step 2: Create forward DNS records (A/AAAA)
In your authoritative DNS zone for example.com:
- Create an A record:
mail.example.com→ your IPv4 - If you send email over IPv6, create an AAAA record:
mail.example.com→ your IPv6
If you prefer keeping domain and DNS management in one place, you can register and manage DNS for your mail hostname with HostMyCode domains.
Step 3: Set PTR (reverse DNS) for the sending IP
You can only set PTR from the party that controls the IP block. In practice, that’s your VPS or dedicated provider.
Set the PTR value to the exact hostname you created above:
- IPv4 PTR:
<your IPv4>→mail.example.com - IPv6 PTR:
<your IPv6>→mail.example.com
Formatting details that matter:
- No trailing spaces. Some panels accept them and quietly publish broken PTR.
- Use an FQDN (not just
mail). - Stick to one hostname per IP. Multiple PTRs aren’t standard practice for SMTP reputation.
Step 4: Ensure your server’s HELO/EHLO matches
Now make your mail software present the same identity during SMTP.
Postfix (Ubuntu/Debian/RHEL-family):
sudo postconf -n | egrep 'myhostname|mydomain|myorigin'Set the hostname:
sudo postconf -e 'myhostname = mail.example.com'
sudo systemctl restart postfixExim on cPanel/WHM: WHM typically uses the system hostname. In WHM, set:
- Networking Setup → Change Hostname →
mail.example.com
After that, verify the hostname resolves properly from outside your network.
If you’re running WHM mail, follow your full mail stack steps too.
This pairs well with this cPanel mail server setup guide, which covers Exim, DNS, and secure SMTP.
Verify PTR, forward-confirmed reverse DNS, and real SMTP behavior
“PTR set” isn’t the same as “PTR working.” Test from somewhere other than the mail server (or use public resolvers). That helps you avoid being misled by local caching.
Check reverse lookup
dig +short -x 203.0.113.10
# expected output:
# mail.example.com.Check forward lookup
dig +short mail.example.com A
dig +short mail.example.com AAAACheck “FCrDNS” (forward-confirmed reverse DNS)
FCrDNS means the PTR points to a hostname, and that hostname resolves back to the same IP.
IP=203.0.113.10
HOST=$(dig +short -x $IP | head -n1)
echo "PTR -> $HOST"
dig +short $HOST AIf the A record returns a different IP than the one you started with, fix the A record or PTR before you send anything.
Confirm what your server says in SMTP
This catches a common mismatch: PTR is correct, but HELO is still wrong.
sudo apt-get update && sudo apt-get install -y swaksswaks --server 127.0.0.1 --helo mail.example.com --quit-after HELOYou should see the banner and the HELO/EHLO exchange without warnings. If the banner name differs, revisit your MTA configuration and system hostname.
For DNS-side mail authentication alignment, pair PTR with SPF, DKIM, and DMARC. Use this email authentication setup guide to finish the baseline.
Common pitfalls (and how to fix them fast)
Most “PTR problems” are really consistency problems. These issues show up repeatedly on VPS and dedicated servers.
Pitfall 1: PTR set, but A record missing
Many providers let you set PTR to any name, even if it doesn’t resolve. Receivers often check the forward lookup and penalize mismatches.
Fix: create the A/AAAA record for the PTR hostname, then retest FCrDNS.
Pitfall 2: You’re sending from the wrong IP
Multiple IPs, NAT, or outbound relays can mean the connecting IP isn’t the one you updated.
Fix: confirm the actual source IP in logs.
On Postfix, check /var/log/mail.log (Debian/Ubuntu) or /var/log/maillog (RHEL-family). On cPanel/WHM, review Exim’s mainlog in /var/log/exim_mainlog.
Pitfall 3: HELO/EHLO is “localhost” or an internal name
This is common after quick installs, migrations, or snapshots restored onto a new host.
Fix: set the system hostname to your FQDN and configure your MTA to use it. Restart the service after changes.
Pitfall 4: IPv6 exists, but PTR doesn’t
If your server advertises IPv6 and connects over IPv6, receivers may check the IPv6 PTR. Many providers are stricter on IPv6 than IPv4.
Fix: either set the IPv6 PTR and AAAA correctly or ensure your SMTP traffic prefers IPv4 for outbound delivery (provider policies vary; don’t force this unless you know why).
Pitfall 5: rDNS changes take time (and caches lie)
PTR updates can appear quickly, but caches can lag.
Check more than one resolver before you assume it didn’t work:
dig +short -x 203.0.113.10 @1.1.1.1
dig +short -x 203.0.113.10 @8.8.8.8
dig +short -x 203.0.113.10 @9.9.9.9cPanel/WHM notes: keep hostname, AutoSSL, and DNS consistent
On WHM servers, the hostname affects a lot. It drives service SSLs, Exim’s identity, and defaults clients see.
If you change it after the server is live, schedule the work. Then re-check TLS and mail flows afterward.
- Set hostname in WHM → Networking Setup → Change Hostname.
- Ensure
mail.example.comhas correct A/AAAA. - Re-run AutoSSL if needed so services present valid certificates.
If you’re hardening the box too, use an order that won’t lock you out.
Add SSH keys first, then configure the firewall, then run mail and DNS checks.
This firewall audit tutorial helps you tighten ports without breaking SMTP, IMAP, or webmail.
Quick deliverability sanity checks after PTR is live
PTR is required, but it’s not the whole deliverability picture. Once DNS is consistent, do a quick pass over:
- Banner and HELO show your mail hostname (not an internal name).
- SPF includes the sending IP.
- DKIM signs outbound mail and validates.
- DMARC policy starts at
p=nonefor rollout, then moves stricter. - TLS is offered on SMTP and has a valid chain.
For a clean DMARC rollout (and avoiding “looks fine but fails alignment”), use the step-by-step in this DMARC setup tutorial.
Migration and IP change: how to avoid breaking PTR overnight
PTR breaks most often during migrations. The hostname stays the same, but the sending IP changes underneath it.
Plan the order and you’ll avoid surprises during cutover:
- Provision the new server and assign the new IP.
- Create/confirm
mail.example.comA/AAAA points to the new IP (or be ready to flip it). - Set PTR for the new IP to
mail.example.com. - Only then switch outbound mail to the new server.
If you’re migrating customer hosting, keep rollback realistic. A tested backup and snapshot routine makes the move survivable.
Start with this VPS snapshot backup tutorial if you don’t already run restore drills.
Wrap-up: a clean PTR setup you can defend in an audit
A correct PTR setup isn’t complicated. Pick one hostname and point it to your sending IP.
Set PTR back to that hostname, and make sure your MTA uses it in HELO.
Verify with dig -x, confirm FCrDNS, and test SMTP behavior with swaks. Once that’s done, you’ve removed one of the most common “silent” causes of mail delivery trouble on VPS and dedicated servers.
If you run mail on your own infrastructure, use hosting where you can control rDNS and keep the IP stable. A HostMyCode VPS is a solid fit for production email, and managed VPS hosting is a good option if you want DNS, security, and mail checks handled with you instead of dumped on you.
FAQ
How long does it take for a PTR record change to work?
Often minutes, sometimes a few hours. The usual limiter is resolver caching. Test against multiple public resolvers (1.1.1.1, 8.8.8.8, 9.9.9.9) to confirm the change is visible broadly.
Can I set PTR from my domain registrar?
No. PTR is controlled by whoever owns the IP address block (your VPS/dedicated provider). Your registrar controls A/AAAA and MX records for your domain, not reverse DNS for your IP.
What should my PTR be: the domain root or a mail subdomain?
Use a dedicated hostname like mail.example.com and keep it consistent with HELO/EHLO. The domain root can work, but it often clashes with web hosting changes and CDN setups.
Do I need reverse DNS if I only receive email?
Not always. Receiving-only servers can still benefit, but strict checks usually apply to outbound SMTP. If you send any mail directly (even password resets), set PTR.
My PTR is correct but emails still go to spam—what next?
Check SPF/DKIM/DMARC alignment, TLS on SMTP, content and volume patterns, and whether your IP has a poor history. Start with the authentication steps in the linked SPF/DKIM/DMARC tutorial, then review your MTA logs for rejections and deferrals.