What is a PTR record and how does reverse DNS work?

A PTR (pointer) record is a DNS record that maps an IP address back to a hostname. It's the opposite of an A or AAAA record: instead of asking "what is the address of mail.example.com?", a reverse DNS lookup asks "what name belongs to 198.51.100.25?". PTR records live in special reverse zones under in-addr.arpa for IPv4 and ip6.arpa for IPv6, and they're controlled by whoever owns the IP address, not whoever owns the domain.

Reverse DNS matters most for email, where receiving servers routinely reject or penalise mail from IP addresses without a sensible PTR record, but it also shows up in logs, traceroutes, and security tools. In this article you'll learn how reverse lookups are structured, how IPv4 and IPv6 reverse names are built, who you need to ask to set a PTR record, what forward-confirmed reverse DNS is and why mail servers check it, how to run your own reverse zone, and how to test everything from the command line.

How Reverse DNS Works

DNS is built for looking up names, not numbers. To make reverse lookups possible, IP addresses are turned into names inside a dedicated part of the DNS tree, and PTR records are published at those names.

IPv4: in-addr.arpa

For an IPv4 address, you reverse the four octets and append .in-addr.arpa:

IP address	Reverse lookup name
198.51.100.25	25.100.51.198.in-addr.arpa
192.0.2.10	10.2.0.192.in-addr.arpa
203.0.113.7	7.113.0.203.in-addr.arpa

The octets are reversed because DNS names are read from right to left in terms of hierarchy. Reversing the address puts the most significant part, the network, closest to the root. That lets the delegation follow the way addresses are allocated: the regional internet registry is responsible for 198.in-addr.arpa, a provider might hold 100.51.198.in-addr.arpa for a whole /24, and so on.

The PTR record itself is simple:

25.100.51.198.in-addr.arpa.    3600    IN    PTR    mail.example.com.

IPv6: ip6.arpa

IPv6 uses the same idea, but works in nibbles (single hexadecimal digits). You expand the address to all 32 hex digits, reverse them, separate each with a dot, and append .ip6.arpa. The address 2001:db8::25 becomes:

5.2.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

Nobody writes these by hand. Tools generate them for you, and you can do it in Python with the standard library:

import ipaddress

for ip in ["198.51.100.25", "2001:db8::25"]:
    print(ipaddress.ip_address(ip).reverse_pointer)

25.100.51.198.in-addr.arpa
5.2.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

Who Controls Your PTR Records

This is the part that surprises most people. Owning a domain doesn't let you set reverse DNS for an IP address. The reverse zone for an address belongs to the organisation the address block was allocated to, which is usually your hosting provider, cloud platform, or ISP.

That means:

• You can't add a PTR record in your normal DNS provider's dashboard for example.com. It would have no effect, because resolvers never look in your zone for reverse names.
• You set PTR records through whoever owns the IP: a setting in your cloud console, a support ticket with your ISP, or your own nameservers if the block has been delegated to you.
• Home broadband connections usually get a generic PTR, such as host-198-51-100-25.isp.example.net, which you can't change.

Setting Reverse DNS on Common Platforms

Most cloud and VPS providers expose reverse DNS as a setting on the server or IP address:

• AWS: Elastic IP addresses support a reverse DNS setting. The forward record must already point at the Elastic IP before AWS will accept it.
• DigitalOcean: The PTR for a Droplet's IP is set automatically from the Droplet's name, so name the Droplet with the fully qualified hostname you want.
• Most VPS hosts: Hetzner, Linode (Akamai), Vultr, OVHcloud and others have a reverse DNS field per IP in their control panels.

On AWS, you can set it with the CLI:

aws ec2 modify-address-attribute \
  --allocation-id eipalloc-0123456789abcdef0 \
  --domain-name mail.example.com

And check its status:

aws ec2 describe-addresses-attribute \
  --allocation-ids eipalloc-0123456789abcdef0 \
  --attribute domain-name

The change can take a little while to become active, as AWS verifies the forward record first.

Why Reverse DNS Matters for Email

Receiving mail servers check the reverse DNS of every connecting IP address. It's one of the cheapest and oldest spam signals available, because large botnets of compromised home computers rarely have meaningful PTR records.

Forward-Confirmed Reverse DNS

The check most mail servers perform is forward-confirmed reverse DNS (FCrDNS), sometimes called "full-circle" reverse DNS:

1. Look up the PTR record for the connecting IP, for example 198.51.100.25 returns mail.example.com.
2. Look up the A (or AAAA) record for that name, mail.example.com.
3. Check that the result includes the original IP, 198.51.100.25.

If all three line up, the IP and the name confirm each other. Someone could publish a PTR claiming any name they like, but they can't create an A record in a domain they don't control, so the round trip proves both sides agree.

Major mailbox providers treat this seriously. Google's sender guidelines, for example, require that sending IPs have valid forward and reverse DNS records, and messages from IPs that fail are likely to be rejected or sent to spam.

Matching the SMTP Greeting

Mail servers announce themselves with a hostname in the EHLO command. It's good practice for this name to match the PTR record. In Postfix, it's set with myhostname:

# /etc/postfix/main.cf
myhostname = mail.example.com

The full set of names for a well-configured sending server then lines up:

; Forward zone (example.com, managed by you)
mail.example.com.               3600  IN  A     198.51.100.25
mail.example.com.               3600  IN  AAAA  2001:db8::25

; Reverse zones (managed by the IP owner)
25.100.51.198.in-addr.arpa.     3600  IN  PTR   mail.example.com.
5.2.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. 3600 IN PTR mail.example.com.

If your server sends over IPv6, it needs a PTR for its IPv6 address too. Missing IPv6 reverse DNS is a common reason mail to Gmail fails while IPv4 delivery works.

