A PTR record is the only DNS record whose name is an IP address spelled backwards. It lives in the special in-addr.arpa zone (for IPv4) or ip6.arpa (for IPv6), and the only system that cares about it intensely is the receiving mail server on the other end of your outbound SMTP connection. Skip PTR setup for your mail-sending IP and your messages will hit the spam folder, or get rejected outright, with no clue on the sending side except a curt 5xx response.

The format

To create a PTR for 203.0.113.10 pointing at mail.example.com:

10.113.0.203.in-addr.arpa.    3600    IN    PTR    mail.example.com.

The IPv4 address is reversed octet by octet and suffixed with .in-addr.arpa. For IPv6, every nibble of the address is reversed and suffixed with .ip6.arpa — a 32-character query for a typical address.

Lookup:

dig -x 203.0.113.10 +short
mail.example.com.

Who controls the in-addr.arpa zone

This is the operational gotcha. The in-addr.arpa zone for an IP block is controlled by whoever owns the IP block — your ISP, your cloud provider, your colo. Not by you, unless you have your own ASN and IP allocation. You cannot edit your PTR by editing the same DNS zone you use for your A records.

AWS EC2: request via support ticket per Elastic IP. Limited to 1 PTR per EIP.
Google Cloud: set via the console for each external IP.
Hetzner: set in the cloud console "Networking" tab.
DigitalOcean: automatic — the droplet's hostname becomes its PTR. Rename the droplet, the PTR follows.
OVH: set via "ReverseDNS" in the manager. Takes minutes to apply.
Your colo provider: open a ticket, or they may have delegated x.y.z.in-addr.arpa to your nameservers so you can self-serve.

Why mail servers care

Two reasons, both rooted in 25 years of anti-spam heuristics.

Reason one: forward-confirmed reverse DNS (FCrDNS). The receiving mail server does:

You connect from IP X.
I look up the PTR for X. I get hostname H.
I look up the A (and AAAA) for H. I get IP X'.
If X is in X', FCrDNS passes. Otherwise it fails.

FCrDNS is a weak proof of "this hostname's owner controls this IP", since both the forward and reverse zones have to point at each other. It is not authentication (anyone with control of both DNS zones can fake it for their own IP), but it is enough of a signal that legitimate mail operators have it and most spammers don't bother.

Failing FCrDNS adds spam points at every major receiver. Gmail, Outlook, Yahoo, Proton — all will silently penalise. They will not tell you that's why.

Reason two: residential IP detection. Many ISPs assign generic PTRs like c-203-113-0-10.dialup.example-isp.net to dynamic residential pools. Receivers maintain blocklists of common residential PTR patterns. A mail server sending from one of these gets rejected outright with messages like "client host rejected: cannot find your hostname" or "client host rejected: residential pool detected".

If your VPS or dedicated server inherits the provider's default PTR pattern (which often looks generic), you'll hit this filter even though you're operating a legitimate mail server. Set a real, descriptive PTR like mail.example.com.

What PTR does NOT prove

It does not prove the sender is authorised to send mail for the domain in the From header. That is what SPF, DKIM and DMARC do (see the email auth post). PTR is a far weaker, IP-level reputation signal that lives below the email-authentication layer entirely.

IPv6 PTR is also required

If your mail server sends from an IPv6 address (and most do, since most modern providers dual-stack by default), the receiving server checks PTR on the IPv6 too. The same FCrDNS rule applies, with the added pain that the ip6.arpa zone format is awful to read.

Lookup IPv6 PTR:

dig -x 2001:db8::1 +short

The -x flag does the nibble-reversal for you. The actual ip6.arpa name is unreadable by hand.

Verifying your setup

Sending mail and watching for inbox vs spam is too slow a feedback loop. Use the tooling:

# Is the PTR set?
dig -x <your-mail-ip> +short

# Does FCrDNS pass?
dig -x <your-mail-ip> +short
dig +short <hostname-from-above> A
dig +short <hostname-from-above> AAAA
# All forward results must include your mail IP.

For a full "what does the receiver see" view, mail-tester.com and mxtoolbox.com are the standard tools. From a DNS-only perspective, the PTR forms part of the same record set that dnscheck queries — although for IP-side records, you generally have to query by IP, not by hostname.

And once your forward records are also published (MX, SPF, DKIM, DMARC TXT), validate those are consistent across resolvers — try the multi-resolver matrix on protonmail.com to see a clean reference setup.

References: RFC 1035 §3.5 (in-addr.arpa), RFC 3596 (IPv6 PTR via ip6.arpa), RFC 8499 (DNS Terminology).