Struggling with failing reverse DNS (PTR) lookups after moving to a new /21 subnet? I’ll break down why it happens and walk you through three real-world solutions to fix your IP reputation and get your services communicating properly again.

From the Trenches: Why Your New /21 Subnet is Killing Your IP Reputation (and How to Fix It)

I remember one Tuesday morning, around 2 AM. PagerDuty was screaming. Our brand new application cluster, sitting pretty in a shiny new /21 subnet we’d just acquired, was suddenly being blackholed. Our mail gateways were getting rejected, partner APIs were throwing authentication errors, and our external monitoring was lit up like a Christmas tree. The services were up, the network was fine, but to the rest of the internet, we looked like a spam operation. After a frantic hour of digging, we found the culprit: our reverse DNS was completely broken. This wasn’t a simple missing PTR record; this was a fundamental mismatch between our modern subnetting and the old-school rules of DNS.

The Root of the Problem: Classful Thinking in a Classless World

So, what’s actually going on here? You get a new /21 block, say 198.51.100.0/21. You carve it up, assign 198.51.101.50 to your new mail gateway, mail-gw-01.techresolve.com, and you go to set the reverse DNS (a PTR record). But you can’t. Why?

It’s because of how reverse DNS zones (the in-addr.arpa domain) are delegated. Authority is handed off at octet boundaries, which line up perfectly with old classful subnets: /8, /16, and /24. Your /21 subnet doesn’t fit this model. The authority for the entire /16 block (51.198.in-addr.arpa) likely still sits with your upstream provider. When a server tries to look up the reverse DNS for your IP, it asks your provider’s DNS servers, not yours. And since they have no idea about your specific hosts, the lookup fails.

Pro Tip: You can see this failure in action yourself. If you have an IP like 198.51.101.50, you can test its reverse lookup. The name to look up is the IP reversed with .in-addr.arpa at the end. A simple dig command tells the story.

# This query will likely go to your provider's nameservers and fail
dig -x 198.51.101.50
# Or more explicitly
dig PTR 50.101.51.198.in-addr.arpa

This failed lookup makes you look untrustworthy to mail servers, security appliances, and services that use rDNS as a first-pass sanity check. So, how do we fix it? We have a few options, ranging from a quick plea for help to a proper architectural change.

The Fixes: From Band-Aids to Brain Surgery

Solution 1: The “Get Me Out of Jail” Quick Fix

This is the fastest way to stop the bleeding, but it’s not a long-term solution. You essentially treat your upstream provider as your reverse DNS administrator.

• The Action: Open a support ticket with your provider. Give them a list of IP addresses and the hostnames you want them to resolve to. “Please create a PTR record for 198.51.101.50 pointing to mail-gw-01.techresolve.com.”
• The Reality: This is hacky and doesn’t scale. Every time a new critical server comes online or an IP changes, you’re back to filing another ticket. It’s fine for a handful of static, critical IPs (like mail gateways or external load balancers), but it’s a nightmare for dynamic environments.

Solution 2: The “Do It Right” Permanent Fix

The correct, scalable solution is to have your provider delegate control of the reverse zone for your /21 block to your authoritative nameservers (like AWS Route 53, Cloudflare DNS, or your own BIND servers). This is the method described in RFC 2317, and it’s how the internet is supposed to work.

The provider will create CNAME records for every IP address in your range, pointing to a zone you control. For example, for the IP 198.51.101.50:

1. Your provider creates a CNAME record in their zone file.
2. This CNAME points from their zone to a corresponding record in a zone you control.
3. You then create the actual PTR record in your own zone.

Here’s what that conversation with your provider looks like:

“We have the block 198.51.100.0/21. Please delegate the reverse DNS for this range to our nameservers, ns1.techresolve.com and ns2.techresolve.com, using the RFC 2317 CNAME method.”

On their side, their zone might look something like this for your IP:

; In the provider's 100-107.51.198.in-addr.arpa zone
50.101 CNAME 50.101.100-107.rdns.techresolve.com.

And on your side, in your 100-107.rdns.techresolve.com zone, you’d have full control:

; In your new rdns.techresolve.com zone
50.101 PTR mail-gw-01.techresolve.com.

Warning: Not all providers are created equal. Some will know exactly what you’re asking for. Others will require you to educate their support staff. Be patient, be persistent, and don’t be afraid to reference RFC 2317 directly.

Solution 3: The “Change the Game” Nuclear Option

Sometimes, fighting with a provider isn’t worth the time, or you need to move faster than their bureaucracy allows. This option is about architecturally side-stepping the problem for the services that are most affected.

• The Action: Instead of hosting services that are highly sensitive to rDNS reputation (like email) on your own IPs, offload them. Use a dedicated service like Amazon SES, SendGrid, or Mailgun for email. Their IPs are pristine, their rDNS is immaculate, and deliverability is their core business.
• The Broader View: For other services, place them behind a managed load balancer or proxy service from a major cloud provider. The public-facing IPs of these services are managed by the provider and typically have generic but valid rDNS records, which is often enough to pass a basic sanity check. You avoid the rDNS problem entirely because your troublesome IPs are no longer the ones making first contact.

Comparing the Solutions

Here’s a quick breakdown to help you decide which path to take:

We ended up using a hybrid approach. We used Solution 1 to immediately fix our main mail gateways and unblock our critical partners. While that was happening, we opened a second, more detailed ticket with our provider to get proper delegation (Solution 2), which took about a week of back-and-forth. For future projects, we’re now heavily biased towards using managed services (Solution 3) for anything that directly communicates with the outside world, just to avoid this headache altogether.

This is a frustrating, old-school networking problem colliding with modern, agile infrastructure. Don’t beat yourself up if you hit it. Just know your options, pick your battle, and get your reputation back on track.

Darian Vance

Lead Cloud Architect & DevOps Strategist

With over 12 years in system architecture and automation, Darian specializes in simplifying complex cloud infrastructures. An advocate for open-source solutions, he founded TechResolve to provide engineers with actionable, battle-tested troubleshooting guides and robust software alternatives.

🤖 Frequently Asked Questions