Forward DNS turns a name into an IP. Reverse DNS does the opposite: given 203.0.113.10, it answers mail.example.com. Websites do not care about it at all. Mail servers care about it a great deal, and a server sending mail without a matching PTR record will find most of that mail in spam or bounced.
Why receivers check it
When your server connects to Gmail to deliver a message, it says "hello, I am mail.example.com". Gmail looks up the PTR for the connecting IP. If the PTR says mail.example.com, and mail.example.com resolves forward to that same IP, the server is who it claims. If the PTR is missing, or says something generic like 203-0-113-10.static.provider.net, the connection looks like a compromised home machine or a throwaway VPS — which is what most spam sources look like.
Gmail's published policy: mail from an IP without a PTR is rejected outright. Microsoft and most corporate filters score it heavily. It is the single most common reason a freshly set-up mail server "works" but delivers nothing to Gmail.
Check yours
dig -x 203.0.113.10 +short
# mail.example.com.
dig mail.example.com A +short
# 203.0.113.10Both directions must agree — that is called forward-confirmed reverse DNS (FCrDNS). The hostname in the PTR must also be what your mail server announces in its HELO/EHLO. On Plesk that is Tools & Settings → Server Settings → Full hostname; on Postfix it is myhostname in main.cf.
Who sets it
You cannot add a PTR in your own DNS zone. The reverse zone for an IP belongs to whoever was allocated the IP block — your hosting provider. Depending on the provider:
- a field in the VPS control panel ("Reverse DNS" / "rDNS"),
- a support ticket,
- automatic, set to the hostname you chose when ordering.
On VPSPioneer managed VPS plans, the PTR is set to your chosen hostname at provisioning and can be changed by ticket. On shared plans the shared mail IPs already have correct PTRs.
One PTR per IP
An IP has exactly one PTR. If a server sends mail for fifty domains, they all send from mail.yourserver.com — that is fine. The PTR does not have to match the sender domain, only the server's own hostname. What ties each sender domain to the server is SPF and DKIM, not the PTR.
IPv6
If the server sends mail over IPv6, that address needs its own PTR — and Gmail is stricter about IPv6 than IPv4. Most small mail servers should send over IPv4 only until the IPv6 PTR is confirmed. In Postfix: smtp_address_preference = ipv4 or inet_protocols = ipv4.
Symptoms of a missing PTR
- Bounces containing
550-5.7.1 ... does not meet IPv6 sending guidelinesor... PTR record. - Mail to Gmail vanishes; mail to a small business server arrives.
- mail-tester.com score of 5–6 with "you're not using a reverse DNS" in the report.
Fix the PTR, wait for the change to propagate (usually minutes, up to a day), and resend.
Other uses
Some SSH and FTP daemons log the PTR of connecting clients, which is why a login takes a few seconds on a server with slow DNS (UseDNS no in sshd_config stops that). Firewalls and geolocation databases use PTRs as a hint about who owns an address. But mail is the reason you will actually need one.
The checklist for a mail server that delivers — PTR, hostname, SPF, DKIM, DMARC, TLS — is in setting up email on Plesk so it does not land in spam.