What are PTR records, and when are they used?

Most DNS records answer the question "what's the IP address for this domain?" A PTR record answers the opposite question: "what domain is this IP address associated with?" It's a small, easy-to-overlook record type, but it quietly plays an outsized role in email deliverability, network diagnostics, and security tooling. This article covers what PTR records are, how reverse DNS lookups actually work under the hood, and the situations where a missing or misconfigured PTR record can cause real problems.

What Is a PTR Record?

A PTR (Pointer) record is a DNS record type that maps an IP address to a hostname — the reverse of an A record, which maps a hostname to an IP address. This process is called a reverse DNS lookup (or rDNS), and it's the mechanism behind the dig -x or nslookup <ip> commands you may have already used without realizing they were querying PTR records.

Unlike most DNS records, a PTR record isn't configured in your domain's zone file. It lives in a special reverse-lookup zone tied to the IP address's owner — usually your ISP, hosting provider, or cloud platform — because that's who is authoritative for the IP address space, not the domain owner.

How Reverse DNS Lookups Work

Forward DNS resolves names to numbers using zones like example.com. Reverse DNS needs a way to represent IP addresses as domain names so the same DNS hierarchy can be reused. It does this with a special top-level domain:

• IPv4 addresses use in-addr.arpa, with the octets of the IP reversed.
• IPv6 addresses use ip6.arpa, with each hex nibble reversed.

For example, the IPv4 address 203.0.113.25 becomes the following reverse DNS name:

25.113.0.203.in-addr.arpa

A resolver looking up the PTR record for 203.0.113.25 is really just asking for the PTR record of 25.113.0.203.in-addr.arpa — the octets are reversed because DNS zones delegate from general to specific, left to right (arpa → in-addr → 203 → 0 → 113 → 25), while IP addresses are written most-significant-octet first.

IPv6 follows the same idea but is far more verbose, since each hex digit ("nibble") of the address gets its own reversed label. The IPv6 address 2001:db8::1 expands to:

1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.8.b.d.0.1.0.0.2.ip6.arpa

PTR Record Syntax and a Zone File Example

A PTR record's zone file entry is straightforward — it looks a lot like an A record, just flipped:

; Reverse zone file for 203.0.113.0/24
$TTL 3600
@   IN  SOA   ns1.example.com. admin.example.com. (
        2026090701 ; serial
        3600       ; refresh
        900        ; retry
        604800     ; expire
        3600 )     ; minimum TTL

    IN  NS    ns1.example.com.

25  IN  PTR   mail.example.com.
26  IN  PTR   www.example.com.

Here, 25 and 26 are shorthand for the last octet in the 113.0.203.in-addr.arpa zone, so the full record for the first line is 25.113.0.203.in-addr.arpa. IN PTR mail.example.com. — meaning a reverse lookup on 203.0.113.25 returns mail.example.com.

How to Look Up a PTR Record

You can query PTR records the same way you'd query any other DNS record, using standard command-line tools.

Using dig:

dig -x 203.0.113.25 +short

Using nslookup:

nslookup 203.0.113.25

Using host:

host 203.0.113.25

Any of these should return the hostname associated with that IP, if a PTR record exists. If nothing is configured, you'll get NXDOMAIN or a "no reverse DNS" style message instead.

You can also do a reverse lookup programmatically. Here's a small Python example using the standard library:

import socket

ip_address = "203.0.113.25"

try:
    hostname, aliases, addresses = socket.gethostbyaddr(ip_address)
    print(f"PTR record found: {hostname}")
except socket.herror:
    print("No PTR record configured for this IP")

socket.gethostbyaddr() performs the reverse lookup and raises socket.herror if the address has no PTR record — useful if you're building monitoring or validation tooling that needs to check rDNS in bulk.

When Are PTR Records Used?

PTR records aren't required for a website or app to function, but they matter in a handful of specific, high-stakes situations:

