Most senders never touch PTR records. Their ESP sets one for them. The moment you move to a dedicated IP, a self-hosted relay, or any cloud VM that sends mail directly, PTR becomes your problem — and most of the time it is already wrong.
No PTR record on your sending IP, or a PTR that doesn't match forward DNS (FCrDNS), and Gmail will quietly rate-limit you. Outlook is stricter: many messages will be rejected at the SMTP layer with a 5xx code. Fix PTR before you even think about tuning SPF.
What a PTR record is
A PTR record — short for Pointer — is the reverse of an A record. An A record maps a hostname to an IP. A PTR maps an IP back to a hostname. They live in a special DNS zone called in-addr.arpa (IPv4) or ip6.arpa (IPv6) and, crucially, they are controlled by the owner of the IP, not the owner of the domain.
For IP 192.0.2.25, the PTR lives at 25.2.0.192.in-addr.arpa and typically resolves to something like mail.example.com. You can query it directly:
$ dig -x 192.0.2.25 +short
mail.example.com.Forward-confirmed reverse DNS (FCrDNS)
PTR alone is not enough. Receivers insist on forward-confirmed reverse DNS — the round trip must close. Given an IP, the flow is:
- Reverse lookup the IP. Get a hostname (e.g.
mail.example.com). - Forward lookup that hostname. Get an IP (or several).
- Confirm the original IP appears in that set.
If any step fails, FCrDNS fails. Here is a concrete example of a passing FCrDNS:
$ dig -x 192.0.2.25 +short
mail.example.com.
$ dig mail.example.com +short
192.0.2.25And a failing one:
$ dig -x 192.0.2.25 +short
ec2-192-0-2-25.compute-1.amazonaws.com.
$ dig ec2-192-0-2-25.compute-1.amazonaws.com +short
192.0.2.25 # technically passes FCrDNS, but looks like a raw cloud hostThe second case round-trips cleanly, so strictly it passes FCrDNS. The problem is the content of the hostname. Receivers use generic-cloud-hostname patterns as a strong spam signal. A PTR of ec2-203-0-113-45.compute-1.amazonaws.com will not help you.
Why Gmail, Outlook and Yahoo demand it
Every major inbox provider documents a PTR requirement for bulk senders. In practice:
- Gmail. The 2024 bulk sender rules list "valid PTR record" as mandatory. Messages from IPs without one are still accepted but routed straight to Spam.
- Outlook / Office 365. The strictest of the majors. Missing PTR = SMTP-level rejection with a 5xx code before the message even reaches the content filter. The bounce explicitly mentions PTR.
- Yahoo. Same 2024 bulk rules as Gmail. Non-matching PTR is treated the same as no PTR.
- Mail.ru and Yandex. Both aggressively down-rank mail from cloud-pattern PTRs. Yandex has a documented list of generic hostname suffixes that trigger automatic Spam placement.
Two common PTR failure modes
1. No PTR at all
Typical on self-hosted VPS. You provisioned an instance, assigned an IP, started Postfix, everything looked fine. Outgoing mail fails for Outlook recipients and goes to Spam for Gmail. A dig -x on your IP returns NXDOMAIN or no answer.
2. Mismatched or generic PTR
Your PTR says mail.example.com but the A record for mail.example.com points at a different IP. Round-trip fails, FCrDNS fails, authentication systems flag the mismatch. Or your PTR was never changed from the provider default static.203.0.113.in-addr.arpa.
Setting up rDNS, by provider
Hetzner
In the Cloud Console or Robot panel, open the server, then the IP list, then the small edit icon next to each IP. Enter the fully-qualified hostname (no trailing dot, no protocol). Hetzner publishes the PTR within minutes. Repeat for IPv6.
OVH
OVH manages IPs separately from servers. Go to Bare Metal Cloud → IP, find the address, click the ⚙ icon, and choose Modify the reverse. Note: OVH requires the forward A record to exist and match before it will accept the PTR. Create the A first.
AWS — EC2 and SES
For EC2, open a support request from the AWS console: Service → EC2 → Feature Request → Reverse DNS. You provide the Elastic IP and the hostname. AWS needs an MX or SPF record involving that hostname to verify control. Approval is typically within 48 hours.
For SES, you do not set PTR yourself. SES manages rDNS for its shared pool. On dedicated IPs, PTR is set to a SES-owned hostname by default; you can request a custom MAIL FROM domain and a custom PTR via AWS support.
DigitalOcean
DigitalOcean sets the PTR automatically from your Droplet name. So if you want mail.example.com as the PTR, rename the Droplet to exactly that. Counterintuitive but documented. IPv6 PTRs follow the same rule.
Your PTR should read like a real mail server hostname under a domain you control. mail.example.com, smtp-out.example.com, mta1.example.com. Never the raw cloud provider pattern. And the forward A record for that hostname must point back to the same IP.
How to verify your PTR
dig -x 192.0.2.25 +shortfrom a terminal. Must return your chosen hostname.dig A mail.example.com +short. Must include the same IP.- Send a test message to
check-auth@verifier.port25.com. The reply includes an explicit FCrDNS section. - MXToolbox
SuperToolwith the Reverse Lookup option. - Or run an inbox placement test — the DNS tab flags a missing or mismatched PTR in seconds.
Shared vs dedicated IPs — who owns the PTR
On a shared IP at an ESP (SendGrid shared, Mailchimp, Postmark shared), the ESP owns the IP and therefore owns the PTR. It will read like o1.sendgrid.net or similar. You cannot change it, and you should not want to — the ESP's PTR is part of its reputation.
On a dedicated IP, the ESP typically sets the PTR on your behalf to a hostname under their domain, and some offer a custom PTR if you provide a hostname on your domain. That is worth doing: a PTR matching your domain strengthens brand signal and helps alignment checks at stricter receivers.
On your own IP (VPS, cloud VM, dedicated server), the PTR is yours to set and yours to break. This is the case where the rules in this article matter most.