Back to tutorials
Tutorial

rDNS Setup Tutorial (2026): Configure Reverse DNS for a VPS to Fix Email Deliverability and HELO Errors

rDNS setup tutorial for 2026: set reverse DNS on your VPS, verify PTR, and stop common mail rejections and HELO errors.

By Anurag Singh
Updated on Aug 30, 2026
Category: Tutorial
Share article
rDNS Setup Tutorial (2026): Configure Reverse DNS for a VPS to Fix Email Deliverability and HELO Errors

Email deliverability problems often show up as “SPF failed” or “blocked by policy.” Sometimes the fix is simpler: your sending IP has no reverse DNS. This rDNS setup tutorial shows how to set a PTR record for a VPS. Then you’ll verify it end-to-end so common HELO/PTR checks stop rejecting your mail.

The workflow is the same whether you run Postfix, Exim (cPanel), or send via a WordPress SMTP plugin. First, identify the real outbound IP. Next, set reverse DNS at your provider. Finally, align forward DNS, HELO, and authentication so your server stops looking “unknown” to receiving systems.

What you’ll set up (and why mail servers care)

Reverse DNS (rDNS) maps an IP address back to a hostname using a PTR record. Many receiving MTAs (and anti-spam gateways) expect three things:

  • Your sending IP has a PTR record (IP → hostname).
  • That hostname resolves back to the same IP (hostname → A record). This is called forward-confirmed reverse DNS (FCrDNS).
  • Your server’s SMTP greeting/HELO uses a stable hostname that also resolves correctly.

If any link in that chain is missing, you’ll see rejections like these:

  • 450 4.7.1 Client host rejected: cannot find your reverse hostname
  • 550 5.7.1 Reverse DNS required
  • 521 5.2.1 Message rejected due to local policy (often masking PTR/HELO issues)

Prerequisites checklist (5 minutes)

  • A VPS or dedicated server with a static public IPv4 (and/or IPv6) address.
  • Control over your domain’s DNS (where you can create A/AAAA, SPF, DKIM, DMARC).
  • The hostname you want to use for mail, such as mail.example.com.
  • Root access to the server (or WHM access if you’re on cPanel).

If you need a stable IP and full DNS control, start with a HostMyCode VPS. A consistent PTR helps avoid churn that can hurt outbound reputation.

Step 1: Find your outbound sending IP (don’t guess)

If your server has multiple IPs, set rDNS on the IP that actually sends mail.

  1. Check your public IP from the server:

    curl -4 https://ifconfig.co
curl -6 https://ifconfig.co

  2. If you’re on cPanel/WHM, confirm the “main” outgoing IP:

    • WHM → Server Configuration → Basic WebHost Manager Setup
    • Look for Main Shared Virtual Host IP and the hostname section

  3. On Postfix, check whether you’ve pinned a specific source IP:

    postconf -n | egrep 'smtp_bind_address|inet_interfaces'

Pitfall: If you relay mail through a third-party SMTP provider, rDNS on your VPS won’t change deliverability. Recipients see the relay’s IP. If you’re not sure which system is sending, read this SMTP relay setup guide first.

Step 2: Choose a PTR hostname that makes sense

Pick a hostname you control. Common choices include:

  • mail.example.com (most common)
  • smtp.example.com
  • vps123.example.com (works, just less “brand clean”)

Avoid PTRs that point to a generic ISP hostname, random strings, or a domain you don’t use for mail. Many filters treat those patterns as higher risk.

Step 3: Create the forward DNS record (A/AAAA) first

Set forward DNS before you touch the PTR. That way, FCrDNS can pass as soon as reverse DNS propagates.

  1. Create an A record in your DNS zone:

    mail.example.com.   3600   IN   A      203.0.113.10

  2. If you use IPv6 for mail, also add AAAA:

    mail.example.com.   3600   IN   AAAA   2001:db8::10

If you’re planning a cutover, lower the TTL ahead of time so changes move quickly. HostMyCode’s walkthrough is here: DNS TTL reduction tutorial (2026).