1. Email deliverability and anti-spam filtering. This is the most common reason PTR records matter. Most major mail providers (Gmail, Outlook, and others) check whether the sending mail server's IP has a valid PTR record that resolves to a hostname, and whether that hostname's A record resolves back to the original IP (a check called forward-confirmed reverse DNS, or FCrDNS — more on that below). Mail servers with missing or mismatched PTR records are frequently flagged as spam or rejected outright.
2. Network troubleshooting and logging. When you're reading server logs, firewall logs, or running traceroute, seeing mail-relay-03.example.com is a lot more useful than seeing 203.0.113.25. Reverse DNS makes raw IP addresses in logs human-readable, which speeds up incident response.
3. Security and abuse investigation. Threat intelligence tools and abuse-report systems use PTR records to identify the organization or hosting provider behind an IP address making suspicious connections — often the first step in tracing an attack back to its source.
4. VoIP and SIP trust checks. Some SIP trunk providers validate reverse DNS on the IP addresses of connecting servers as a lightweight trust signal before accepting call traffic.
5. Compliance and audit trails. Some regulated environments require accurate rDNS on server infrastructure so that connection logs can be reliably attributed to identifiable, named hosts.

How to Set Up a PTR Record

Since PTR records live in a reverse zone controlled by whoever owns the IP address block, you generally can't add one through your domain registrar's DNS panel the way you would an A or MX record. Instead:

• On a cloud platform or VPS (AWS, DigitalOcean, Hetzner, etc.), look for a "reverse DNS" or "PTR record" setting attached to the specific IP in your provider's control panel or API.
• On a dedicated server or IP block from an ISP, submit a support request asking them to set the PTR record for your IP to your desired hostname.
• On shared hosting, the PTR record is usually already set by the host to a generic value and isn't user-configurable.

Whichever route you take, make sure the hostname resolves back to that same IP via a forward A/AAAA record — a mismatch is often treated as suspicious by mail servers and security tools.

Advanced Considerations

Forward-Confirmed Reverse DNS (FCrDNS)

Many mail servers don't just check that a PTR record exists — they verify it's consistent. This two-step check is called FCrDNS:

1. Look up the PTR record for the connecting IP → get a hostname.
2. Look up the A record for that hostname → confirm it resolves back to the same IP.

You can replicate this check manually:

# Step 1: reverse lookup
dig -x 203.0.113.25 +short
# → mail.example.com.

# Step 2: forward lookup to confirm
dig mail.example.com A +short
# → 203.0.113.25

If both steps line up, the IP passes FCrDNS. If they don't match — or the forward lookup fails entirely — many spam filters treat the mismatch as a red flag.

IPv6 PTR Records

Because ip6.arpa reverse zones are written one nibble per label, they're tedious to write by hand and easy to get wrong. Most DNS providers offer a shorthand where you supply the full IPv6 address and they generate the correct nibble-reversed zone entry for you — it's worth using that tooling rather than constructing ip6.arpa names manually.

Common Misconfigurations

• Generic or missing PTR records on mail-sending IPs — one of the most common causes of outbound mail landing in spam folders.
• PTR pointing to a hostname with no matching forward record, breaking FCrDNS checks.
• Stale PTR records left over after an IP is reassigned to a different server or customer.
• One IP, one PTR record — unlike forward DNS, an IP can only have a single PTR record, unlike the multiple A records that can point at one IP.

---

PTR Records FAQ

Conclusion

PTR records don't get nearly as much attention as A, CNAME, or MX records, but they solve a real problem: letting anything on the internet ask "who is this IP address?" and get a useful answer. For most day-to-day web hosting, you can go a long time without ever thinking about reverse DNS. The moment you start sending outbound email from your own server, though, a correctly configured PTR record — one that matches your forward DNS and passes an FCrDNS check — becomes one of the simplest, highest-impact things you can do for deliverability. It's also worth setting up correctly on any server-facing infrastructure, since it makes your own logs, monitoring, and incident response noticeably easier to read.

Here are some useful references for going deeper on PTR records and reverse DNS:

1. Cloudflare Learning Center: What is a PTR record? — a concise explainer of PTR records and reverse DNS lookups.
2. DigitalOcean Community Tutorial: An Introduction to DNS Terminology, Components, and Concepts — covers reverse DNS in the context of broader DNS concepts.
3. RFC 1035: Domain Names - Implementation and Specification — the original IETF specification defining PTR records and the in-addr.arpa domain.
4. RFC 3596: DNS Extensions to Support IP Version 6 — defines the ip6.arpa reverse zone used for IPv6 PTR records.
5. MXToolbox: Reverse DNS Lookup — a free tool for checking the PTR record of any IP address.