Setting up reverse DNS (PTR records) for your subnet
Forward DNS, the part that turns a name into an address, you set up without thinking. Reverse DNS, the part that turns your addresses back into names, is the step people skip on a new subnet, because it needs a delegation nobody hands you automatically. It is also the first thing many mail servers check, and getting it wrong quietly costs you delivery no matter how perfect your authentication is. Here is how reverse DNS actually works on a block you control, and how to set it up properly.
What reverse DNS is, and who controls it
A forward record answers "what address is this name". A reverse record answers the opposite, "what name is this address", and it lives in a parallel part of DNS built for exactly that. For IPv4 the reverse tree is under in-addr.arpa, with the address octets reversed: the reverse zone for 203.0.113.0/24 is 113.0.203.in-addr.arpa, and each address in it carries a PTR record naming a hostname. For IPv6 the same idea lives under ip6.arpa.
The catch is authority. You do not get to publish reverse records for your addresses just because you announce them; the owner of the reverse zone does, and by default that is the registry or your upstream, not you. So the first job on a new block is to have that authority delegated to you, or to use the reverse-DNS panel your provider exposes for it. Until that happens, your PTR records have nowhere to live.
Why mail servers care so much
Reverse DNS is load-bearing mostly for one job: sending mail. A large share of receiving mail servers will reject or heavily penalise a connection from an address that has no PTR record at all, and many go further and require a forward-confirmed reverse DNS check, often written FCrDNS. That check closes a loop: the address must have a PTR record pointing to a hostname, and that hostname must have a forward record pointing back to the same address. If the loop does not close, the mail is treated as suspicious before your content, your SPF, your DKIM or your DMARC is even considered.
This is why reverse DNS belongs to the same job as warming a new range: it is part of making the addresses describe you before you ask anyone to trust them. Authentication proves who you are; reverse DNS proves the addresses are set up like a real sender rather than an anonymous host.
Getting the reverse zone delegated
For a full /24 or larger, delegation is clean. You run nameservers for the reverse zone, and the holder of the parent zone, your RIR or your upstream, points the zone at them with NS records. In the RIR databases this is usually a matter of setting the reverse delegation on the relevant object; with an upstream it is a request to their support or a field in their portal. Either way the outcome is the same: queries for addresses in your block are directed to your nameservers, and you become the authority for their PTR records.
Many hosting providers skip the delegation entirely and give you a reverse-DNS editor instead, where you type the PTR for each address and they publish it in the zone they hold. That is perfectly fine and often simpler; the only thing to confirm is that the editor actually covers the addresses you are announcing.
Publishing the PTR records
With authority in place, publish a PTR for every address that will originate connections, mail addresses above all, on a naming scheme that is yours and resolves forward. A PTR like mail.example.com is only useful if mail.example.com resolves back to the same address, so the forward and reverse records are set as a pair. Give addresses meaningful, consistent names rather than the generic auto-generated hostnames a provider assigns, because those generic names read to a receiver as "unconfigured host", which is not the impression a sender wants to make.
One PTR per address is the norm; multiple PTRs on one address are legal but tend to confuse the software that reads them, so keep it to one canonical name that forward resolves back. Match the hostname to the mail server's HELO name where you can, so the whole identity lines up.
Blocks smaller than a /24, and IPv6
Reverse DNS delegation follows octet boundaries, so a block smaller than a /24 does not get its own natural zone. The answer is the classless delegation described in RFC 2317, where the parent zone owner uses CNAME records to point each address's reverse name at a zone you control. If you hold a sub-/24 assignment, this is the mechanism to ask your upstream about; most that assign small blocks already have a process for it.
IPv6 works the same way under ip6.arpa, with the address expanded to its full nibble form and reversed. The address space is far too large to populate by hand, so IPv6 reverse DNS is usually generated, either by a wildcard-style scheme or by software that answers PTR queries dynamically. If you send mail over IPv6, the same FCrDNS expectation applies, so the sending addresses still need names that resolve both ways.
Verifying it, and the inherited-name trap
Check the round trip explicitly. A reverse lookup on an address should return your hostname, and a forward lookup on that hostname should return the address: dig -x 203.0.113.10 to read the PTR, then a forward query on the name it returns. If either half is missing or points somewhere else, FCrDNS fails.
There is one trap specific to space you did not always hold. If the block was previously someone else's, its reverse records may still resolve to their naming scheme, so every receiving admin who looks you up sees the previous tenant, and worse, abuse reports find their way to a contact that is no longer yours. Reverse DNS that still names a previous holder is a small job to fix and a large one to leave broken, because it undoes the identity you are trying to build. Setting your own PTRs across everything you announce, and confirming the old ones are gone, is part of clearing what you inherited before the first message goes out.
Look up any prefix on the front page to see who held it before you, which is the usual reason its reverse records still carry the wrong name. The report shows the ownership history with dates, and says plainly when nobody has checked something.