Bulletproof hosting disposable email

By Adrian Crismaru · Founder, vrfymail · Published 2026-05-16

Disposable-email operators need somewhere to run. The MX server that receives bob@somefakedomain.com needs a real IP address on a real machine somewhere on the internet. Reputable cloud providers (AWS, Google Cloud, major-brand managed hosts) actively police temp-mail abuse: deplatform an operator and the operator scrambles for new infrastructure. The result is a small set of budget and “bullet-proof” hosting providers where the same operators keep landing — and where, after a few months of repeated catches, you can predict the next operator’s IP range with reasonable confidence based on AS membership alone.

In our production detection table, 186 /24 CIDR ranges are flagged as operator-IP infrastructure. Hit the MX A-record against any of those /24s and you can return disposable at Tier 3, even on a brand-new domain we’ve never seen before. This post: which hosting providers dominate the list, why those specific ones, and how Tier-3 CIDR detection fits into the broader disposable email checker API signal stack.

How Tier-3 IP-range detection works

Tier 1 of the detection stack does an exact domain lookup. Tier 2 does an MX-hostname match. Tier 3 does:

1. Look up the MX hostname’s A record (one DNS lookup).
2. Cast the resolved IP to a 32-bit integer (start_ip_int).
3. SQL: SELECT verdict FROM disposable_ip_ranges WHERE start_ip_int >= start AND end_ip_int <= end AND is_cdn = 0.
4. If a match, return disposable with tier: 3 and confidence: 80.
5. Cache the result so subsequent verifies on domains with the same MX A skip the DNS round-trip.

The is_cdn = 0 filter is critical. Cloudflare’s IP ranges, Mailgun’s, Postmark’s — all CDN/ESP infrastructure used by legitimate domains — are tagged is_cdn = 1 and excluded from Tier-3 matching. Catching only the operator-CIDRs and not the shared-infrastructure CIDRs is the difference between useful Tier-3 detection and a customer-support disaster.

Total CIDRs in the table:

The hosting providers we see most

Pulling 10 CIDRs from the production table (deduplicated by ASN where possible):

Hetzner, OVH, Linode, DigitalOcean, Leaseweb. These show up disproportionately. Every one of them is a legitimate, generally well-run hosting provider — none are “bullet-proof” in the criminal-infrastructure sense. They’re budget VPS providers with permissive abuse-handling policies, especially compared to AWS/Google Cloud. The barrier to standing up a temp-mail operation on Hetzner is “buy a €4/month server” and the barrier to staying up after an abuse report is “wait two weeks and the report ages out.”

This isn’t an indictment of those providers. They run massive legitimate businesses. The disposable-mail traffic is a tiny fraction of their overall use. But for the specific subset of disposable-mail operators, the same handful of ASNs keep appearing.

Why operators concentrate at these providers

Three reasons:

1. Price. A €4-9/month VPS at Hetzner or OVH covers the inbound-mail traffic of a small temp-mail operation. AWS/GCP comparable VMs are 3-5× more expensive.

2. Tolerant abuse policies. Major cloud providers deplatform temp-mail operations relatively quickly. Budget VPS providers process abuse reports more slowly and often require more evidence. The asymmetric cost of moving means operators settle at the most-tolerant provider that meets their needs.

3. No deep verification. Signing up at Hetzner or OVH requires basic KYC (an email, a payment method). No identity verification. Easy to spin up new accounts under different identities if one gets banned.

The result over time: a steady-state ecology where the same handful of ASNs host the bulk of disposable-mail back-ends. The CIDR map is the residue of that ecology.

How a CIDR gets onto the table

Three entry paths:

1. MX clustering. When we identify a new operator (via the operator graph work — fingerprint matching, MX-pattern detection, etc.), we resolve the operator’s MX server A records and check whether they cluster into a /24. If yes, that /24 enters the candidate-CIDR queue.

2. Customer-consensus on hosting tracts. If multiple distinct operators (5+) get caught in the same /24 over the course of a quarter, the /24 promotes from “operator-specific” to “operator-cluster” — meaning we generalize from specific operator IPs to the whole /24, expecting future operators in the same /24 to be disposable too.

3. Manual review. Operations staff can add a /24 directly when investigation reveals a coordinated network (a “bullet-proof hosting operator” running multiple temp-mail tenants on adjacent IPs).

A CIDR stays in the table indefinitely once added. /24s rarely get repurposed in ways that would create false positives — once a hosting provider has rented IPs in that range to disposable-mail operators, they tend to keep doing so. If we see a clean legitimate signal from a /24 (someone reporting a legitimate corporate mail server in the range), the CIDR gets a manual exclusion review.

The /24 grain

We use /24 (256 IPs) rather than /23 or /28 specifically because that’s the practical hosting-rental grain. Hetzner sells you a single IP from a /24 block when you provision a VPS. The /24 is the “neighborhood” — your immediate IP neighbors are other Hetzner customers, sometimes also disposable-mail operators, sometimes legitimate small businesses.

