Understanding Reverse DNS (rDNS) and PTR Records

Most DNS work goes in one direction: you have a name such as example.com and you want its IP address. Reverse DNS goes the other way. Given an IP address, it answers the question “what hostname belongs to this address?” It sounds like a small detail, yet reverse DNS quietly influences whether your email reaches inboxes, how readable your server logs are, and how trustworthy your infrastructure looks to other systems.

This guide explains how reverse DNS works under the hood, who is actually allowed to set it, why mail servers care so much about it, and how to check and request the right configuration. If you are new to record types, start with our guide to DNS record basics.

What reverse DNS and PTR records are

A normal (forward) lookup uses an A record for IPv4 or an AAAA record for IPv6 to turn a name into an address. A reverse lookup uses a PTR record (pointer record), which turns an address into a name.

For example, the forward record might say that mail.example.com points to 203.0.113.25. The matching PTR record says that 203.0.113.25 points to mail.example.com. These are two separate records, stored in two separate places, often managed by two different organisations. Updating one never updates the other automatically.

An IP address usually has a single PTR record. Multiple PTR records for one address are technically allowed but often cause inconsistent results, so the common practice is one clear hostname per IP.

How in-addr.arpa and ip6.arpa work

DNS is built around names, not numbers, so reverse lookups need a trick: the IP address is rewritten as a domain name inside special zones.

IPv4: in-addr.arpa

For IPv4, the four octets are reversed and the suffix in-addr.arpa is added. The address 203.0.113.25 becomes:

25.113.0.203.in-addr.arpa.  IN  PTR  mail.example.com.

The reversal matters because DNS delegates from right to left. Reversing the octets lets the zone for 113.0.203.in-addr.arpa (the whole /24 network) be delegated to whoever owns that range, just as example.com is delegated under .com.

IPv6: ip6.arpa

For IPv6, the address is expanded to all 32 hexadecimal digits, each digit becomes its own label, the order is reversed, and ip6.arpa is appended. The address 2001:db8::1 becomes a long name ending in ...8.b.d.0.1.0.0.2.ip6.arpa. It looks intimidating, but tools generate it for you, and providers usually let you set IPv6 PTR records through a simple form.

Who controls PTR records

This is the point that confuses most people. Owning a domain does not let you set reverse DNS for the IP your domain points to. Reverse zones follow the allocation of IP addresses: regional internet registries such as RIPE NCC, ARIN or APNIC allocate address blocks to providers, and they delegate the matching reverse zones to those providers.

In practice this means:

• On a VPS, dedicated server or cloud instance, your provider controls the reverse zone, but usually lets you set the PTR for your assigned IP in the control panel.
• On shared hosting, many sites share one IP, so the PTR normally points to the provider’s own server hostname and cannot be changed by individual customers.
• On a home or office connection, the ISP sets a generic PTR (often containing the IP and words like “dynamic” or “pool”). Business plans with static IPs may allow custom PTRs on request.
• If your organisation holds its own IP space, the registry can delegate the reverse zone to your own nameservers.

If you are unsure who operates an IP, the TLDix hosting lookup shows which network and provider the address belongs to, so you know whom to contact.

Forward-confirmed reverse DNS (FCrDNS)

A PTR record alone proves little, because anyone who controls an IP range can make it point to any name, including names they do not own. Forward-confirmed reverse DNS closes that gap with a two-step check:

1. Look up the PTR for the IP: 203.0.113.25 gives mail.example.com.
2. Look up the A (or AAAA) record for that hostname: mail.example.com must return 203.0.113.25.

When both directions agree, the IP and hostname are confirmed to belong together, because the forward record could only be set by the domain owner. Many receiving systems treat a matching pair as a basic sign of a properly run server.

Why rDNS matters for email deliverability

Email is where reverse DNS matters most. Receiving mail servers commonly check the connecting IP before accepting a message, and a missing or generic PTR is a frequent reason for rejection or spam-folder placement. Large mailbox providers, including Gmail, state in their sender guidelines that sending IPs should have valid forward and reverse DNS that match.

For a server that sends mail, aim for this setup:

• The sending IP has a PTR record pointing to a real hostname, such as mail.example.com.
• That hostname has an A or AAAA record pointing back to the same IP (FCrDNS).
• The hostname the mail server announces in its SMTP greeting (HELO/EHLO) ideally matches the PTR name.
• Avoid generic-looking names that include the IP address or words such as “dynamic”, which some filters treat as residential connections.

Reverse DNS works alongside SPF, DKIM and DMARC; it does not replace them. A correct PTR will not rescue a poor sending reputation, but a missing one can sink otherwise legitimate mail. If you send through a service such as a transactional email provider, it manages rDNS on its own sending IPs.

How to check reverse DNS

The quickest method is dig with the -x option, which builds the in-addr.arpa or ip6.arpa name for you:

dig -x 203.0.113.25 +short
dig -x 2001:db8::1 +short

Then confirm the forward direction:

dig mail.example.com A +short

On Windows, nslookup 203.0.113.25 gives the same answer, and on many systems host 203.0.113.25 works too. If the PTR query returns nothing, no reverse record exists. If it returns a hostname that does not resolve back to the IP, FCrDNS fails and you should fix one side or the other.

How to request or set a PTR record

Because the IP holder controls the reverse zone, the process depends on your provider:

1. Create the forward record first. Add an A or AAAA record such as mail.example.com pointing to your server IP. Many providers refuse to set a PTR until the forward record exists.
2. Find the setting. Cloud and VPS providers often call it “Reverse DNS” or “PTR” in the network or IP section of the panel.
3. Open a ticket if needed. If there is no self-service option, ask support to set the PTR for your IP and give the exact hostname.
4. Wait for caches. Like any DNS change, the new PTR may take time to appear everywhere, depending on the TTL of the old record. See how DNS TTL settings work for details.
5. Verify both directions with dig -x and a forward lookup.

Other uses of reverse DNS

Beyond email, rDNS makes logs and network tools more readable: traceroute output, firewall logs and analytics show hostnames instead of bare numbers. Some services use it to recognise genuine crawlers, for example by checking that a visitor claiming to be a search engine bot has a PTR in the search engine’s domain and that the name resolves back to the same IP. Security teams also use it to quickly see which provider or network a suspicious address belongs to.

Reverse DNS is easy to overlook because it lives outside your domain’s zone. A few minutes spent setting a clean, matching PTR for every server that sends mail or offers public services is one of the most cost-effective bits of DNS hygiene you can do. While you are at it, checking your domain details with the TLDix domain lookup helps keep the forward side of the picture accurate too.