Reverse DNS (PTR) and Why It Matters for Email Deliverability

Most of DNS works in one direction: you have a name like mail.example.com and you look up the IP address it points to. Reverse DNS does the opposite. It answers the question "which hostname belongs to this IP address?" That sounds like a niche convenience, but for anyone running a mail server it is anything but optional. A missing or sloppy reverse DNS entry is one of the quickest ways to get your legitimate email rejected, deferred, or dumped in the spam folder before a human ever sees it.

This guide explains what reverse DNS and the PTR record actually are, the special zones that make them work, who controls them (probably not who you think), and the forward-confirmed reverse DNS check mail servers rely on, then how to set up a PTR record and confirm it is correct.

Reverse DNS (rDNS) is the process of mapping an IP address back to a hostname. The record that carries this mapping is the PTR record, short for "pointer." Where an A or AAAA record points a name at an address, a PTR record points an address at a name. So while the A record for mail.example.com might be 203.0.113.25, the PTR record for 203.0.113.25 should resolve back to mail.example.com.

A PTR record holds a single hostname value and is meant to be the canonical name for that address. It is not a free-text label or a description; it is a fully qualified domain name that itself resolves in the normal, forward direction. That round-trip property, name to address and address back to name, is what makes reverse DNS useful as a lightweight trust signal rather than just a curiosity.

Reverse lookups do not use the same hierarchy as forward names. Instead, DNS reserves two special zones to hold PTR records: in-addr.arpa for IPv4 and ip6.arpa for IPv6. The trick is that an IP address has to be turned into a domain name so it can live in the DNS tree, and that is done by reversing it.

For IPv4, you reverse the four octets and append in-addr.arpa. The address 203.0.113.25 becomes the name 25.113.0.203.in-addr.arpa, and the PTR record lives there. The octets are reversed because DNS reads names from most specific (leftmost) to least specific (rightmost), the opposite of how IP addresses are written, so reversing keeps the network portion grouped on the right where delegation happens.

IPv6 works the same way but at the nibble level: each of the 32 hex digits of the fully expanded address becomes its own reversed label, followed by ip6.arpa. The name is long, but the principle is identical. When you run an IPv6 lookup with the Reverse DNS (PTR) tool, this nibble-reversed query is built for you automatically.

This is the single most common point of confusion. PTR records are not managed in the DNS zone for your domain. You cannot simply log in to your registrar or DNS host, add a PTR record for your IP, and be done. The authority for the in-addr.arpa and ip6.arpa zones follows IP address ownership, not domain ownership.

When a regional internet registry allocates a block of addresses to an ISP, hosting company, or cloud provider, it also delegates the corresponding reverse zone to them. That provider, the entity that actually owns or controls the IP, is the one who can publish or change the PTR record. So if you rent a server, a VPS, or an Elastic IP, the reverse DNS for that address is set by your host or cloud platform, usually through their control panel or a support request, not in your own DNS.

For larger allocations the provider may delegate the reverse zone down to you, but that delegation still originates with whoever holds the address space. The practical takeaway: to fix reverse DNS, you talk to whoever gave you the IP. You can confirm who that is, and which IP your traffic actually uses, with the IP Information tool.

A PTR record on its own is easy to fake, so mail servers do not trust it in isolation. They run a stronger check called forward-confirmed reverse DNS, or FCrDNS. It works in two steps. First, the receiving server takes the connecting IP and looks up its PTR record to get a hostname. Second, it takes that hostname and looks it up in the forward direction (A or AAAA) to get an IP. If the forward lookup returns the original connecting IP, the check passes.

Concretely: a server at 203.0.113.25 connects to deliver mail. The receiver looks up the PTR and gets mail.example.com. It then resolves mail.example.com forward and gets 203.0.113.25. The two match, so FCrDNS confirms that whoever controls this IP also legitimately controls a matching name, and that the name's owner agrees the IP belongs to it. Both halves are required, which is why a PTR pointing to a hostname that does not resolve back, or that resolves to a different address, fails the check just as surely as having no PTR at all.

Email has almost no built-in identity. Anyone can open a connection and claim to send mail from any domain, which is why receivers lean hard on signals that are difficult to forge. FCrDNS is one of the cheapest and oldest of those signals. Spammers frequently send from compromised home machines, dynamic IP ranges, and cheap hosts where reverse DNS is missing or generic, so the absence of a clean PTR correlates strongly with abuse.

Real mail servers, by contrast, are run by operators who can set a proper PTR, so receivers treat a passing FCrDNS check as a baseline sign of a legitimate, accountable sender. It does not prove the mail is wanted, but it raises the floor on the sender's reputation and is often a prerequisite before SPF, DKIM, and DMARC even get a fair hearing.

The consequences of weak reverse DNS range from subtle to brutal. The harshest receivers, including several major mailbox providers, will refuse the connection outright if there is no PTR record at all, returning an error that explicitly mentions missing reverse DNS. Others accept the mail but add a significant spam-score penalty, which can be enough to tip an otherwise clean message into the junk folder.

A generic PTR is nearly as damaging as a missing one. Default hostnames such as 203-0-113-25.dynamic.isp-example.net or a raw cloud-assigned name like ec2-203-0-113-25.compute.amazonaws.com look exactly like the dynamic and shared addresses spammers abuse. Even though they technically pass FCrDNS, many filters specifically distrust hostnames that contain the IP, words like "dynamic" or "pool," or a provider's default suffix, because real mail servers normally use a deliberate, branded name. A mismatch between forward and reverse, where the PTR points to a name that resolves elsewhere, is treated as a hard failure and is one of the most common reasons legitimate mail from a new server gets blocked.

Because you do not control the reverse zone, setup almost always means asking the right party. On a cloud platform, look for a reverse DNS or PTR field on the static IP or instance: AWS sets PTRs for Elastic IPs through a request form (and usually wants matching forward DNS in place first), while Google Cloud, Azure, and most VPS providers expose a PTR field in their console. With a traditional hosting company or ISP, you typically open a support ticket asking them to set the PTR for your IP to a specific hostname.

Whatever hostname you choose, make sure it is real and matched. Create a forward A (or AAAA) record for that hostname pointing to the same IP, using a name in a domain you control, ideally something deliberate like mail.example.com rather than a generic label. Then have the provider set the PTR to that exact name. Get both halves agreeing and FCrDNS will pass. You can sanity-check the forward record you create with the DNS Lookup tool before and after the PTR goes live.

One caveat for senders with many IPs: each sending address needs its own correct PTR. A pool of outbound mail servers should each resolve to a distinct, valid hostname that resolves back, not a single shared name that only matches one of them.

After making a change, verify it rather than assuming. Run your IP through the Reverse DNS (PTR) tool to see the PTR record and confirm it returns the hostname you expect; then check that the hostname resolves forward to the same address so you know FCrDNS will pass. Reverse-DNS changes can take time to propagate because of caching, so if a fresh PTR does not show up immediately, give it a little while and check again.

Reverse DNS is necessary but not sufficient for good deliverability, so confirm the rest of your mail posture too. Use the MX Lookup tool to verify your domain's mail routing points at the right hosts and that those hosts line up with the IPs actually sending. And because a clean PTR will not save an address that is already on a blocklist, scan your sending IP with the IP Blacklist Check tool to catch any listings. Fixing reverse DNS, aligning forward and reverse records, and keeping the IP off blocklists together form the foundation that SPF, DKIM, and DMARC build on top of.