161 of 360 VPS IPs have no reverse DNS. They're cleaner than the ones that do

2026-10-07 · 数据来自公开可复现源 · 作者 One IP

Reverse DNS (a PTR record) is the first thing most deliverability guides tell you to check. "No PTR = spammer" is treated as common knowledge.

I sampled 360 IPs across 12 VPS providers and checked both their PTR records and their presence on 8 public DNS blocklists. The assumption doesn't hold up.

The numbers

All 360 IPs, split by whether they had a PTR record at all:

IPs without reverse DNS are listed on fewer blocklists than IPs with it. The relationship runs the opposite direction from the conventional advice.

That doesn't mean PTR records cause listings. It means the absence of one is not evidence of anything.

Why the correlation inverts

The pattern becomes clear once you look at which providers sit on each side:

• Alibaba Cloud: 30/30 IPs have no PTR (100%), but only 1/30 is on any blocklist (3.3%).
• Tencent Cloud: 29/30 have no PTR (97%), and 6/30 are listed (20%).
• BandwagonHost: 0/30 missing a PTR — every IP is set up — and only 1/30 is listed (3.3%).
• DigitalOcean: 25/30 have no PTR, 1/30 listed.

The large cloud providers assign IPs in huge batches and never configure reverse DNS, because their customers spin up instances programmatically and PTR management isn't part of the default flow. Those batches are mostly clean — they're used for ordinary services.

The IPs most likely to have PTR records configured are the ones run by smaller hosting operations where someone sets things up by hand. Those same operations also host the cheap ranges that accumulate listings.

PTR configuration is a proxy for "how this provider operates," not for "how clean this IP is."

The blocklist detail

The 16 listings among the no-PTR IPs come from:

SPFBL dominates this group exactly as it dominates the full dataset: of all 47 listed IPs in the sample, 41 are on SPFBL alone, and not a single IP appears on more than one list. If you're checking an IP and it's listed, it's overwhelmingly likely to be exactly one list, and that list is SPFBL.

What this means for checking an IP

Checking PTR first is backwards. A missing PTR tells you the provider didn't configure it, which correlates with being a large cloud provider, which correlates with being cleaner.

The order that actually reflects risk:

1. Query the blocklists directly. This is the only step that measures the thing you care about.
2. Check RDAP for a registrant. 247/360 IPs in this sample (69%) return no registrant on record at all — which is a much stronger signal about who is accountable for the IP than PTR status.
3. Leave PTR for last. Useful context if you're debugging mail delivery specifically. Near-useless as a reputation signal.

Method

360 IPs, 30 per provider, across 12 providers: RackNerd, BandwagonHost, Vultr, DigitalOcean, Linode, Hetzner, OVH, Contabo, Oracle Cloud, Alibaba Cloud, Tencent Cloud, and DMIT.

PTR looked up via direct DNS query, classified as named or none. Blocklists checked against 8 public DNSBLs: all.s5h.net, dnsbl-1.uceprotect.net, bl.spamcop.net, dnsbl.dronebl.org, dnsbl.spfbl.net, hostkarma.junkemailfilter.com, psbl.surriel.com, and bl.blocklist.de. RDAP queried against the relevant registry.

The 360 raw records are public: vps-audit-2026-09.json (CC BY 4.0), method and per-IP detail at the full audit page.

I built PureIP — an IP lookup and network diagnostics toolbox — these 360 records are a byproduct of it.