PTR Records and Reverse DNS: Why Mail Servers Care
A PTR record is the cheapest piece of mail infrastructure to set up. It is also the one most senders forget to check — and a missing or generic PTR is a hard block at most modern mailbox providers. This is what it does and how to get it right.
What a PTR record actually is
DNS normally maps names to IPs: ask for example.com and you get back 198.51.100.20. A PTR record is the reverse: ask for 198.51.100.20 and DNS returns a name. PTR records live in the special in-addr.arpa zone (for IPv4) or ip6.arpa zone (for IPv6).
For our example IP, the PTR record sits at 20.100.51.198.in-addr.arpa — the octets reversed, with the special suffix appended. Most operators never see this directly because their hosting provider's control panel hides the gory details behind a simple text field.
Forward-confirmed reverse DNS, explained
A receiving mail server checks two things when accepting an inbound SMTP connection:
- It resolves the PTR of the connecting IP. Suppose
198.51.100.20→mail.example.com. - It then resolves the A record of
mail.example.com. The result must come back as198.51.100.20.
If both directions match, the IP has forward-confirmed reverse DNS (FCrDNS). If only one direction works, the receiver treats the connection as suspicious. If neither works, your mail will almost certainly be blocked or scored heavily towards spam.
What "good" looks like
A clean PTR for a sending mail server has these properties:
- It resolves to a name in a domain you control.
- The name is forward-resolvable to the same IP (FCrDNS).
- The name is descriptive and stable, e.g.
validation-mx02.prod.delgara.com, notvps-i7-12345.cheap-cloud.example. - The name matches the EHLO/HELO hostname your MTA announces.
That last bullet is subtle but consequential: many receivers compare the connecting IP's PTR to the name your server uses in EHLO. A mismatch is a small but consistent negative signal.
What "bad" looks like
The most common failure modes:
- No PTR at all. Reverse lookup returns NXDOMAIN. Many receivers reject outright.
- Generic ISP PTR. Names like
198-51-100-20.example-broadband.comorec2-198-51-100-20.compute.amazonaws.com. Treated as residential or generic infrastructure rather than a legitimate mail server. - PTR does not forward-confirm. The PTR points at
mail.example.combutmail.example.comdoes not resolve back to that IP, or resolves to a different one. - PTR points at a domain whose forward DNS is broken. Same effect: the lookup chain breaks.
How to set a PTR record
This is the only DNS record you cannot publish yourself. PTR records live in the IP owner's DNS, which means your hosting provider publishes them on your behalf. The mechanism varies by provider.
OVH
Manager → Bare Metal Cloud or VPS → IP → "Reverse DNS" pencil icon. Type the desired hostname and save. Active within a few minutes. OVH validates that the forward A record exists before accepting the change.
Hetzner
Cloud Console → Server → Networking tab → "Reverse DNS" beside each IP. For dedicated servers (Robot), use the Robot panel under "Server → IPs".
AWS EC2
Reverse DNS for an Elastic IP requires opening a support case — AWS will not let you set a PTR through the console. The case template is at console.aws.amazon.com → Support → "Service limit increase" → "Reverse DNS for EC2 IP." Approval typically takes a day or two and AWS will refuse if your domain does not already have an MX record pointing at the IP.
Google Cloud
Custom PTR records can be set through the console for Public IP addresses. Compute Engine → the IP → "Reverse DNS" field. As with AWS, the forward record must exist first.
DigitalOcean
The PTR is automatically derived from the droplet's hostname. To customise, rename the droplet to your desired hostname and DigitalOcean propagates the change to the PTR.
Linode / Akamai
Linode Manager → the linode → Network tab → "Edit RDNS" against each IP. The forward A record must exist.
How to verify your PTR
From any Linux or macOS shell:
# Reverse lookup
$ dig +short -x 198.51.100.20
mail.example.com.
# Forward lookup of the result
$ dig +short mail.example.com
198.51.100.20Both must return what you expect. If the forward lookup is missing, add an A record. If the reverse lookup is missing, contact your hosting provider.
For one-off web checks: MXToolbox's Reverse Lookup tool does both directions on a single page.
Edge cases worth knowing
IPv6 PTR records
Same idea, different syntax. A PTR for 2001:db8::1 would live at 1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.8.b.d.0.1.0.0.2.ip6.arpa — every nibble reversed, dots between, with the ip6.arpa suffix. Do not type this by hand; let your DNS provider generate it.
Multiple PTRs for one IP
You can technically publish multiple PTR records for one IP. Do not. Most resolvers return only one (and they pick which one apparently at random), so the result is non-deterministic and the FCrDNS check sometimes passes and sometimes fails. One PTR per IP, always.
Shared IP and PTR conflict
If your hosting provider gives you a generic PTR (vps-12345.host-co.example), you usually want to override it with your own hostname. But that hostname needs to forward-resolve to that IP, which can clash if the same hostname is also used for your website on a different IP. Use distinct hostnames for web and mail (e.g. example.com and mail.example.com) and the conflict disappears.
What happens when PTR is wrong
Concrete numbers from production traffic across our customer base:
- Sending from an IP with no PTR — about 35% of mail to Gmail goes to spam, 80% to Outlook gets blocked outright.
- Sending from an IP with generic ISP PTR — about 15% goes to spam at Gmail, 40% blocked at enterprise gateways.
- Sending with FCrDNS but PTR not matching HELO — mostly accepted but a small reputation drag accumulates over time.
- Sending with clean FCrDNS that matches HELO — baseline good.
The fix is so cheap and so effective there is no excuse not to do it. Audit every sending IP, get them all to FCrDNS, make sure the PTR matches your EHLO. Few deliverability investments produce more return for less effort.