A PTR record maps an IP address back to a hostname. It is the reverse of the A and AAAA records that turn a name into an IP. When a system looks up the name for an IP, it is reading that IP's PTR record. This is called a reverse DNS lookup.
→ Check the PTR record for your IP or any address with the free Reverse DNS Lookup tool. It also runs the forward-confirmed check described below.
Where PTR records live
PTR records sit in a dedicated part of DNS. For IPv4 the address is written backwards under in-addr.arpa, so 8.8.8.8 becomes 8.8.8.8.in-addr.arpa. For IPv6 each hex digit is reversed under ip6.arpa. These zones are handed down the same chain as the addresses themselves: registry to provider to customer. Whoever holds the IP block controls the PTR, which is usually your ISP or hosting company — not you. For a full walk-through of the mechanics, see our guide to reverse DNS lookups.
FCrDNS: the check that matters
A PTR record on its own proves little, because the block holder can set it to any string. So receiving systems apply a stricter test called Forward-Confirmed reverse DNS (FCrDNS):
- Look up the PTR record for the IP. Say it returns
mail.example.com. - Look up the
AandAAAArecords formail.example.com. - Check that the original IP is in that list.
If it matches, the reverse DNS is forward-confirmed. If the PTR points to a name that resolves somewhere else, or to nothing, the check fails. The Reverse DNS Lookup tool shows you both the PTR and the forward IPs it found, so you can see exactly where a mismatch is.
Why email cares
Mail servers use FCrDNS as a cheap signal of a legitimate sender. A sending IP with no PTR, or one that fails forward confirmation, is a common trait of spam sources and compromised machines. The typical outcomes:
- No PTR at all. Many servers reject the connection outright or add a large spam score.
- Generic PTR. A name like
93-184-216-34.dynamic.example-isp.netpasses FCrDNS but still looks like a home or dynamic line, which some servers weigh against you. - PTR fails forward confirmation. Treated much like having no PTR.
- Clean, matching PTR such as
mail.yourdomain.comthat resolves back to the sending IP. This is what you want, and it should line up with your SPF and DKIM setup.
Reverse DNS is not the only thing that decides inbox placement — SPF, DKIM, DMARC, and sending reputation all matter — but a broken PTR is an easy way to fail before those are even checked.
How to check yours
- Reverse DNS Lookup — enter the IP, read the PTR and the FCrDNS result.
dig -x 203.0.113.25 +shorton macOS or Linux.nslookup 203.0.113.25on Windows.
For the IP of your own mail server, run the check against that address. To see who is responsible for the block, use an IP WHOIS lookup — the abuse or registrant contact is usually the party that sets PTRs.
If it is missing or wrong
You cannot add a PTR in your own domain's DNS. You have to ask whoever controls the IP block:
- Cloud or VPS host. Most have a "reverse DNS" or "PTR" field in the server or IP settings. Set it to a hostname you also publish an
Arecord for. - Business ISP. Open a ticket asking them to delegate the reverse zone to you or to set a specific PTR.
- Home connection. You usually cannot get a custom PTR, which is one reason to send mail through a relay or provider rather than straight from a home IP.
After a change, allow for the old record's TTL to expire, then re-run the lookup to confirm the PTR resolves and forward-confirms.
Quick answers
Does every IP need a PTR? No. It matters for servers that send mail. For a device that only browses, a missing PTR changes nothing.
Can one IP have several PTR records? It can, but many mail systems only look at the first, and multiple PTRs make FCrDNS harder to reason about. One clean record is best.
Is a PTR the same as an MX record? No. An MX record says which server receives mail for a domain. A PTR names the IP a connection is coming from. They serve different jobs.
Run a reverse DNS check → · Related: reverse DNS lookups in depth, DNS record lookup.