The trade-off: at /24, we sometimes false-positive a legitimate customer who happens to provision a VPS in a range that’s heavily occupied by disposable operators. The 380-domain allowlist catches the headline false-positive case (gmail.com, harvard.edu, etc.). For other false-positive risks, the confidence: 80 Tier-3 verdict is intentionally weaker than Tier-1’s confidence: 95-100 — so customers using vrfymail in score-aware mode can choose to soft-block at Tier 3 rather than hard-block.

We considered /28 (16-IP) granularity. It would reduce false positives but quintuple the table size and miss the operator-cluster-by-neighborhood effect we actually want to catch. /24 is the right grain for this signal.

What this looks like in your verify call

When /v1/check hits a Tier-3 match:

{
  "result": "undeliverable",
  "reason": "disposable",
  "reason_message": "This email provider doesn't deliver mail reliably. Please use a real address.",
  "disposable": true,
  "score": 0.2,
  "detection_source": "ip-range:87.98.164.0/24"
}

The score: 0.2 reflects the slightly-lower confidence vs Tier-1/Tier-2 hits. The detection_source field carries the CIDR that fired — useful for debugging or auditing.

If you want to filter Tier-3 hits client-side (perhaps you’d rather allow signups with a soft warning when the only signal is IP-range rather than domain-specific evidence), branch on score:

if (verdict.score < 0.1) {
  // Tier-1/Tier-2 hit. Block firmly.
  return { error: verdict.reason_message };
}
if (verdict.score < 0.3) {
  // Tier-3 IP-range hit. Block in B2B, allow with flag in B2C.
  return { warning: verdict.reason_message };
}

Most customers use the default (block on any undeliverable); a small minority want score-aware handling for edge cases.

The CDN-exclusion rules

The other half of the CIDR table — the 31 is_cdn=1 entries — explicitly exclude CDN and ESP infrastructure from Tier-3 matching. Without this, a legitimate Cloudflare-hosted mail forwarder, an SES-backed transactional mail server, or any other shared-infrastructure mail setup would false-positive heavily.

Notable exclusions:

• Cloudflare Email Routing IPs
• Mailgun sending and receiving IPs
• Postmark IPs
• SendGrid IPs
• Resend IPs
• Major IaaS shared-tenancy ranges (AWS SES, Google Cloud, Azure)

These are still observable in the table — if you query the verdict and it shows detection_source: 'ip-range-excluded:cdn', that means the IP-range matched but was overridden because of the CDN flag.

Connection to the rest of the detection stack

Tier 3 is the last-resort catch — fired only when Tier 1 (domain), Tier 2a (exact MX), and Tier 2b (parent MX pattern) all missed. In practice, ~3-5% of disposable hits land at Tier 3. That’s small relative to the 70-80% Tier-1 catch rate, but the catches Tier-3 makes are catches no other layer would have made: brand-new domains under brand-new operators whose only identifying signal is “this IP is in a known bad neighborhood.”

The combined effect is the layered detection that protects sign-up forms against the long tail of operators that don’t fit any clean pattern in the upper tiers.

FAQ

Are Hetzner / OVH / DigitalOcean themselves disposable-mail companies?

Absolutely not. They’re legitimate hosting providers running massive businesses serving millions of customers, the overwhelming majority of whom are not running disposable mail. The clustering at these providers reflects disposable-operator preferences, not provider intent.

Will you false-positive my legitimate mail server hosted at Hetzner?

The 380-domain allowlist catches the big cases. For smaller legitimate domains on Hetzner that happen to land in flagged /24s: if you report being incorrectly blocked, we manually exclude the IP from the relevant CIDR. In practice the false-positive rate at Tier 3 is well under 0.5%.

Why /24 and not the whole ASN?

ASN-grain would be way too coarse. AS24940 (Hetzner) hosts millions of legitimate sites. /24 narrows to specific neighborhoods within an ASN — the 256-IP blocks where disposable-mail operators have actually been observed clustering. Even within Hetzner, only ~3-5 specific /24s show heavy operator concentration; the rest of Hetzner’s IP space is uneventful.

What happens if a /24 gets re-issued to a new tenant?

Theoretically the new tenant could be a legitimate mail server inheriting a flagged /24. In practice this is rare because operator-flagged /24s rarely get fully released — operators churn within the same neighborhood. If a legitimate customer reports a false positive, we manually review and exclude.

Can I detect this myself without your API?

Sort of. You can run dig against the MX of any candidate domain, resolve the A record, and check the IP against published reputation lists (Spamhaus DROP, Spamhaus EDROP, etc.). Those general-purpose lists catch some of the operator-CIDR overlap but not all of it. Operator-specific CIDRs from temp-mail concentrations are a more focused signal that doesn’t show up on broad spam-list databases.

Tier-3 CIDR detection in one API call

vrfymail’s /v1/check runs all four tiers including IP-range matching. Free tier: 5,000 verifies/month, no card. Get an API key →

Updated 2026-05-16