PTR Record Missing? Fix VPS Mail Getting Rejected

You set up SPF, DKIM, and DMARC exactly like the checklist said, but mail from your VPS still bounces or lands in spam — especially to Gmail, Outlook, and Yahoo addresses. If that's you, the missing piece usually isn't your domain's DNS at all. It's the reverse DNS record on the server's IP address, and almost nobody sets it up until mail starts failing.

Symptom: mail from your VPS gets rejected or flagged

This shows up in a few different ways, depending on the receiving server:

• Outgoing mail from Postfix/Exim bounces with something like 550 5.7.1 Client host rejected: cannot find your reverse hostname
• Gmail defers or rejects with 421-4.7.0 [TS01] Messages from x.x.x.x temporarily rate limited or flags you as spam even though SPF/DKIM/DMARC all pass
• Mail-tester.com or MXToolbox gives you a low score and specifically calls out "no PTR record" or "reverse DNS mismatch"
• Your own mail server logs show the connection being dropped before your SPF/DKIM records are even checked

The tell-tale sign: you've verified SPF, DKIM, and DMARC pass with dig txt yourdomain.com, and everything looks fine, but delivery still fails. That's your cue to check reverse DNS next.

Cause: forward DNS and reverse DNS are two different things

Your domain's A record points a hostname to an IP — that's forward DNS, and it lives in your zone file (cPanel Zone Editor, Cloudflare, wherever your nameservers are). Reverse DNS does the opposite: it maps an IP address back to a hostname, using a special PTR record. Crucially, you don't control this from your domain's DNS zone at all — it's tied to the IP address block, which means it's controlled by whoever owns that IP: your VPS or hosting provider.

When another mail server receives a connection from your VPS, most spam filters do a reverse lookup on your IP, then a forward lookup on whatever hostname comes back, and check that the two match and resolve to something sane. If:

• the PTR record doesn't exist at all (common on fresh VPS instances), or
• it points to a generic hostname like 123-45-67-89.your-provider.net instead of your mail domain, or
• it doesn't match the hostname your mail server announces in its HELO/EHLO greeting

…plenty of receiving servers treat that as a strong spam signal, sometimes strong enough to reject the connection outright before your message body is even read.

Fix: set the PTR record and match it on the server

This is a two-sided fix — one change with your hosting provider, one change on the VPS itself. Both need to agree.

Step 1: Check what your current PTR record says

From any machine with a terminal, run:

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

Or, if dig isn't installed:

host YOUR.SERVER.IP.ADDRESS

If this returns nothing, or returns your provider's generic hostname instead of something like mail.yourdomain.com, that's the problem.

Step 2: Decide what hostname you want the PTR to resolve to

Pick one hostname to be the server's canonical identity — usually mail.yourdomain.com or server1.yourdomain.com. Before requesting the PTR change, make sure this hostname already has a matching A record pointing back to the same IP. PTR without a matching forward record is exactly the mismatch spam filters flag.

Step 3: Request the PTR record from Getwebup (or your VPS provider)

PTR records live in the reverse DNS zone for the IP block, which only the IP's owner can edit. On a Getwebup VPS, open a support ticket (or use the reverse DNS option in your VPS control panel, if your plan exposes one) and ask for:

YOUR.SERVER.IP.ADDRESS  ->  mail.yourdomain.com

This is a quick change on our end, but it isn't instant — give it a few hours to propagate before you re-test.

Step 4: Match the hostname on the server itself

The PTR record alone isn't enough. Your mail server has to introduce itself with the same hostname, or you've just moved the mismatch instead of fixing it. On Ubuntu/Debian:

sudo hostnamectl set-hostname mail.yourdomain.com
sudo nano /etc/hosts
# make sure this line exists:
# 127.0.1.1   mail.yourdomain.com mail

If you're running Postfix, confirm it's using that hostname for its greeting:

sudo postconf myhostname
# should print: myhostname = mail.yourdomain.com

If it doesn't, edit /etc/postfix/main.cf, set myhostname = mail.yourdomain.com, then restart:

sudo systemctl restart postfix

For Exim (common on cPanel servers), the equivalent is the primary_hostname setting, usually already synced to the server's hostname — but it's worth checking under WHM → Exim Configuration Manager → Basic Editor if you've renamed the server recently.

Step 5: Verify everything lines up

Once the PTR has propagated, check both directions:

dig -x YOUR.SERVER.IP.ADDRESS +short
# should return: mail.yourdomain.com.

dig A mail.yourdomain.com +short
# should return: YOUR.SERVER.IP.ADDRESS

Then send a test email to mail-tester.com and check the report. If PTR was your last blocker, you'll usually see the score jump straight away, and the "reverse DNS" line will show green instead of a warning.

Prevention: bake this into your server setup checklist

If you're spinning up a new VPS to send mail from — a transactional mail server, a self-hosted helpdesk, a WooCommerce store sending order confirmations directly instead of through a relay — add PTR configuration to day one, not after your first bounce. A few habits that keep this from becoming a recurring fire drill:

• Set the PTR record and matching hostname before you install your mail stack, not after
• Keep a single canonical hostname for the server; don't rename it later without re-checking PTR and Postfix/Exim config together
• If you migrate to a new IP (new VPS, new provider, IP change after a plan upgrade), treat PTR as part of the migration checklist — it does not follow the domain automatically
• For anything beyond low-volume transactional mail, consider relaying through a dedicated email API (SES, Mailgun, Postmark) instead of sending directly from the VPS — you get PTR, SPF, and warmed-up sending reputation handled for you

Reverse DNS is one of those settings nobody thinks about until deliverability breaks, but it's a five-minute fix once you know where to look — and unlike SPF or DKIM, it's the one record you can't set yourself from your domain's DNS zone.