PTR Records and Deliverability: What ISPs Must Provision

Our rDNS fundamentals guide covers what a PTR record is and why receiving mail servers check for one. This article assumes that background and goes narrower: the mechanics of forward-confirmed reverse DNS, why a present but generic PTR record can be almost as damaging as a missing one, and exactly what an ISP should provision by default for each class of IP it hands out.

Two Different Failures

Missing PTR is the failure everyone knows about - no reverse DNS at all, and a growing share of receiving mail servers reject the connection at SMTP time. It's well documented and easy to test for.

The second failure is subtler: a PTR record that exists but reads as unmanaged address space - hostnames built from patterns like dynamic, dhcp, pool, or dsl combined with the raw IP and nothing else. Reputation systems that track dynamic and residential ranges - Spamhaus's Policy Block List is the best-known example - classify IPs partly by exactly this kind of naming convention, on the theory that address space labeled as dynamic residential shouldn't be originating direct-to-MX mail in the first place. An IP with a PTR record that satisfies the "record exists" check can still get treated as if it shouldn't be sending mail, purely because of what the hostname says about it.

How FCrDNS Validation Actually Runs

Forward-Confirmed reverse DNS is a two-step check, and both steps have to pass:

# Step 1: reverse lookup on the connecting IP
dig -x 198.51.100.22
;; ANSWER: 22.100.51.198.in-addr.arpa. PTR mail.example.com.

# Step 2: forward lookup on the returned hostname
dig A mail.example.com
;; ANSWER: mail.example.com. A 198.51.100.22

# Both addresses match -> FCrDNS passes

A mismatch at either step - no PTR, a PTR whose forward record doesn't exist, or a forward record that resolves to a different IP - fails FCrDNS. A common, easy-to-miss cause: the PTR points to a hostname whose A record was updated after the PTR was set (a server migration, a load balancer change) and nobody updated the reverse side to match. The check has been passing for months and silently starts failing the day the forward record moves.

Gmail's published guidance is explicit that it checks for a PTR record on the sending IP with matching forward DNS, and treats its absence as a negative signal in spam classification. Microsoft's and other major receivers' filtering pipelines apply equivalent logic even where it's less explicitly documented.

Default PTR Provisioning by IP Class

Not every IP needs a hand-picked hostname. What matters is matching the provisioning default to how the IP will actually be used:

IP class	Default PTR	Why
Residential / dynamic	Descriptive but honest pattern, e.g. `198-51-100-22.customers.yourisp.net`	Not expected to send mail directly; clarity matters more than avoiding the word "customers"
Static business, no mail server	ISP-generated default hostname	No deliverability requirement, but still avoids a blank record
Business mail server	Exact match to the HELO/EHLO hostname the mail server presents	FCrDNS is validated against this specific hostname; anything else fails the check
Dedicated / hosting server	Meaningful hostname set at provisioning, not left on the default pattern	Customer will likely run mail or other services expecting a real identity

A Provisioning Checklist for Mail-Sending IPs

Collect the intended HELO hostname before activation - the PTR needs to match what the mail server will actually present, not a guess
Validate the forward record exists and matches first - creating the PTR before the customer's A/AAAA record is live guarantees a temporary FCrDNS failure
Set the PTR only after forward validation passes - reject or hold the request rather than creating a record you know will fail
Re-validate on a schedule, not just at creation - forward records drift independently of PTR records over a customer's lifetime
Avoid default hostnames that read as dynamic/residential on any IP a business customer intends to use for mail, even if the IP itself is technically static

The pattern across all of this is the same one that shows up everywhere in bulk PTR management: validation and defaults have to be enforced at the point of provisioning, automatically, because a manual "remember to check the PTR" step is the one that gets skipped under load.

Provision Correct PTR Records by Default

WebPTR validates FCrDNS before a PTR goes live and applies the right default pattern per IP class - so mail-sending customers never activate on a record that was always going to fail.

Learn about WebPTR →