What is a PTR record? (reverse DNS, explained)

A PTR record runs DNS in reverse: instead of turning a name into an IP address, it turns an IP address back into a name. It is the one record you usually cannot set where you set all the others.

The one-sentence version

A PTR (pointer) record is reverse DNS: it maps an IP address back to a hostname, the exact mirror of an A record. Ask “what name belongs to 203.0.113.10?” and the PTR answers.

The reverse-DNS tree

PTR records do not live alongside your normal records. They live in a separate namespace built just for addresses, with the address written backwards:

  • IPv4 reverse records sit under in-addr.arpa with the octets reversed: 203.0.113.10 becomes 10.113.0.203.in-addr.arpa.
  • IPv6 reverse records sit under ip6.arpa with the address reversed one hex digit (nibble) at a time.

The reversal is not arbitrary. DNS names are hierarchical from right to left (the .com is the broadest part), and IP addresses are hierarchical from left to right (the first octets identify the network). Flipping the address lets it delegate down the tree the same way a name does.

The part that surprises people: you usually cannot set it yourself

This is the key difference between a PTR and every other record. You control the forward DNS for your domain name, but the reverse zone for an IP address belongs to whoever owns that address block, which is your hosting provider, cloud provider, or ISP, not your domain's DNS host. So as a rule:

  • You set or request the PTR through whoever gave you the IP, not in the DNS panel where you add your SPF and MX records.
  • On the big clouds you can self-serve, but still through their console: AWS lets you set reverse DNS on an Elastic IP, and Google Cloud and Azure expose it on a static IP. Each one wants a matching forward record first.
  • On shared hosting or a home or office connection, the IP's PTR is often a generic name you cannot change at all.

(The exception that proves the rule: a large customer can have the reverse zone formally delegated to their own nameservers, at which point they host the PTRs themselves. That is the uncommon case.)

Why mail servers care about it

Reverse DNS is one of the oldest sniff tests for a legitimate mail sender. When your server connects to deliver a message, the receiver looks up the PTR of your connecting IP. A missing PTR, or a generic one like 203-0-113-10.dynamic.example-isp.net, reads as “some random host,” and your mail is treated with suspicion. The norm is one meaningful PTR per sending IP, naming a host on your own domain.

Worth being precise: this is a reputation signal, not authentication. Unlike SPF, DKIM, and DMARC, a passing reverse-DNS check does not authorize anything by itself. It just removes a common reason to distrust you.

The full-circle check (forward-confirmed reverse DNS)

Strict receivers do not stop at the PTR. They do a round trip, formally called iprev: take your connecting IP, find its PTR hostname, then look up that hostname's forward A or AAAA record and confirm it points back to the same IP. Both directions have to agree. This is what people mean by forward-confirmed reverse DNS, and Gmail and Yahoo both expect it from senders.

If your mail is getting bounced right now

This page is the concept: what reverse DNS is and who controls it. If a receiver is actively rejecting your mail over reverse DNS (Gmail's 550 5.7.25 is the usual one), head to the fix: reverse DNS and PTR records: why mail gets rejected, which walks the diagnosis and the repair.

Common questions

What is the difference between an A record and a PTR record?

An A record turns a name into an IP address. A PTR record turns an IP address back into a name. They are forward and reverse of each other, and a well-configured sending IP has both, pointing at each other.

Why can't I add a PTR record in my DNS settings?

Because the reverse zone for an IP belongs to whoever owns the address block, your host, cloud provider, or ISP, not your domain's DNS host. Set it through them: a cloud console for a cloud IP, or a support request for a hosting or ISP address.

Do I need a PTR record?

If you send mail directly from your own server's IP, yes, a matching reverse record is effectively required for good delivery to Gmail and Yahoo. If you send through an email provider, they own the sending IPs and manage the PTRs for you.

Keep reading

Last verified 2026-06-23 against RFC 1035 §3.5, which defines the in-addr.arpa reverse-DNS tree.

Stop guessing. Start monitoring.

Free for one domain. Set up in five minutes. We parse the reports; you read plain-English summaries.