Why mail servers need PTR records (and how to set one up)
// published 2026-04-17
Missing or mismatched PTR records (reverse DNS) is the #1 reason legitimate mail gets scored as spam. Almost every major receiver — Gmail, Microsoft 365, Yahoo, corporate filters — does an rDNS check during the SMTP handshake. Fail it and you're already at -3 spam points before anyone reads the message.
What PTR records do
A normal DNS lookup goes name → IP. PTR is the reverse: IP → name. When a mail server connects to deliver a message, the receiver records the source IP. Then it does a PTR lookup on that IP. The result is supposed to be a hostname that "owns" the IP — typically the actual mail server hostname.
Receivers then often do a forward-confirmed reverse DNS (FCrDNS) check: take the PTR result, look up its A record, see if it matches the original IP. If yes — verified. If not — something's off.
Why receivers care
Spammers run on hijacked residential connections, compromised IoT, or hastily-rented VPS. They don't have time to configure PTR for each new IP. Lack of PTR is a near-perfect signal of abuse.
Specifically:
- No PTR at all → almost certain spam, often outright rejected.
- PTR exists but generic (
ip-1-2-3-4.dynamic.isp.net) → spam-scored. Generic patterns indicate "consumer connection", not a mail server. - PTR mismatched with HELO → suspicious. Many receivers downgrade.
- Forward-confirmed PTR (FCrDNS resolves both directions correctly) → trusted.
Run the Reverse DNS Lookup on your sending IP to see what receivers see.
How to set a PTR record
You don't set PTR at your registrar — you set it with whoever owns the IP. That's typically your hosting provider, not your domain registrar.
Cloud providers
- AWS EC2: file a request via "EC2 → Elastic IPs → Manage reverse DNS" (requires opening a support case for new accounts).
- Hetzner: Robot panel → "Reverse DNS" tab. Self-service.
- DigitalOcean: set the droplet hostname → DO auto-creates a matching PTR.
- Linode: "Networking" tab → "Edit Reverse DNS" (requires forward DNS exists first).
- Google Cloud: create a public PTR record in Cloud DNS. Per-project.
Dedicated/colocation
Email your hosting provider's NOC. Standard request: "Please set PTR for 1.2.3.4 to mail.example.com." Most respond within 24h.
Verify it's right
Three checks:
- Forward DNS:
mail.example.com → A → 1.2.3.4✓ - Reverse DNS:
1.2.3.4 → PTR → mail.example.com.✓ - HELO/EHLO matches: your mail server should announce itself with the same hostname during SMTP.
postfix:myhostname = mail.example.com.
All three pointing at each other = forward-confirmed reverse DNS. Most receivers stop scoring this as spam.
Common mistakes
- Setting PTR to a hostname that doesn't have a forward A record. FCrDNS check fails, you get scored as misconfigured.
- Multiple PTRs for the same IP. Some servers only consult the first. Pick one canonical hostname.
- PTR set to the bare domain (e.g.
example.cominstead ofmail.example.com) — works but ambiguous; better to use a dedicated mail subdomain. - Forgetting to update PTR after a server move. The old IP still has the old PTR; the new IP has nothing. Both look bad.
After fixing PTR, re-check with the Reverse DNS Lookup and confirm the IP isn't on a blacklist — if it was previously listed, you may need delisting too.