Why receivers insist on it
A PTR record requires that someone controls the IP block — it is set by whoever operates the address, not by whoever currently uses it. That is precisely what makes it a usable minimum signal: anyone sending from a hijacked endpoint or an arbitrary cloud container typically does not have one.
Google, Microsoft and most large receivers reject at connection time when the PTR is absent — before SPF, DKIM or the content are ever considered.
A PTR alone is not enough: FCrDNS
The check runs both ways. The circle has to close:
If the PTR points at a name whose A record leads elsewhere, that counts as not confirmed (FCrDNS fail) and is treated by many receivers like a missing record. Both directions must agree.
Where the record is set
This is where most people get stuck: the PTR does not belong in your domain zone. It lives in the in-addr.arpa zone of the IP block and is therefore managed by whoever gave you the IP — hosting provider, data centre or ISP. Most offer a field in the customer portal; otherwise a short support request does it.
The A record for the same name, by contrast, is yours. Both sides must be in place.
Related: the HELO name
Many receivers additionally compare whether the name the server announces in HELO/EHLO matches the PTR. Cleanest is to use the same fully qualified name everywhere — in HELO, in the PTR and in the A record. A default HELO such as localhost.localdomain is a rejection reason in its own right.
Patience when verifying
Reverse DNS zones are cached by many resolvers for a long time. After setting the record it can take hours before every receiver sees it — so an immediate re-test says little.