Most outbound email failures on a new VPS aren’t caused by “bad content.” They usually come from identity gaps. Common causes include: no PTR, a hostname that doesn’t match your IP, missing SPF/DKIM/DMARC, or a HELO name that doesn’t exist in DNS.
This reverse DNS setup tutorial shows you how to set a correct PTR record (rDNS), align it with forward DNS (FCrDNS), and verify everything before you send anything important.
The examples assume an Ubuntu/Debian-style VPS running Postfix (common on custom stacks). They also cover control-panel servers (cPanel/WHM, Plesk, DirectAdmin).
The target state is the same in every case.
Your mail server uses a hostname that resolves to your IP. That IP reverse-resolves back to the same hostname.
What you’ll set up (and why mail providers care)
Reverse DNS (PTR) maps an IP address back to a hostname. Receiving servers use it as a quick legitimacy check.
If your server connects from 203.0.113.10 and says “HELO mail.example.com”, providers typically verify:
- PTR: Does
203.0.113.10reverse tomail.example.com(or at least a stable hostname you control)? - A record: Does
mail.example.comresolve to203.0.113.10? - FCrDNS: Does forward-then-reverse (or reverse-then-forward) match cleanly?
If those checks don’t line up, you’ll often see Gmail deferrals. Microsoft 365 may accept but junk the message.
You may also get bounces like “Reverse DNS required” and “rDNS missing.”
Prerequisites checklist (5 minutes)
- A VPS or dedicated server with a static IPv4 (or static IPv6). Dynamic IPs are a non-starter for reliable sending.
- A domain you control (example:
example.com). - A chosen mail hostname (recommendation:
mail.example.com). - SSH access (root or sudo).
If you’re still choosing infrastructure, start with a VPS where IP ownership and rDNS requests are straightforward.
A HostMyCode VPS works well for mail + web stacks where you control hostname, rDNS requests, and firewall policy.
Step 1 — Pick the correct mail hostname (don’t use your bare domain)
Use a dedicated hostname like mail.example.com or smtp.example.com. Avoid:
example.comas the mail hostname (it often points to your website/CDN).- Provider-default hostnames (they rarely match your DNS and can fail strict checks).
Keep the name simple and consistent.
Use the same FQDN for your server hostname, PTR, forward DNS, and your MTA’s HELO/EHLO.
Step 2 — Set your server hostname (Ubuntu/Debian)
On Ubuntu 24.04 LTS / Debian 12 (common in 2026 hosting stacks), set a fully-qualified domain name (FQDN):
sudo hostnamectl set-hostname mail.example.com
hostnamectlThen confirm /etc/hosts isn’t misleading. A typical setup looks like:
127.0.0.1 localhost
127.0.1.1 mail.example.com mail
# Optional: your public IP mapping is fine too, but not required here
# 203.0.113.10 mail.example.com mailPitfall: don’t let your MTA announce a public hostname that points somewhere else in public DNS.
In most VPS setups, local name resolution can stay local.
Public DNS should remain the source of truth for receivers.
Step 3 — Create forward DNS (A/AAAA) for your mail hostname
In the DNS zone for example.com, add:
- A:
mail.example.com→203.0.113.10 - AAAA (if you send over IPv6):
mail.example.com→2001:db8::10
If you’re unsure about IPv6, don’t publish AAAA yet.
A broken IPv6 path can create confusing, intermittent delivery delays.
DNS changes are easier to manage when you plan TTL and rollback.
If you’re moving services during the same window, pair this with: DNS cutover tutorial for low-downtime changes.
Step 4 — Request/Configure the PTR record (reverse DNS setup tutorial core step)
You usually can’t set PTR from your domain’s DNS provider.
PTR is controlled by whoever owns the IP block (your hosting provider).
Your PTR record should map your IP back to your mail hostname:
203.0.113.10→mail.example.com
What to submit in a support ticket:
- IP address:
203.0.113.10 - Desired PTR:
mail.example.com - Confirm you already created the forward A record for
mail.example.com→203.0.113.10
PTR rules that prevent problems:
- Use a hostname you control in DNS (not an arbitrary label).
- Use one stable PTR per sending IP.
- Don’t point PTR to a CNAME target; use a straightforward FQDN with an A/AAAA.
Step 5 — Verify rDNS + FCrDNS from your workstation
Give your provider time to apply rDNS (often minutes, sometimes a few hours).
Verify from a machine outside your VPS network.
This avoids getting fooled by local caching or split-horizon DNS.
Check PTR
dig -x 203.0.113.10 +shortExpected output:
mail.example.com.Check forward A/AAAA
dig mail.example.com A +short
dig mail.example.com AAAA +shortConfirm forward-confirmed reverse DNS (FCrDNS)
FCrDNS means “PTR resolves to a name, and that name resolves back to the same IP.”
A quick manual check:
- PTR:
dig -x 203.0.113.10 +short→mail.example.com - Forward:
dig mail.example.com A +short→203.0.113.10
If you get multiple A records, remember that some receivers treat that as suspicious for small senders.
For a single VPS, keep it 1:1.
Step 6 — Make Postfix announce the right name (HELO/EHLO)
rDNS can be perfect and you can still fail checks.
This happens when your MTA announces a different hostname during SMTP.
On Postfix, inspect what it will use:
sudo postconf myhostname mydomain smtp_helo_nameRecommended baseline for a single-host sender:
sudo postconf -e "myhostname = mail.example.com"
sudo postconf -e "mydomain = example.com"
# Optional but explicit:
sudo postconf -e "smtp_helo_name = mail.example.com"
sudo systemctl restart postfixQuick live test: Use OpenSSL to confirm what your server presents during SMTP (replace IP):
openssl s_client -starttls smtp -connect 203.0.113.10:587 -crlfYou want a clean banner and no obvious TLS name mismatch.
If port 587 isn’t reachable, fix firewall/service first.
If you need a safer way to reach mail/admin ports without leaving them open to the internet, use: SSH port forwarding tutorial for cPanel/webmail ports.
Step 7 — Open only the mail ports you actually use (UFW example)
Mail deliverability and mail security move together.
“Temporary” firewall rules tend to become permanent. That’s how servers get abused.
Typical required inbound ports for a VPS that both sends and receives mail:
- 25/tcp SMTP (server-to-server receiving)
- 587/tcp Submission (client sending with auth)
- 993/tcp IMAPS (if you host mailboxes)
With UFW:
sudo ufw allow 22/tcp
sudo ufw allow 25/tcp
sudo ufw allow 587/tcp
sudo ufw allow 993/tcp
sudo ufw statusIf you’re tightening a hosting VPS and want a checklist that won’t accidentally lock you out, use: UFW firewall setup tutorial.
Step 8 — Align SPF, DKIM, DMARC, and PTR (minimum viable deliverability)
PTR won’t “earn” deliverability by itself.
It mainly removes an easy reason to distrust your mail.
For basic alignment in 2026, you want:
- SPF to authorize your sending IP(s)
- DKIM to cryptographically sign outgoing messages
- DMARC to publish your policy and reporting mailbox
- PTR to match your mail hostname, plus FCrDNS
HostMyCode has a dedicated hands-on guide for the auth records and PTR considerations: Email authentication setup guide (SPF/DKIM/DMARC & PTR).
A sequencing that keeps you from chasing your tail:
- Set hostname + forward A record
- Apply PTR
- Verify FCrDNS
- Then publish SPF/DKIM/DMARC
Step 9 — Validate from the VPS (nameserver view can differ)
Resolvers don’t always agree.
Your laptop may see the “new” DNS while your VPS still sees cached results. It may also be using a different recursive resolver.
On the server, query a known resolver like Cloudflare (1.1.1.1) or Google (8.8.8.8).
# Forward lookup using a specific resolver
dig @1.1.1.1 mail.example.com A +short
# Reverse lookup using a specific resolver
dig @1.1.1.1 -x 203.0.113.10 +shortIf results don’t match what you expect, confirm you edited the correct zone.
Also confirm your domain uses the nameservers you think it does.
If everything is correct, wait for TTLs to age out.
Step 10 — Troubleshoot common PTR/rDNS failure modes
These issues usually burn the most time during migrations and first-time mail setups.
1) PTR points to a hostname that doesn’t exist
Symptom: dig -x returns a name, but dig mail.example.com A returns nothing.
Fix: Create the A record for that hostname (or change PTR to match an existing hostname you control).
2) Hostname resolves to a different IP than the sending IP
Symptom: PTR says mail.example.com, but mail.example.com resolves to your CDN or another server.
Fix: Use a dedicated mail hostname that isn’t shared with web. Point it directly at the sending IP.
3) Multiple PTR records (rare, but ugly)
Symptom: Reverse lookup returns multiple names.
Fix: Ask your provider to keep only one PTR for the IP. Keep that name stable.
4) IPv6 deliverability is flaky
Symptom: Some providers accept mail, others defer; logs show IPv6 connections failing.
Fix: Either fully configure IPv6 (AAAA + IPv6 PTR + open ports + correct Postfix inet_protocols), or temporarily disable IPv6 sending until it’s correct.
5) HELO mismatch even though PTR is correct
Symptom: Bounce mentions “HELO name invalid” or “hostname does not resolve”.
Fix: Set Postfix myhostname / smtp_helo_name to the exact mail hostname used in PTR and forward DNS.
6) Port 25 blocked by upstream network policy
Some environments restrict outbound SMTP on port 25.
If your queue grows or external delivery stalls, test outbound connectivity:
nc -vz gmail-smtp-in.l.google.com 25If it’s blocked, you’ll need provider unblocking or a smart host relay. For cPanel-specific relay routing, see: cPanel SMTP relay setup tutorial.
Step 11 — Control panel notes (cPanel/WHM, Plesk, DirectAdmin)
Panels can automate parts of mail configuration. They won’t solve rDNS for you.
PTR still lives with the IP owner.
cPanel/WHM
- Set the server hostname in WHM: Networking Setup → Change Hostname.
- Ensure the hostname has a valid A record in DNS.
- After PTR is applied, run a quick AutoSSL check if you host webmail/panel over the same hostname.
If you’re running cPanel in production, do rDNS work alongside basic hardening.
A compromised server loses mail reputation quickly: cPanel security hardening tutorial.
Plesk / DirectAdmin (general)
- Set the panel/server hostname to the same FQDN you use for PTR.
- Confirm the panel’s mail service uses that name in SMTP greetings.
- Keep web and mail hostnames separate if your web sits behind a proxy/CDN.
Step 12 — Check logs: prove the change fixed delivery
Don’t rely on guesswork.
Send a test message to mailboxes you control (Gmail, Outlook.com, and a corporate domain if you can).
Then check what your server actually did.
On Ubuntu/Debian with Postfix:
sudo journalctl -u postfix --since "30 minutes ago" --no-pager
# or classic log file if enabled
sudo tail -n 200 /var/log/mail.logWhat you want to see:
- Clean TLS negotiation (no certificate name errors if you use STARTTLS)
- Successful relay: status=sent, 250 accepted
- No repeated deferrals citing rDNS/PTR/HELO
Operational checklist (keep this as your runbook)
- [ ] Chosen mail hostname:
mail.example.com - [ ] Server hostname set to the same FQDN
- [ ] Forward DNS A record exists and matches the sending IP
- [ ] PTR record set to the same FQDN
- [ ] FCrDNS verified (PTR ↔ A match)
- [ ] Postfix (or panel MTA) uses the same HELO/EHLO name
- [ ] Firewall allows required ports only
- [ ] SPF/DKIM/DMARC published and aligned
- [ ] Test emails delivered to inbox (not just “accepted”)
Summary: treat PTR as a baseline, not a bonus
PTR and FCrDNS are basic identity checks.
Set them early, confirm them from more than one resolver, and keep them stable.
Once rDNS is clean, you’ll spend less time chasing “mysterious” bounces.
You can then focus on what actually moves deliverability: list hygiene, steady sending patterns, and sensible content.
If you’re building a mail-capable hosting stack and want predictable networking and admin control, start on a HostMyCode VPS.
If you’d rather offload patching and core server maintenance, managed VPS hosting is the cleaner route for business-critical email.
Need a stable server foundation for email and web hosting in 2026? HostMyCode runs mail-friendly VPS and managed plans built for clean DNS, predictable IPs, and day-to-day admin work that doesn’t fight you. Start with a HostMyCode VPS, or choose managed VPS hosting if you want help keeping the stack secure and updated.
FAQ
How long does it take for a PTR record change to work?
Often minutes, sometimes a few hours. Reverse DNS caching varies by resolver.
Verify using dig -x against multiple resolvers (for example @1.1.1.1 and @8.8.8.8).
Can I set PTR records from my DNS provider (like I set A records)?
Usually no. PTR is controlled by the organization that owns the IP range. You request it from your VPS/dedicated server provider.
Do I need PTR for inbound mail, outbound mail, or both?
Outbound matters most. Receiving servers commonly score or reject mail if the sending IP has missing or inconsistent rDNS.
Inbound mail can still function without PTR, but you’ll have trouble sending replies reliably.
Should I use the same hostname for my website and mail?
It’s safer not to. Websites often sit behind CDNs, load balancers, or change IPs. Mail identity wants a stable 1:1 mapping.
Use www.example.com for web and mail.example.com for mail.
My PTR is correct but messages still land in spam. What next?
Check SPF/DKIM/DMARC alignment, sending volume patterns, and whether your IP/domain is listed on common blocklists.
Also confirm your server isn’t relaying spam and that TLS is working on submission (587). For deeper mail routing issues, see email routing troubleshooting.