Reverse DNS for IPv4: Complete Configuration Guide

Why Reverse DNS Matters for Your New IPv4 Addresses

So you’ve got your block. Now what? Reverse DNS configuration is one of those tasks that’s easy to postpone — and painful to regret. Without valid PTR records, your outbound email gets rejected, monitoring tools log nothing but unresolved numbers, and your reputation with the big mailbox providers takes a hit almost immediately. In practice, Gmail and Microsoft 365 will block or spam-filter mail from IPs without matching forward and reverse records. No warning. It just happens.

Email isn’t the whole story, either. Reverse DNS IPv4 records feed log correlation, geolocation, security analytics — the unglamorous plumbing that falls apart quietly when it’s missing. If you’ve recently picked up a block through a marketplace like IP4 Market, where sellers are verified and transfers are handled cleanly, getting rDNS right ensures your investment actually performs from day one.

Reverse DNS Basics: PTR Records and in-addr.arpa

Reverse DNS maps an IP address to a hostname using PTR (pointer) records stored in special reverse zones under in-addr.arpa. Take 203.0.113.45. Its record lives at 45.113.0.203.in-addr.arpa — and yes, the octets are reversed. Everyone trips over that the first time.

How DNS Lookups Work in Reverse

A resolving server queries the in-addr.arpa hierarchy from the rightmost octet down. Control of that hierarchy is delegated zone by zone: /8 blocks at the top, then /16 and /24 sub-delegations beneath. If you hold a /24 or larger, you can ask for the reverse zone to be delegated to your own nameservers. Smaller than that? Your upstream provider usually manages the PTR records for you.

Prerequisites Before You Configure Anything

• Confirmed allocation: Your block must be registered in the RIR database (ARIN, RIPE NCC, APNIC, LACNIC, or AFRINIC) under your organization. Verified marketplaces such as IP4 Market handle transfer documentation, but check the whois/RDAP output yourself. Trust, then verify.
• Forward DNS (A records): Every PTR should match an existing A record. Set these up first — that’s what enables Forward-Confirmed reverse DNS (FCrDNS).
• Authoritative nameservers: Your own NS pair, or an arrangement with your upstream/ISP to host the reverse zone.
• Provider cooperation: If the block arrived via a transit provider or ISP, they may need to delegate the zone or enter records on your behalf.

Step-by-Step: Configuring PTR Records for Your Block

Step 1: Determine Who Controls the Reverse Zone

For blocks /24 or larger, query whois for the in-addr.arpa zone to find the current reverse-zone delegations. Upstream controls it? Submit a request for delegation or record entry. In the RIPE region, use the Database or your LIR portal; in ARIN, the reverse DNS (in-addr.arpa) section of your account handles it.

Step 2: Request or Create the Zone Delegation

Submit an NS delegation for your zone — say, 113.0.203.in-addr.arpa — pointing at your nameservers. Then wait. Propagation typically takes 24–48 hours.

Step 3: Build the Zone File

Create PTR records for every address in use. A minimal BIND-style example for 203.0.113.0/24:

• 5.113.0.203.in-addr.arpa. IN PTR mail.example.com.
• 10.113.0.203.in-addr.arpa. IN PTR web01.example.com.
• 254.113.0.203.in-addr.arpa. IN PTR gw.example.com.

Don’t forget the SOA record, NS records for both primary and secondary servers, and a sensible TTL — 3600 seconds is common. During initial setup, drop it lower temporarily. You’ll thank yourself when something’s wrong and you need to fix it fast.

Step 4: Match Forward Records (FCrDNS)

Make sure mail.example.com resolves back to 203.0.113.5. Mailbox providers treat FCrDNS as a trust signal, and mismatches between the PTR hostname and the A record are one of the most common causes of blocked mail. Simple to fix, easy to miss.

Step 5: Test Thoroughly

1. Run dig -x 203.0.113.5 +short from multiple resolvers (Google 8.8.8.8, Cloudflare 1.1.1.1).
2. Use online tools like MXToolbox to check rDNS and blacklist status.
3. Send test mail to Gmail and Outlook and read the headers yourself. Look for the rDNS pass result.

Delegating Smaller Blocks: The CNAME Method

What if you bought something smaller than a /24? That’s increasingly common — /23 and /24 pricing has stayed firm, with IPs historically trading in the $25–$50 range depending on region and RIR. Classic zone delegation won’t work here. Instead, use CNAME delegation: your upstream points each individual reverse record (e.g., 65.113.0.203.in-addr.arpa) to a CNAME in a zone you control, such as 65.rev.example.com. The actual PTR then lives in your zone. One caveat, and it’s a big one: not all providers support per-record CNAME delegation. Confirm before you buy if rDNS control matters to you.

Common Mistakes to Avoid

• Generic PTR names: Records like “203-0-113-5.static.isp.net” are fine. Hostnames with no forward record at all are not.
• Missing records for unused IPs: Not every address needs a PTR — but leaving mail-facing IPs blank guarantees trouble.
• No secondary nameserver: RFC 2182 requires at least two authoritative servers. A single NS is a single point of failure, full stop.
• Ignoring IPv6 parity: Announcing IPv6 too? Configure ip6.arpa zones with the same rigor.
• TTL too high during migration: Keep TTLs low (300–900s) while changes are in flight.

Validation Checklist and FAQ

Reverse DNS IPv4 configuration costs you an afternoon, maybe two. What it buys — deliverability, a sane security posture, operational visibility you can actually rely on — is worth far more. Do it within days of acquiring new space, not months later when the mail starts bouncing.