PTR Records and Reverse DNS: Why They Matter for Email
A PTR record is the simplest piece of email infrastructure you can configure. It is also the one that most senders forget to check — and a missing or generic PTR is a hard block at most modern mailbox providers. Here is what it does and how to get it right.
What a PTR record is
DNS normally maps names to IPs: ask for example.com and you get back 192.0.2.10. A PTR record is the reverse lookup: ask for 192.0.2.10 and DNS gives you back a name. The PTR record is published in the special in-addr.arpa zone (for IPv4) or ip6.arpa zone (for IPv6).
For our example IP, the PTR record lives at 10.2.0.192.in-addr.arpa — the octets reversed and a special suffix. Most people never see this directly because their hosting provider's control panel hides the gory details.
What forward-confirmed reverse DNS means
A receiving mail server checks two things when it accepts an inbound SMTP connection:
- It looks up the PTR record of the connecting IP. Suppose
192.0.2.10→mail.example.com. - It then looks up the A record of
mail.example.com. The result must come back as192.0.2.10.
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, you are almost certainly going to have your mail blocked or scored heavily towards spam.
What "good" looks like
A clean PTR for a sending mail server has these properties:
- 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:
mail2.doposta.com, notvps-i7-12345.cheap-cloud.example. - The name matches the EHLO/HELO hostname your MTA announces.
That last one is subtle but important: 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
192-0-2-10.example-broadband.comorec2-192-0-2-10.compute.amazonaws.com. Treated as residential or generic infrastructure, not a legitimate mail server. - PTR doesn't forward-confirm. The PTR points at
mail.example.combutmail.example.comdoesn't resolve back to that IP, or resolves to a different IP. - PTR is on a domain whose forward DNS is broken. Same effect: lookup chain breaks.
How to set a PTR record
This is the only DNS record you cannot set 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, 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 won't 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 doesn't already have an MX record pointing to 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 set to the droplet's hostname. To customise, you need to 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. Forward A record must exist.
How to verify your PTR
From a Linux or macOS shell:
# Reverse lookup
$ dig +short -x 192.0.2.10
mail.example.com.
# Forward lookup of the result
$ dig +short mail.example.com
192.0.2.10Both must return the values 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 the same in a single page.
Special 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. Don't try to type this yourself; your DNS provider will generate it.
Multiple PTRs for one IP
You can technically publish multiple PTR records for one IP. Don't. 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 PTR pointing to their generic infrastructure (vps-12345.host-co.example), you usually want to override it with your own hostname. But your own 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 problem goes away.
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 doesn't match HELO — mostly accepted but small reputation drag over time.
- Sending with clean FCrDNS that matches HELO — baseline good.
The fix is so cheap and so effective that there is no excuse not to do it. Audit every sending IP, get them all to FCrDNS, make sure the PTR matches your EHLO. It is one of the best deliverability returns on the smallest investment.