Why mail servers need PTR records (and how to set one up)
Reverse DNS is the #1 cause of legitimate mail being scored as spam. What PTR records are, how to set one, and how to verify it from the receiver's side.
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.