This article is a localized edition of the Japanese original. Read the Japanese original
A PTR record (reverse DNS) is added not in your domain's DNS but in the reverse zone managed by the owner of the IP address. With a VPS or cloud, you do it in the provider's control panel or by request; if reverse delegation has been handed to you, you write it in the zone on your own DNS server. This article first shows how to use dig to find out where you can add a PTR, then explains how to write it when you manage the reverse zone yourself (in-addr.arpa for IPv4, ip6.arpa for IPv6, and how blocks smaller than a /24 are handled), and how to verify it after adding.
PTR is mainly required by mail servers. If the sending IP address has no reverse record, or it does not match the forward record, the receiving side may treat the mail as spam or reject it.
Who can add a PTR
A common misunderstanding is "you just add the PTR in your domain's DNS control panel." The name for reverse lookup is built from the IP address, like 10.113.0.203.in-addr.arpa, and the authority to manage it lies with whoever you reach by following the IP address allocation, that is, the network provider or hosting provider. Even if you write a PTR in the domain's zone, nobody will ever look it up.
You can find out which name server is responsible for the reverse zone of your IP address as follows.
# Follow from the root to see who the reverse name is delegated to
dig -x 203.0.113.10 +trace
# Directly look up the name servers of the reverse zone (example for a /24)
dig 113.0.203.in-addr.arpa NS +shortIf the name servers shown belong to the provider, set the PTR in the provider's control panel or request window. If they are your own name servers, add it to the zone using the steps in the second half of this article.
For VPS and cloud
With many VPS and cloud services, the server or IP address settings screen has items such as "reverse lookup" or "reverse DNS," and you can set it just by entering a hostname. The names and locations of the items differ by service and may change (as of October 2026). If there is no such item on the screen, some services accept it as a request to support.
Even when it is set on the provider's side, it is often a prerequisite that you register the forward record (the hostname's A or AAAA record) first. This is because some services have a mechanism to check that the hostname returned by the reverse lookup resolves forward to the same IP address.
Work out the reverse name
To write a PTR in a reverse zone, convert the IP address into its reverse name.
IPv4: Put the four numbers in reverse order and append in-addr.arpa. 203.0.113.10 becomes 10.113.0.203.in-addr.arpa. For a /24 allocation, the zone name is 113.0.203.in-addr.arpa and the record name inside it is 10.
IPv6: Expand the address into 32 hexadecimal digits with nothing omitted, separate each digit (nibble) with a dot in reverse order, and append ip6.arpa. It is easy to get wrong by hand, so converting with a tool is safer.
python3 -c "import ipaddress; print(ipaddress.ip_address('2001:db8::25').reverse_pointer)"
# 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.arpadig -x also accepts an IPv6 address as is and does the same conversion internally.
Add a PTR to a BIND reverse zone
This is an example for when you have been given reverse delegation and run an authoritative DNS server with BIND. Before you start, make copies of the configuration file and the zone file and keep them. If possible, check the syntax on a test server before applying it to production.
First, define the reverse zone in named.conf (or named.conf.local or similar, depending on the distribution).
zone "113.0.203.in-addr.arpa" {
type primary;
file "/etc/bind/zones/db.203.0.113";
};In older BIND, type primary is written as type master. Match the syntax of the version you use.
In the zone file, put the SOA and NS just as in a forward zone, and line up the PTR records below them.
$TTL 3600
@ IN SOA ns1.example.com. hostmaster.example.com. (
2026101801 ; serial number (increase it with every change)
3600 ; refresh
900 ; retry
1209600 ; expire
3600 ) ; negative cache TTL
IN NS ns1.example.com.
IN NS ns2.example.com.
10 IN PTR mail.example.com.
11 IN PTR web.example.com.Write the PTR value as a complete hostname with a trailing dot. Without the dot, the zone name is appended and it becomes mail.example.com.113.0.203.in-addr.arpa..
When you finish writing, check the syntax and then load it.
named-checkconf
named-checkzone 113.0.203.in-addr.arpa /etc/bind/zones/db.203.0.113
rndc reload 113.0.203.in-addr.arpaEven when you are only adding one PTR to an existing zone, do not forget to increase the serial number. If you do not, the secondary name servers will not pick up the change, and different servers will give different answers.
Blocks smaller than a /24
If your allocation is smaller than a /24, such as a /28 or /29, you cannot have the whole 113.0.203.in-addr.arpa zone delegated to you. The method commonly used in this case is the one described in RFC 2317.
The upstream provider, inside its own /24 zone, points the name of each relevant address to an alias with a CNAME, and delegates a subzone containing those aliases to the customer's name server.
; The provider's 113.0.203.in-addr.arpa zone (example: delegating a /28)
0-15 IN NS ns1.example.com.
10 IN CNAME 10.0-15.113.0.203.in-addr.arpa.On the customer side, create a zone named 0-15.113.0.203.in-addr.arpa and write 10 IN PTR mail.example.com. in it. How the subzone is named (0-15, 0/28, and so on) is decided by the provider, so confirm the name before you accept the delegation and create the zone exactly as specified. If the names do not match, the CNAME's destination cannot be found and the reverse lookup fails.
PTR for IPv6
With IPv6, it is common to be delegated an ip6.arpa zone in units of /64 or /48. For example, for 2001:db8:1234::/48, the zone name is 4.3.2.1.8.b.d.0.1.0.0.2.ip6.arpa, and the record name inside the zone is the remaining 20 digits in reverse order.
Because IPv6 has an enormous number of addresses in a single network, you do not need to write a PTR for all of them. Add them only for the addresses that are asked for reverse lookup, such as mail servers. If a mail-sending server also sends over IPv6, unless you also prepare a PTR for the IPv6 address, delivery over IPv6 alone may be rejected.
Checking after you add it
# Check the reverse lookup through a caching DNS
dig -x 203.0.113.10 +short
# Query the authoritative server of the reverse zone directly
dig @ns1.example.com -x 203.0.113.10 +norecurse +noall +answer
# Resolve the returned hostname forward and check that it returns to the original IP address
dig mail.example.com A +shortThe points to check are as follows.
- Does the reverse lookup return exactly one intended hostname? You can write multiple PTRs for one IP address, but the receiving side's judgment becomes unstable, so keep it to one.
- Does the forward lookup of that hostname return the same IP address?
- If it is correct on the authoritative server but old on the caching DNS, wait until the TTL of the previous PTR expires.
Common stumbling points
- You wrote it in the domain's zone: Use the method in the first section to check which name server is responsible for the reverse lookup.
- It is not delegated: Even if you create a reverse zone on your own name server, it will not be consulted unless it is delegated from upstream. In the middle of
dig -x ... +trace, check whether the provider's name server is the one answering. - You forgot the trailing dot: Check in the output of
dig -xthat the PTR value has not become a long name with the zone name attached. - The PTR hostname is generic: If it stays as the provider's default name such as
203-0-113-10.example-isp.net, the receiving side may treat it as a consumer connection. For a mail server, set a hostname in your own domain.
Summary
- A PTR is added to the reverse zone managed by the owner of the IP address. Writing it in the domain's DNS has no effect.
- Use
dig -x address +traceto find the name server responsible for the reverse lookup; if it is the provider, use the control panel or a request, and if it is you, write it in the reverse zone. - For the reverse name, reverse the numbers for IPv4, and reverse nibble by nibble for IPv6. For IPv6, converting with a tool is safer.
- In BIND, do not forget the trailing dot on the value and the serial number update, and load it after checking with
named-checkzone. For blocks smaller than a /24, write it in the subzone with the name the provider specifies. - After adding, check all the way that forward-resolving the reverse hostname returns to the original address.
Questions about WordPress? The publisher of this site is based in Japan and replies in Japanese. Contact (Japanese)