Reverse DNS maps an IP address back to a hostname, the opposite of the forward lookups most people think of. For IPv4 this lives in the in-addr.arpa zone and feels familiar. IPv6 does the same job in the ip6.arpa zone, but the format trips people up because it works one hex digit at a time, reversed, with a dot between every digit. This guide explains how IPv6 PTR records are built, why reverse DNS still matters even in an IPv6 world, and how to create and verify an entry correctly.
How the ip6.arpa name is built
An IPv6 address is 128 bits, written as eight groups of four hex digits. A single hex digit represents four bits and is called a nibble. IPv6 reverse DNS works at nibble granularity: you expand the address to its full 32 nibbles, reverse the whole string, place a dot after each nibble, and append ip6.arpa. That is the pointer domain name whose PTR record holds the hostname.
The process is mechanical once you see it:
- Expand the address fully. Restore every
::shorthand to its zeroes and pad each group to four digits, so no abbreviation remains. - Remove the colons, leaving one continuous string of 32 hex digits.
- Reverse that string, digit by digit.
- Put a dot between every digit, then add
ip6.arpaat the end.
Take 2001:db8::567:89ab as the worked example. Expanded, it becomes 2001:0db8:0000:0000:0000:0000:0567:89ab. Reversed into nibble format, its pointer name is:
b.a.9.8.7.6.5.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.IPv4 and IPv6 reverse zones side by side
| Aspect | IPv4 (in-addr.arpa) | IPv6 (ip6.arpa) |
|---|---|---|
| Unit of the label | Octet (8 bits, decimal) | Nibble (4 bits, one hex digit) |
| Labels in a full address | 4 | 32 |
| Order | Octets reversed | Nibbles reversed |
| Example suffix | .in-addr.arpa | .ip6.arpa |
| Record type | PTR | PTR |
The record type is identical. Only the way you encode the address into a name differs, and IPv6 simply uses far more, far smaller labels.
Why IPv6 reverse DNS still matters
It would be tempting to skip reverse DNS for IPv6 given how tedious the names are, but one audience cares a great deal: receiving mail servers. Many of them reject or heavily penalize mail from a sending IP that has no PTR record, or whose PTR does not forward-confirm. Forward-confirmed reverse DNS (FCrDNS) means the PTR points to a hostname, and that hostname's forward AAAA record points back to the same IP. If you send email over IPv6, a correct PTR is close to mandatory for deliverability.
Beyond email, reverse DNS aids logging and diagnostics: traceroutes, server logs, and monitoring tools are far more readable when addresses resolve to names. It is a courtesy to anyone reading your traffic and a requirement for your outbound mail.
There is a scale factor worth understanding too. An IPv6 allocation is enormous, and nobody populates a PTR for every one of the trillions of possible addresses in a block. In practice you publish reverse records only for the specific addresses that actually send traffic or mail, and you leave the rest without a PTR. Some operators go further and have their nameserver synthesize a generic PTR for any address in a block, but for a sending mail server you want a real, deliberate name that forward-confirms, not an auto-generated placeholder.
How reverse zones get delegated
Reverse delegation in IPv6 follows nibble boundaries. A provider that assigns you a /48 can delegate the matching reverse zone to your nameservers, and because /48 lands on a clean nibble boundary (12 nibbles of prefix), the delegation is tidy. Less tidy prefixes that do not fall on a four-bit boundary require the provider to delegate at the nearest nibble and manage the remainder, which is why many providers prefer to expose a PTR field in their panel rather than delegate the whole reverse zone to each customer.
Creating the PTR record
Reverse zones for your addresses are almost always controlled by whoever assigned the block to you: your ISP, hosting provider, or cloud platform. Many of them either expose a field where you set the PTR directly, or delegate the reverse zone to you so you run it yourself. In a zone file the entry looks like this, using the full reversed nibble name:
; Reverse zone for 2001:db8::1 pointing at mail.example.com
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. IN PTR mail.example.com.
; Do not forget the matching forward record so FCrDNS passes:
mail.example.com. IN AAAA 2001:db8::1For a mail server, publish both halves. The PTR gives the name, and the forward AAAA confirms it. If the two disagree, a strict receiver treats the reverse DNS as failing even though a PTR exists.
Verifying the entry
You never have to type the reversed nibble name by hand to check it. Both dig and nslookup accept the plain address with a reverse flag and build the ip6.arpa name for you.
# dig: -x takes the address directly
$ dig -x 2001:db8::1 +short
mail.example.com.
# Or query the full pointer name explicitly
$ dig PTR 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. +short
mail.example.com.
# Confirm the forward side agrees, completing FCrDNS
$ dig AAAA mail.example.com +short
2001:db8::1On Windows the equivalent is nslookup 2001:db8::1, which performs the reverse lookup automatically. When both the PTR and the matching AAAA resolve to each other, your reverse DNS is complete and forward-confirmed.
Common mistakes
- Forgetting to expand the address. You must restore every zero that
::hid. A reversed name with the wrong number of nibbles is simply the wrong name. - Reversing groups instead of nibbles. IPv6 reverses individual hex digits, not four-digit groups. Each digit is its own dotted label.
- Setting the PTR but not the forward AAAA. Mail receivers want both halves to match. A lone PTR often is not enough.
- Assuming you control the reverse zone. The block owner usually does. If your provider has not delegated it to you, you must set the PTR through their panel or support.
Confirm your reverse records resolve
Once the PTR and the matching forward record are in place, confirm they resolve consistently rather than trusting a single local lookup. Run the address and the hostname through the Valla DNS lookup and propagation tools to verify the PTR appears everywhere and the forward AAAA agrees, and pair this with our guides on PTR records and reverse DNS for mail and on why mail servers need them before you rely on IPv6 for sending email.