Other Uses of Reverse DNS

Email is the main reason to care, but PTR records show up elsewhere:

• Logs and analytics: Web servers and firewalls can resolve client IPs to names, which makes logs easier to read.
• Traceroute and MTR: Router hostnames often encode location and link details, which helps network engineers diagnose routing.
• Access control: Some older services, such as SSH with UseDNS yes or TCP wrappers, look up client names. This is unreliable for security, because PTR records are controlled by the IP owner, and it slows down connections when reverse DNS is broken.
• Verifying crawlers: Search engines recommend confirming that a visitor claiming to be their crawler has a PTR in their domain and that the forward lookup matches, which is the same FCrDNS check mail servers use.

Looking Up PTR Records

With dig

The -x option builds the reverse name for you:

dig -x 198.51.100.25 +noall +answer

25.100.51.198.in-addr.arpa. 3600 IN PTR mail.example.com.

It works for IPv6 too:

dig -x 2001:db8::25 +short

mail.example.com.

To see who's responsible for the reverse zone, ask for its SOA record:

dig -x 198.51.100.25 SOA +noall +authority

With host and nslookup

host 198.51.100.25

25.100.51.198.in-addr.arpa domain name pointer mail.example.com.

nslookup 198.51.100.25

With PowerShell

Resolve-DnsName -Name 198.51.100.25 -Type PTR

A Forward-Confirmed Reverse DNS Check

This Bash script performs the same round trip a mail server does:

#!/usr/bin/env bash
ip="$1"
name=$(dig -x "$ip" +short | head -n1)

if [ -z "$name" ]; then
  echo "FAIL: no PTR record for $ip"
  exit 1
fi

if [[ "$ip" == *:* ]]; then
  forward=$(dig "$name" AAAA +short)
else
  forward=$(dig "$name" A +short)
fi

if echo "$forward" | grep -qx "$ip"; then
  echo "PASS: $ip -> $name -> $ip"
else
  echo "FAIL: $ip -> $name, but $name resolves to: ${forward:-nothing}"
  exit 1
fi

chmod +x fcrdns.sh
./fcrdns.sh 198.51.100.25

PASS: 198.51.100.25 -> mail.example.com. -> 198.51.100.25

For IPv6, the comparison needs the address in the same compressed form dig returns, which is the standard short form such as 2001:db8::25.

Running Your Own Reverse Zone

If your organisation has its own address space, or a provider delegates a block to you, you can serve reverse DNS on your own nameservers. In BIND, a reverse zone is just another zone:

// /etc/bind/named.conf.local
zone "100.51.198.in-addr.arpa" {
    type primary;
    file "/etc/bind/zones/db.198.51.100";
};

; /etc/bind/zones/db.198.51.100
$TTL 3600
@   IN  SOA  ns1.example.com. hostmaster.example.com. (
             2026101301 7200 3600 1209600 3600 )
@   IN  NS   ns1.example.com.
@   IN  NS   ns2.example.com.

10  IN  PTR  www.example.com.
25  IN  PTR  mail.example.com.
53  IN  PTR  ns1.example.com.

Names without a trailing dot, such as 25, are relative to the zone, so 25 means 25.100.51.198.in-addr.arpa.. The targets must have trailing dots, or they'll be treated as relative names too.

Validate and load it:

sudo named-checkzone 100.51.198.in-addr.arpa /etc/bind/zones/db.198.51.100
sudo rndc reload

The zone only takes effect publicly once the parent, usually your provider or the regional internet registry, delegates it to your nameservers.

Blocks Smaller Than a /24

Reverse delegation follows octet boundaries, so a customer with only a /26 can't simply be given its own in-addr.arpa zone. RFC 2317 describes the standard workaround: the provider creates CNAME records in its /24 zone that point into a sub-zone it delegates to you.

; In the provider's 113.0.203.in-addr.arpa zone
0-63    IN  NS     ns1.example.com.
0-63    IN  NS     ns2.example.com.
1       IN  CNAME  1.0-63.113.0.203.in-addr.arpa.
2       IN  CNAME  2.0-63.113.0.203.in-addr.arpa.

You then publish the actual PTR records in a zone called 0-63.113.0.203.in-addr.arpa on your own servers. Resolvers follow the CNAME and find your PTR.

Common Reverse DNS Mistakes

1. Adding PTR records at your domain's DNS provider: They won't be used. Set reverse DNS with the IP owner.
2. No matching forward record: A PTR pointing to a name that doesn't resolve back to the same IP fails FCrDNS.
3. Forgetting IPv6: Mail servers that send over IPv6 need IPv6 PTR records too.
4. Generic PTRs on mail servers: A name like ip-198-51-100-25.provider.example.net looks like a dynamic address to spam filters. Use your own hostname.
5. Multiple PTR records for one IP: Allowed, but many tools only read the first one, and the order isn't guaranteed. Keep one PTR per address.
6. Relying on reverse DNS for security: The IP owner controls the PTR, so treat it as a hint, never as proof of identity, unless you also confirm the forward lookup.

---

FAQ: PTR Records and Reverse DNS

---

Conclusion

A PTR record turns an IP address back into a name, using the reversed-address naming of in-addr.arpa and ip6.arpa. The key point to remember is that reverse DNS belongs to whoever owns the IP address, so you set it through your hosting provider or ISP rather than your domain's DNS host.

If you run a mail server, make sure every sending IP, IPv4 and IPv6, has a PTR record that points to your own hostname and that the hostname resolves back to the same address. Test it with dig -x and a quick forward-confirmed check, and you'll remove one of the most common reasons legitimate mail gets rejected.