Skip to main content
Relaymetry

What is a PTR record? Reverse DNS, explained

A PTR record maps an IP address back to a hostname, the record type behind reverse DNS (RFC 1035). It does not live in your own domain's zone: whoever owns the IP block, usually your host, cloud, or ISP, publishes it. Mail servers need a matching PTR and IPv6 senders effectively require one, or outbound mail lands in spam or is rejected.

Quick answer

A PTR record maps an IP address back to a hostname, which is the reverse of what an A or AAAA record does. It is the record type behind reverse DNS (RFC 1035 §3.3.12). The record does not live in your own domain's zone: whoever controls the IP address block publishes it, usually your hosting provider, cloud platform, or ISP. You can look up the PTR for any address with the reverse-DNS lookup tool.

What a PTR record actually is

A forward lookup answers "what is the IP for mail.example.com?" and returns an A record (IPv4) or AAAA record (IPv6). A reverse lookup asks the opposite question: "what hostname belongs to 203.0.113.10?" The answer comes from a PTR record.

The RDATA of a PTR record is a single domain name (RFC 1035 §3.3.12). That is the whole payload. The name 10.113.0.203.in-addr.arpa might hold a PTR pointing to mail.example.com, and nothing else. There is no rule that a PTR match any forward record, and DNS itself does not enforce that the two agree. Whether they agree is exactly what mail servers check, covered further down.

Where a PTR record lives: in-addr.arpa and ip6.arpa

Reverse DNS has its own branch of the namespace. IPv4 reverse records live under in-addr.arpa, with the four octets of the address written in reverse order (RFC 1035 §3.5). The reversal is what lets a provider delegate one network's worth of reverse space as a single zone.

IP address:   203.0.113.10
PTR query:    10.113.0.203.in-addr.arpa

Read the octets right to left. 203.0.113.10 becomes 10.113.0.203, then .in-addr.arpa is appended.

IPv6 uses ip6.arpa instead and goes finer-grained. The address is expanded to its full 32 hex digits, each nibble becomes one label, and the nibbles are written low-order first (RFC 3596 §2.5). The RFC's own example maps 4321:0:1:2:3:4:567:89ab to b.a.9.8.7.6.5.0.4.0.0.0.3.0.0.0.2.0.0.0.1.0.0.0.0.0.0.0.1.2.3.4.ip6.arpa. The principle matches IPv4: reverse the address, append the special suffix.

Who publishes a PTR record

This is the part that trips people up. A PTR record is not in your domain's zone file, so you cannot add it in the same DNS panel where you manage your A, MX, and TXT records. It lives in the reverse zone for the IP block, and that zone belongs to whoever owns the address space.

For a server you rent, that owner is your hosting provider, cloud platform, or ISP. You set the PTR through their control panel, where many clouds expose a "reverse DNS" or "PTR" field on the instance or IP object, or by opening a support request. If you run your own address block, you can publish PTR records in the reverse zone directly, and larger providers sometimes delegate that zone to you with NS records so you manage it yourself.

One PTR per IP is the normal case. Publishing several PTR records for a single address is technically legal but discouraged, because consumers generally expect one name back.

Forward-confirmed reverse DNS (FCrDNS)

A PTR on its own proves little, because the IP owner can point it at any hostname they like. Forward-confirmed reverse DNS closes that gap. A PTR is forward-confirmed when the hostname it returns also resolves, through an A or AAAA record, back to the original IP address.

The check is a round trip:

203.0.113.10       --PTR-->  mail.example.com
mail.example.com   --A-->    203.0.113.10   (match: FCrDNS passes)

If the forward record points somewhere else, or does not exist, FCrDNS fails even though a PTR is present. Mail receivers run this check on the connecting IP as a cheap, hard-to-forge signal that the sender controls both the address and the name. RFC 8499 §7 defines the reverse DNS terminology this builds on.

PTR records and email deliverability

For a mail server the PTR is close to mandatory. A missing PTR, or a generic one that still carries the provider's default naming such as 203-0-113-10.static.example-isp.net, reliably pushes outbound mail toward spam folders and rejections. Large receivers read the absence of a proper reverse record as a low-reputation signal. For IPv6 senders the bar is higher: major providers effectively require a valid PTR before they will accept the connection at all.

This page defines the record type; the mail-specific errors have their own guides. If Gmail rejects your mail with a reverse-DNS error, see the Gmail 5.7.25 PTR error page. If your PTR hostname does not match what your server announces in HELO/EHLO, see reverse-DNS HELO mismatch. To see what resolves for any address right now, run the reverse-DNS lookup tool. For the forward side of the same IPv6 address, see the AAAA record guide, and for the wider family of records, the DNS record types hub.

Frequently asked questions

What is a PTR record / reverse DNS?

A PTR record maps an IP address back to a hostname, which is the reverse of what an A or AAAA record does. That mapping is what DNS calls reverse DNS, and the PTR record type is defined in RFC 1035. Reverse records for IPv4 live under in-addr.arpa and for IPv6 under ip6.arpa.

Do I need a PTR record to send email?

For a mail server, effectively yes. A missing or generic PTR reliably sends outbound mail to spam or gets it rejected by large receivers, and IPv6 senders are generally required to have a valid PTR before mail is accepted. A matching reverse record is one of the baseline requirements for inbox delivery.

Who sets the PTR record?

Whoever controls the IP address block, which is normally your hosting provider, cloud platform, or ISP. Because the PTR lives in the reverse zone for the IP rather than in your own domain's zone, you cannot add it in your regular DNS panel. You set it through the provider's control panel or by asking their support.

What is forward-confirmed reverse DNS (FCrDNS)?

Forward-confirmed reverse DNS means the hostname returned by an IP's PTR record also resolves back to that same IP through an A or AAAA record. The two records agree, forming a round trip that is hard to fake. Mail receivers check FCrDNS as a lightweight signal that a sender controls both the address and the name.

How do I check reverse DNS?

Query the PTR for the IP under in-addr.arpa (IPv4) or ip6.arpa (IPv6). On the command line you can run a reverse lookup with nslookup or dig, or use the reverse-DNS lookup tool on this site to see the PTR and whether it forward-confirms back to the same address.

Other DNS records

References

Browse all guides →