Ask anyone who has inherited a mail server with a broken PTR record, and they’ll tell you the same thing: reverse DNS is not optional. PTR records sit at the foundation of email deliverability, network troubleshooting, and IP reputation management for anyone who owns or leases IPv4 space. The problem is that plenty of network engineers find this out the hard way. They register a block, assume everything else follows automatically, and then discover that mail gets rejected, monitoring tools can’t resolve hostnames, and customers start complaining. This guide covers why these records matter, how in-addr.arpa zones work under classless delegation, and the practical steps to get rDNS delegation from your RIR or upstream provider.<\/p>\n
Forward DNS maps a hostname to an IP. Reverse DNS does the opposite: it maps an IP back to a hostname through a PTR record. And here’s where it gets consequential. Mailbox providers like Google, Microsoft, and Yahoo run forward-confirmed reverse DNS (FCrDNS) checks before accepting inbound mail. If your sending IP at 203.0.113.45 has no PTR record at all, or the PTR doesn’t resolve forward to the same IP, your mail will likely bounce or land straight in spam.<\/p>\n
Email is only part of the story, though. PTR records also matter for:<\/p>\n
If you hold a \/24 or larger, inconsistent PTR records across the block signal poor hygiene to peers and monitoring services. A simple naming convention helps more than you’d think \u2014 something like host45.mail.example.com<\/em> for the IP ending in .45. Future you will be grateful.<\/p>\n Reverse lookups use the special domain in-addr.arpa<\/strong>. Each octet of an IPv4 address becomes a subdomain, reversed. So 198.51.100.77 maps to 77.100.51.198.in-addr.arpa<\/em>, and a PTR record at that node returns the hostname. Straightforward enough.<\/p>\n Authority over reverse zones follows the same delegation model as forward DNS. There’s a catch, though: reverse delegation only happens on octet boundaries. A \/24 is the smallest conventional unit, so if you hold a \/26, you can’t get a standard delegation the usual way. This is where RFC 2317<\/strong> \u2014 classless in-addr.arpa delegation \u2014 comes in.<\/p>\n Under RFC 2317, the upstream (typically the ISP or RIR) delegates a subdomain named after your range, for example 0-63.100.51.198.in-addr.arpa<\/em>, and uses CNAME records for each individual host entry. The upstream’s zone contains:<\/p>\n Your nameservers then host the classless zone and publish the actual PTR records. A word of practical advice: confirm your DNS software supports classless zones (BIND, PowerDNS, and Knot all do), and test resolution with dig -x<\/em> from an external network after the delegation propagates. Cached negative answers can delay validation longer than you’d expect.<\/p>\n Who you ask depends on who assigned you the space. Blocks that come directly from an RIR (ARIN, RIPE NCC, APNIC, LACNIC, or AFRINIC) are handled through that registry’s portal. Space received from an ISP is different: the ISP either manages rDNS on your behalf or forwards your delegation request upstream.<\/p>\n A typical workflow looks like this:<\/p>\n Tip:<\/strong> Before requesting delegation, verify your nameservers pass the RIR’s pre-delegation tests. Failed connectivity checks are, by a wide margin, the most common reason reverse DNS setup gets delayed.<\/p>\n<\/div>\n One more thing, and it’s easy to overlook. When buying address space on the secondary market, confirm who controls reverse delegation before you close the transfer. Re-delegating rDNS after a block changes hands can drag on for days if the previous holder’s records linger. Marketplaces like IP4 Market simplify this part of the transition \u2014 they work with verified sellers and walk buyers through post-transfer rDNS setup, so the block is fully operational from day one.<\/p>\n Once the reverse zone is delegated to your name servers, adding PTR records is the easy part. In BIND, a record for the host 203.0.113.25 looks like this:<\/p>\n 25.113.0.203.in-addr.arpa. IN PTR mail.example.com.<\/em><\/p>\n See the fully qualified domain name at the end? Don’t drop that trailing dot. It’s probably the single most common mistake in zone files, and the failure mode is nasty: BIND silently appends your zone name to the hostname, forward-confirmed reverse DNS breaks, and nothing in your logs tells you why. Cloudflare, AWS Route 53, PowerDNS \u2014 same logic everywhere, really. Only the interface changes.<\/p>\n One rule worth internalizing: verify from outside your network. Internal resolvers cache, and they cache aggressively \u2014 stale or local answers will lie to you. Run dig -x 203.0.113.25 +trace<\/strong> and follow the delegation chain from the arpa root all the way down to your authoritative servers. Wherever the chain snaps, that’s your broken link. It usually shows up immediately.<\/p>\n The usual suspects:<\/p>\n Quick check:<\/strong> Before deploying new mail infrastructure, run your IP through an rDNS validator and an SMTP test tool like mail-tester.com. Fixing a score penalty from missing PTR records is trivial before launch. After blacklisting? Not so much.<\/p>\n<\/div>\n Reverse DNS is a small task with outsized consequences \u2014 email deliverability, logging quality, network reputation all hang on it. So put it on your IPv4 acquisition checklist, not in the “later” pile. Register the delegation with your RIR the moment a transfer completes. Publish matching forward and reverse records. Automate the sync through your IPAM platform so drift never creeps in.<\/p>\n If you’re buying address space, it helps to work with a marketplace that understands the full transfer lifecycle. IP4 Market pairs verified sellers with competitive pricing and hands-on guidance for post-transfer work like rDNS delegation, so blocks arrive clean and production-ready. Bake rDNS management into your standard procedures, audit the records quarterly, and the reputation your IPv4 investment depends on will hold.<\/p>\nUnderstanding in-addr.arpa Zones and Classless Delegation (RFC 2317)<\/h2>\n
\n
How to Request rDNS Delegation from Your RIR or ISP<\/h2>\n
\n
Configuring Reverse DNS PTR Records on Your Authoritative Name Servers<\/h2>\n
\n
Testing and Troubleshooting Your Reverse DNS Setup<\/h2>\n
\n
Conclusion: Best Practices for Managing rDNS on Purchased IPv4 Blocks<\/h2>\n