Step 4: Set reverse DNS (PTR) at the VPS provider

PTR records live in the reverse DNS zone for the IP block. The IP owner controls that zone. That’s usually your VPS provider, not your domain’s DNS host.

In most hosting panels, you’ll see a “Reverse DNS / PTR” field per IP. Set it to the hostname you chose:

  • IPv4 PTR: 203.0.113.10 → mail.example.com
  • IPv6 PTR: 2001:db8::10 → mail.example.com

Important: The PTR value must be a hostname (FQDN), not an IP. It should not be a CNAME.

Step 5: Verify PTR, forward DNS, and FCrDNS from multiple resolvers

Don’t stop after one green checkmark. Confirm the full chain with at least two resolvers.

Check PTR

IPV4="203.0.113.10"
dig +short -x "$IPV4"

Expected output:

mail.example.com.

Check forward A/AAAA

dig +short mail.example.com A
dig +short mail.example.com AAAA

Check FCrDNS (PTR → hostname → A matches original IP)

HOST=$(dig +short -x 203.0.113.10 | head -n1)
dig +short "$HOST" A

The A lookup should return 203.0.113.10. If it returns a different address, fix the A record. Or change the PTR to the hostname that matches the sending IP.

Cross-check with public DNS

dig @1.1.1.1 +short -x 203.0.113.10
dig @8.8.8.8 +short mail.example.com A

Quick diagnostic: If one resolver shows the new record and another doesn’t, you’re seeing caching or propagation. Next time, lower TTL before changes.

Step 6: Align the server’s hostname and SMTP HELO/EHLO

Errors like “HELO does not match PTR” usually point to one issue. Your server greets with a hostname that doesn’t resolve cleanly, or it doesn’t match what rDNS points to.

Make the name your MTA presents consistent and resolvable.

Ubuntu/Debian (system hostname)

sudo hostnamectl set-hostname mail.example.com

Confirm:

hostname -f
hostnamectl

Postfix: set a proper myhostname

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

Verify the banner/HELO from another machine:

openssl s_client -starttls smtp -crlf -connect mail.example.com:587
EHLO test.example
QUIT

cPanel/WHM: set hostname correctly

  • WHM → Networking Setup → Change Hostname
  • Set it to the same FQDN you used for PTR (for example, mail.example.com)

If you later see certificate mismatch warnings on mail services, keep using a dedicated mail hostname. Then issue a matching SSL certificate (AutoSSL or Let’s Encrypt).

For renewal problems, see SSL renewal troubleshooting.

Step 7: Add SPF, DKIM, and DMARC so rDNS isn’t your only signal

PTR helps you clear basic policy gates. Authentication keeps mail out of spam folders.

If you send directly from your VPS IP, publish all three records.

SPF (basic, direct-from-server example)

Create a TXT record for the root domain:

example.com.  3600  IN  TXT  "v=spf1 a mx ip4:203.0.113.10 -all"

If you also send through a relay provider, include their mechanism instead of (or alongside) the IP.

DKIM (recommended for any serious sending)

DKIM setup depends on your stack. For Postfix + OpenDKIM, follow: DKIM setup tutorial (2026).

DMARC (start with monitoring)

_dmarc.example.com. 3600 IN TXT "v=DMARC1; p=none; rua=mailto:dmarc-reports@example.com; adkim=s; aspf=s"

After a week of clean reports, move to p=quarantine. Consider p=reject only after you’re confident every sender is authenticated and aligned.

Step 8: Test deliverability and watch logs (so you can prove the fix)

Once PTR and HELO are correct, acceptance often improves right away. Send a real test message. Then read your logs and review the remote response codes.

Postfix logs (Ubuntu/Debian)

sudo journalctl -u postfix -n 200 --no-pager

Or if you log to files:

sudo tail -n 200 /var/log/mail.log

