Reverse DNS / PTR Records — Why Mail Delivery Needs Them

Forward DNS turns a domain into an IP address (yourdomain.com → 192.0.2.1). Reverse DNS does the opposite — IP into a domain (192.0.2.1 → mail.yourdomain.com). For most services this is invisible. For mail, it’s critical: receiving mail servers reject mail from IPs without proper reverse DNS, or with generic-looking reverse DNS. This guide explains what PTR records are, why they matter, and how to request one on iWebVault.

What a PTR record actually is

A PTR (Pointer) record lives in a special DNS zone for IP-to-name lookups. For IPv4 address 192.0.2.1, the PTR record is at 1.2.0.192.in-addr.arpa (note the IP reversed) and points to a hostname.

Unlike forward DNS records (which you control via your registrar / DNS panel), PTR records are owned by whoever owns the IP block. For your iWebVault VPS or dedicated, that’s iWebVault — we set PTR records on request because the IPs belong to us.

Why mail needs reverse DNS

Receiving mail servers do this check on every incoming connection:

1. They see a connection from IP 192.0.2.1.
2. They look up its PTR record. Sees mail.yourdomain.com.
3. They look up the A record for mail.yourdomain.com. Sees 192.0.2.1.
4. Both directions match — accept the connection.

If PTR doesn’t exist, or PTR shows something generic like 192-0-2-1.iwebvault.com, or forward and reverse don’t match — many receivers reject the mail outright. Gmail, Microsoft, and other major mail providers do this check.

Without proper PTR:

• Mail to Gmail/Outlook goes to spam or bounces.
• Mail to corporate mail servers (Microsoft 365, Google Workspace) often rejected.
• Some receivers reject with “554 Reverse DNS check failed” or similar.

This is one of the single most-overlooked causes of “my server can’t send mail reliably.”

Checking your current PTR

On any machine:

dig -x 192.0.2.1
# OR
nslookup 192.0.2.1

(Replace 192.0.2.1 with your actual server IP.)

The output shows the PTR record. Good responses look like:

;; ANSWER SECTION:
1.2.0.192.in-addr.arpa.   3600   IN   PTR   mail.yourdomain.com.

Problematic responses:

• No PTR record returned.
• Generic provider hostname (192-0-2-1.iwebvault.com or similar).
• Hostname that doesn’t match your forward DNS.

Requesting a PTR record

1. Pick the desired hostname. Convention is mail.yourdomain.com for mail-sending servers. Make sure forward DNS for that hostname points at the IP — without forward DNS matching, the PTR is useless.
2. Verify forward DNS: dig mail.yourdomain.com → should return your server IP.
3. Open a support ticket. Subject: “PTR / Reverse DNS request”. Include:
   • Server IP.
   • Desired hostname.
   • Confirmation that forward DNS is already set.
4. We update the PTR — usually within hours.
5. Verify: dig -x your-ip — should show your hostname.

Setting forward DNS first (important order)

PTR alone isn’t enough. You need:

• A record: mail.yourdomain.com → your-ip.
• PTR record: your-ip → mail.yourdomain.com.
• Both matching.

Add the A record at your DNS provider (Cloudflare, iWebVault DNS, registrar). Wait for propagation. Then request PTR. This order ensures both directions resolve when we set the PTR.

PTR for multiple IPs / multiple domains

If your VPS has multiple IPs, each can have its own PTR. Common patterns:

• Mail server with dedicated IP: that IP has PTR pointing to mail.yourdomain.com.
• Multiple sites on one IP: PTR points to one hostname (typically the primary site’s mail subdomain).

For high-volume mail sending across multiple domains, dedicating an IP per major sender domain improves deliverability — each IP can have a PTR matching the sender domain.

PTR and Cloudflare

Cloudflare proxying doesn’t affect PTR. Forward DNS for mail.yourdomain.com must NOT be proxied (grey cloud) so it returns your origin IP directly — mail can’t be proxied through Cloudflare anyway.

Public-facing services like the web (www) can be proxied; mail subdomain must be DNS-only.

PTR vs. HELO / EHLO

When your mail server connects to deliver mail, it announces itself with HELO/EHLO (a hostname). Receivers often check this matches the PTR. Mismatch can cause rejection.

Configure your mail server (Postfix, Exim, whatever) to use the same hostname in HELO as its PTR resolves to. In Postfix:

# /etc/postfix/main.cf
myhostname = mail.yourdomain.com

For Exim, set primary_hostname to the same value. Restart the mail service after changes.

The full deliverability stack

PTR is one of several requirements for good mail deliverability. The full set:

• Matching PTR ↔ forward DNS. This article.
• SPF, DKIM, DMARC. Authentication guide.
• Clean IP reputation. New IPs need warming up; previously-spammed IPs may have lingering blocklist issues.
• HELO/EHLO hostname matching PTR. Mail server config.
• Not sending excessive volume from a new IP. Gradual ramp-up.

PTR alone won’t make a poorly-configured mail server reliable, but missing PTR will block even a perfectly-configured one.

Common PTR questions

“Mail goes to spam even with proper PTR set.” PTR is necessary but not sufficient. Verify SPF/DKIM/DMARC too. Check IP reputation at mxtoolbox.com/blacklists.aspx.

“Can I have multiple PTRs on one IP?” Technically yes, but receivers handle multiple PTRs inconsistently. Stick with one PTR per IP.

“PTR set but reverse DNS lookup still shows old hostname.” DNS caching. Wait an hour or more for propagation. Verify with dig -x ip @8.8.8.8 (against Google DNS) — if Google shows the new value, propagation is working.

“Do I need PTR if I’m not running my own mail server?” If your VPS doesn’t send mail directly (uses external SMTP relay like SendGrid, Brevo, Mailgun), PTR is less critical — the relay’s PTR is what matters then. But it’s still worth having for any server that might send mail (cron job notifications, error reports, etc.).

“How long does PTR change take to propagate?” Variable. The TTL on PTR zones is set by the IP block owner (us). Usually 1-4 hours for full propagation.

What’s next

• Email authentication: SPF, DKIM, DMARC setup.
• Why mail might still go to spam after PTR fix: Deliverability guide.
• Mail logs and bounces: Reading mail logs.

PTR is one of those tiny configuration items with outsized impact. Five minutes of work, dramatic improvement in mail deliverability for any server sending mail directly. Set it up on every mail-sending VPS — don’t wait for “mysterious” deliverability problems to surface.