A PTR record maps an IP address back to a hostname. The reverse of what a normal DNS lookup does. It exists for one practical reason on a hosting server: receiving mail servers check it, and mail from an address without one is treated as suspicious.
Why it lives somewhere else
This is the part that confuses people, and it explains why you cannot add one in your zone.
Forward records are controlled by whoever holds the domain. Reverse records are controlled by whoever holds the IP address, which is your hosting provider, not you.
So a PTR record is a request to your provider rather than something you configure. On a dedicated server or VPS with a dedicated address, they will usually set it to whatever you ask.
On shared hosting you cannot have your own, because the address is shared with hundreds of accounts and there is only one PTR record for it. That is normal and not a problem, as long as your mail is sent through the server's own hostname.
What it needs to say
The PTR must point at a hostname, and that hostname must point back at the same address. Both directions have to agree.
dig -x 203.0.113.10 +short dig A mail.example.com +short
The first should return mail.example.com, and the second should return 203.0.113.10. A PTR naming a hostname that resolves elsewhere is worse than none at all, because it looks like a misconfiguration or an impersonation attempt.
Match it to what your mail server announces
When your server connects to deliver mail, it introduces itself with a hostname in the HELO or EHLO command.
Receiving servers compare three things: that announced name, the PTR for your address, and the forward record for the name. All three should agree.
The most common failure is a server announcing server42.provider.net while its PTR says mail.example.com. Both exist, neither is wrong on its own, and the mismatch is what gets scored against you.
Set the mail server's announced hostname and the PTR to the same value, and make sure that name has an A record pointing back.
What happens without one
Not an outright rejection, usually. Something less visible and harder to diagnose.
Some receiving servers reject outright. Many add to a spam score, so your mail lands in junk folders rather than bouncing. Some defer delivery, which looks like slow mail instead of a configuration problem.
The result is mail that mostly works, arrives late for some recipients, and disappears into spam for others, which nobody reports, because the sender assumes it arrived.
Where it sits among the other checks
PTR is one signal among several, and the others matter more.
SPF says which servers may send for your domain. DKIM signs the message so it cannot be altered. DMARC tells receivers what to do when those fail.
Those three are set in your own DNS and you control them entirely. For that, see understanding SPF, DKIM and DMARC.
PTR is the one you have to ask for, and it is the one people forget because it is not in the zone file they were editing.
Requesting one
Ask your provider, giving the IP address and the hostname you want.
Before asking, create the forward record: the hostname must already resolve to that address, or the pair will not validate when someone checks.
Use a hostname on a domain you control and that looks like a mail server: mail.yourdomain.com rather than something generic. Providers usually apply it within a day, and it propagates like any other DNS record.
One address, one PTR
An address has a single PTR record. It cannot name several hostnames for several domains.
So a server sending mail for twenty domains has one reverse name, and that is fine. The check is that the sending server identifies itself consistently, not that it matches every domain it sends for.
Pick one hostname for the server, use it in the PTR and in the mail server's announcement, and let the per-domain authentication be handled by SPF and DKIM.
IPv6 needs its own
Easy to miss and increasingly relevant.
If your server has an IPv6 address and sends over IPv6, that address needs its own PTR record. Major providers check it, and a server with a correct IPv4 setup and no IPv6 reverse record gets mail rejected only when the receiving side prefers IPv6.
The symptom is mail failing to some large providers and working everywhere else, which is a confusing pattern until you know to look.
Reverse DNS elsewhere
Two places you will meet it outside mail.
Log files. Some tools resolve addresses to names, which is why a log entry can show a hostname. It can also slow log processing considerably, and it is usually worth leaving off.
Access rules. Some systems allow or deny based on a reverse lookup. Treat that as weak: reverse records are controlled by whoever holds the address, so it is not a strong identity check.
Checking yours
dig -x YOUR.IP.ADDRESS +short
Nothing returned means no PTR is set. A name returned means one is, and the next step is confirming it resolves back to the same address.
Then send a test message to an external address and look at the received headers, which usually show what the receiving server made of your connection. Email routing and track delivery explains reading the delivery report from your side.
Confirm the forward and reverse agree
A reverse record on its own is not enough. Receiving systems take the name it returns and look that name up again, expecting to arrive back at the same address.
ip=203.0.113.10 name=$(dig -x $ip +short | sed 's/\.$//') echo "$ip -> $name -> $(dig +short "$name" | tr '\n' ' ')"
All three values must line up. A reverse record naming a host that does not resolve, or that resolves to a different address, fails the check as completely as having no record at all.
This is the most common fault after a server move, because the reverse record is set by the address holder and the forward record by you, and the two are updated by different people at different times.
Shared addresses and what you can actually change
On shared hosting the address belongs to many accounts, so there is one reverse record for all of them and it names the server rather than any customer's domain.
That is correct and it is not something to request a change to, since changing it would affect every other account on the machine. Mail from a shared server should announce the server's own hostname, which matches the reverse record, rather than the customer's domain.
hostname -f dig -x "$(curl -s ifconfig.me)" +short
Where a customer genuinely needs the reverse record to carry their own name, that requires an address dedicated to them. It is worth saying plainly rather than filing a request that cannot be granted. Service certificates and the server hostname deals with keeping that name consistent.
When it is wrong, mail degrades rather than fails
A missing or mismatched record rarely produces a rejection. It produces a lower score, and the effect is delivery that gets slowly worse.
The symptoms are recognisable: mail to one large provider starts arriving in the spam folder while another accepts it normally, and nothing in your own logs shows an error because the message was accepted.
grep -iE 'ptr|reverse|dns' /var/log/exim_mainlog 2>/dev/null | tail -10 exim -bp | wc -l
Because there is no error, this is one of the few problems worth checking proactively rather than in response to a report. It takes one command and it is a common reason for a sending reputation that declines without explanation. The email deliverability tool covers the rest of the checks that behave this way.