Common “still failing” messages and what they mean

  • “No PTR record”: PTR isn’t set on the right IP, or outbound mail is leaving on a different IP than you expect.
  • “Hostname does not resolve”: the PTR hostname has no A/AAAA record.
  • “HELO/EHLO invalid”: Postfix myhostname or the cPanel hostname is wrong, or the server is greeting with a non-FQDN.
  • “TLS required”: you need a valid cert on 587/465 (not an rDNS issue).
  • “Blocked using IP reputation”: rDNS won’t undo a bad reputation by itself; you’ll need cleanup and better sending practices.

If you’re seeing 550/554 bounces, use this guide to decode them quickly: email bounce troubleshooting.

Troubleshooting: quick fixes for the most common rDNS mistakes

Mismatch between PTR hostname and A record

  • Symptom: PTR returns mail.example.com but mail.example.com points to a different IP.
  • Fix: update the A record to match the sending IP (or change PTR to the correct hostname).

Using the root domain as PTR

  • Symptom: PTR points to example.com but your SMTP banner is mail.example.com.
  • Fix: choose one hostname and use it everywhere. A dedicated mail hostname is usually cleaner.

PTR set, but mail still rejected

  • Symptom: PTR checks pass, but you still get policy bounces.
  • Fix: verify SPF/DKIM/DMARC alignment, ensure your From domain matches authenticated domains, and confirm you’re not on a blacklist.

IPv6 surprises

  • Symptom: You set IPv4 PTR but your server prefers IPv6 and remote checks the IPv6 PTR.
  • Fix: set IPv6 PTR too, or configure your MTA to prefer IPv4 for outbound mail if IPv6 isn’t fully configured.

Operational checklist (print this before you migrate or rebuild)

  • Decide mail hostname (FQDN): mail.example.com
  • Create A (and AAAA if used) for that hostname to your outbound mail IP
  • Set PTR on the outbound IP to that hostname (provider side)
  • Verify PTR: dig -x
  • Verify forward lookup returns same IP
  • Set server hostname / Postfix myhostname / WHM hostname to match
  • Enable TLS with a valid certificate for mail hostname
  • Publish SPF, DKIM, DMARC
  • Send test mail and confirm logs show clean acceptance

Summary: a clean rDNS setup that survives real-world hosting

Reverse DNS isn’t optional on a mail-sending VPS. It’s one of the fastest ways to remove basic SMTP policy rejections, especially after a migration or an IP change.

Set the PTR, make sure forward DNS matches, and use a sensible HELO name. You’ll remove an entire class of avoidable deliverability failures.

If you’re rebuilding mail on a new node or moving customers between servers, pair this with a controlled migration plan. This guide walks through a cutover with rollback: server migration tutorial (2026).

For stable IPs, predictable networking, and hosting-friendly defaults, run your mail stack on a managed VPS hosting plan. Move to dedicated hardware if you’re sending for many domains.

Outbound email works best with a stable IP and a provider who can apply reverse DNS changes quickly. Start with a HostMyCode VPS, or choose managed VPS hosting if you want an admin to handle the mail-ready basics (hostname, SSL, rDNS validation) alongside you.

FAQ

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

Often 15–60 minutes, but caching varies. Verify with at least two resolvers (1.1.1.1 and 8.8.8.8). Repeat checks until both show the new PTR.

Can I set PTR in my domain’s DNS zone?

No. PTR lives in the IP’s reverse zone, which is controlled by the IP owner (usually your VPS provider). You can only set it yourself if your provider delegates reverse DNS to you.

Should PTR match the domain I send “From”?

It doesn’t have to. It should be a hostname you control, and it must resolve to your sending IP. Deliverability improves when your identity stays consistent across PTR, HELO, SPF, and DKIM.

Do I need rDNS if I send WordPress mail through an SMTP relay?

Not for deliverability, because the relay’s IP reputation and rDNS are what receivers see. You still want correct DNS for your domain (SPF/DKIM/DMARC), but PTR on your VPS won’t be the deciding factor.

What’s the fastest way to confirm rDNS is the problem?

Check dig -x for your sending IP. If it returns nothing (NXDOMAIN), or it returns a hostname that doesn’t resolve back to the same IP, fix rDNS and forward DNS first. Then move on to SPF or content issues.