Set Up a PTR Record for Your VPS Mail Server

If you're sending mail straight from a VPS — Postfix, Exim, or a mail queue behind a Node/PHP app — and messages keep landing in spam or getting rejected outright with a "poor reputation" bounce, the first thing we check isn't SPF or DKIM. It's whether your IP has a matching PTR record. Missing or mismatched reverse DNS is one of the most common, and most overlooked, reasons a technically well-configured mail server still can't get mail delivered.

Symptom: Mail Bounces or Gets Flagged Even Though DNS Looks Fine

You've set up SPF, DKIM, maybe even DMARC. The zone file checks out. And yet:

• Outbound mail bounces with something like 550 5.7.1 Client host rejected: cannot find your reverse hostname or 450 4.7.1 Client host rejected: Access denied.
• Gmail, Outlook, or Yahoo silently drop or spam-folder mail from your server, but mail from your old shared host went through fine.
• A mail-tester.com or MXToolbox report flags "no rDNS" or "PTR mismatch" as the top issue, even though SPF/DKIM both pass.

This almost always points to reverse DNS — the lookup that lets a receiving mail server resolve your IP address back to a hostname, and check that the hostname matches what your server claims to be in the SMTP handshake.

Cause: PTR Records Live on the IP, Not the Domain

Here's the part that trips people up coming from shared hosting: a PTR (pointer) record isn't something you add in your domain's DNS zone. It's attached to the IP address itself, and it's controlled by whoever owns that IP block — your VPS or cloud provider, not your registrar.

So even if mail.yourdomain.com has a perfect A record pointing at your VPS, that's only half the relationship. Reverse DNS needs the reverse mapping too: your IP address's PTR record needs to resolve back to a hostname, and that hostname should match (or at least be consistent with) what your mail server sends in its EHLO/HELO greeting.

Three things commonly go wrong on a fresh VPS:

• The provider never set a PTR record at all — it defaults to something generic like vps-a1b2c3.provider.net.
• You changed your server's hostname (say, from the provider default to mail.yourdomain.com) in /etc/hostname and your MTA config, but never updated the PTR to match.
• You're on a shared IP (common on cheaper VPS/cloud tiers) and the PTR is locked to the provider's default and can't be changed without a dedicated IP.

Fix: Check, Then Match, the Forward and Reverse Records

1. Check what your PTR currently resolves to

Run this from any Linux machine (or your VPS itself):

dig -x YOUR.SERVER.IP.ADDRESS +short

Or with host:

host YOUR.SERVER.IP.ADDRESS

If that returns nothing, or returns the provider's generic hostname instead of your mail hostname, that's your problem.

2. Confirm what your mail server actually announces

Telnet to your own mail port and watch the greeting:

telnet localhost 25
# or, for a quick remote check:
openssl s_client -connect yourdomain.com:587 -starttls smtp

For Exim, check the configured hostname:

exim -bP primary_hostname

For Postfix:

postconf myhostname

Whatever comes back here has to be exactly the string your PTR record resolves to. A trailing dot, a subdomain mismatch, or a leftover default hostname will all trip up strict receiving servers.

3. Set the PTR record with your IP/network provider

Unlike A records or MX records, you can't edit this from cPanel's Zone Editor or WHM's DNS functions — it has to be set wherever the IP block is managed:

Once it's set, propagation for PTR is usually quick (minutes to a couple of hours) since it's controlled by the provider, not cached the same way a domain's TTL is.

4. Make the forward record match too

PTR resolves IP → hostname. For full "FCrDNS" (forward-confirmed reverse DNS) — which some strict mail systems specifically check — the hostname the PTR returns needs to also have an A record pointing right back at the same IP. So if your PTR resolves to mail.yourdomain.com, make sure:

mail.yourdomain.com.   IN A   YOUR.SERVER.IP.ADDRESS

exists in your domain's zone. Add it in cPanel's Zone Editor, or WHM if you manage DNS for the account, then verify with:

dig mail.yourdomain.com +short

5. Update your MTA's hostname to match

If the PTR and your mail server's announced hostname don't line up, fix the server side rather than fighting the DNS. On Postfix:

postconf -e 'myhostname = mail.yourdomain.com'
systemctl restart postfix

On Exim (via WHM), go to WHM → Exim Configuration Editor → Basic Editor and set the primary hostname there, or edit primary_hostname directly if you manage Exim outside cPanel. Restart Exim afterward.

6. Re-test

Send a fresh test through mail-tester.com or send to check-auth@verifier.port25.com and read the report — it will explicitly flag rDNS pass/fail near the top, separate from SPF/DKIM.

Prevention: Set It Once, at Provisioning Time

• Set the hostname before you configure mail. Decide on your mail server's hostname (e.g. mail.yourdomain.com) at server setup, put it in /etc/hostname, and request the matching PTR immediately — don't wait until deliverability breaks.
• Get a dedicated IP for outbound mail if you're on shared cloud IPs. A shared IP means you inherit whoever else's sending reputation is on it, and you often can't set a custom PTR at all.
• Keep hostname changes in sync. If you ever rename the server or move mail to a different IP, update the PTR and the A record together — not one and then "later" the other.
• Recheck after migrations. Moving to a new VPS or a new SkyServer plan usually means a new IP. Reverse DNS doesn't migrate automatically — it has to be requested fresh for the new address.
• Monitor, don't just set-and-forget. Add a PTR/FCrDNS check to whatever uptime or deliverability monitoring you already run, so a provider-side reset or IP change doesn't silently break outbound mail.

Frequently Asked Questions

Can I set a PTR record myself in cPanel's Zone Editor?

No. cPanel's Zone Editor manages your domain's forward DNS (A, MX, TXT, etc.). PTR records live in the reverse-lookup zone tied to the IP address, which is controlled by whoever owns that IP block — your VPS or cloud provider. On SkyServer VPS/Cloud plans, open a support ticket with the IP and the hostname you want.

Do I need a PTR record if I send mail through a third-party service like SendGrid or Mailgun?

Not for that traffic — the third-party service's IPs already have their own PTR/reputation setup. PTR matters specifically when your VPS itself is the machine doing the SMTP handshake (Postfix, Exim, a self-hosted mail queue).

My PTR resolves to the provider's default hostname — is that a problem?

It can be. Receiving servers don't strictly require the PTR hostname to contain your domain name, but many spam filters score generic/default hostnames (like 123-45-67-89.provider.net) worse than a proper mail.yourdomain.com, especially combined with a failed forward-confirmation check.

How long does it take for a new PTR record to work?

Usually minutes to a couple of hours once your provider applies it — much faster than typical domain DNS propagation, since there's no registrar-side TTL involved. If it's still not resolving after several hours, follow up with your provider; it may not have been applied correctly.

I fixed the PTR but mail is still going to spam — what else could it be?

PTR is one signal among several. Double-check SPF/DKIM/DMARC actually pass (not just exist), confirm your IP isn't on a blacklist via a tool like MXToolbox, and review recent sending volume and content — a sudden spike or spammy-looking content can outweigh a clean PTR on its own.