The 638 operators behind disposable email

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

The first surprise when you cluster 265,673 disposable email domains by operator is that there aren’t 265,673 different people running them. There are 638. The second surprise is how unevenly the domains distribute across those 638. The top 10 operators own 58% of every disposable email domain we track. The top 50 own 90%. The long tail of 588 operators splits the remaining 10% between them, most controlling exactly one domain each.

This post is a tour of that operator graph — who controls how many domains, what their categories are, and why this matters when you’re building a disposable email checker API. All numbers pulled live from the production detection database.

The shape of the operator graph

Per-operator domain counts skew hard:

Read those numbers carefully. Median is 1 — half the operators in the graph run exactly one domain. p90 is 3 — 90% of operators run three domains or fewer. The mean is 10 only because the tail end has operators running hundreds of domains apiece.

That’s a textbook power-law distribution. Building a detection system around it has practical consequences: catching the top 100 operators catches 91% of disposable mail traffic. The remaining 9% — the long tail of one-domain operators — needs different detection (CT-log scanning, customer-consensus promotion) because the operator-fingerprint approach has nothing to cluster on when an operator runs a single domain.

The top 15 operators by domain count

The dominant operators, pulled live:

A few things to notice. The biggest operator (yopmail.co, 654 domains) is technically classified as an alias-forwarder, not a pure temp-mail provider — the mechanical reality of its MX infrastructure makes it forward inbound mail rather than store it in addressable inboxes. We covered the alias forwarder trick in a separate post.

The bccto.me operator runs 14 brands, which is more brands than any other operator in the registry. Each brand looks like a “different” temp-mail site to a casual visitor; the fingerprint cross-reference tells the truth.

The shieldmail.com row is interesting too. It’s classified as privacy-mail-legit rather than temp-mail — it operates as a legitimate alias-forwarding service for users opting in to privacy protection. The mechanism is the same as Yopmail’s; the intent and business model are different. Detection-wise both bucket to the same verdict (risky with reason: alias_forwarder), and your handler decides whether to allow or flag.

Operator categories

The 638 active operators split across three categories:

(Total exceeds 638 because some operators are registered but haven’t been linked to specific domains yet — the registry is fed by SERP discovery, blocklist sync, and fingerprint scrapes, but the operator-to-domain edges only populate when a domain is actually classified.)

The category line matters because it shapes the verdict. Verdicts for temp-mail operators return result: undeliverable with reason: disposable. Verdicts for alias-forwarder operators return result: risky with reason: alias_forwarder — softer because the recipient does actually read the mail at a real (forwarded) inbox. The privacy-mail-legit category exists to make sure we don’t accidentally hard-block users on Firefox Relay, SimpleLogin, or DuckDuckGo Email Protection just because their MX infrastructure shares the mechanical pattern of disposable mail.

How an operator gets into the registry

Three discovery channels feed the operator graph:

1. SERP discovery via DataForSEO. We run targeted searches for “temp mail,” “disposable email,” variants in major languages — French, German, Russian, Spanish, Hindi — capture the candidate domains, then a headless Playwright probe visits each domain to extract the actual mail domains it hands out from its inbox dropdown. Each unique apex visited becomes a candidate operator.

2. Public blocklist sync. Eight community-maintained disposable blocklists on GitHub (the npm disposable-email-domains package being the most-known) get fetched daily, deduped against our existing registry, and any new apex becomes a candidate operator. A defensive deny-list strips known false positives (gmail.com, outlook.com, etc.) before insertion — covered in our 380-domain allowlist post.

3. Fingerprint-driven clustering. When the Playwright probe extracts a candidate’s HTML, it pulls every Google Analytics ID, AdSense publisher ID, Tag Manager ID, Facebook Pixel, and similar tracking codes. Candidates sharing the same ID are flagged as the same operator. This is how Yopmail’s 4 brands collapse into one operator entry. The methodology has its own write-up at operator fingerprint clustering.

Why the operator graph matters for a verifier

A static disposable list treats mailinator.com and wuuvo.com as two unrelated names to remember. The operator graph treats them as one operator’s surface — and once you know that, a new throwaway domain registered by the same operator is detectable before it’s in any list, because its MX points at the same backend.

The detection table works in tiers:

• Tier 1 (~5µs): exact domain lookup in 265,673-row disposable_mail_domains table.
• Tier 2a (~50ms, one DNS): exact MX-hostname match against 302 known operator MX backends.
• Tier 2b (~50ms, same DNS): parent-domain regex match against 12 MX-rotation patterns.
• Tier 3 (~100ms, +1 DNS): MX A-record IP falls inside 186 operator CIDR /24 ranges.

A brand-new domain we’ve never seen — but whose MX is mx99.add5000.com — gets caught at Tier 2b in 50ms because its parent MX matches the add5000.com pattern. That’s not possible with a flat domain list. It needs the operator graph behind it.

The 9% tail

638 operators is the structured part. The other 9% of domains in the disposable-mail table — the ones owned by operators we haven’t clustered yet, or that are genuinely one-off — get caught through other signals:

• CT-log scanning. Hourly polls of crt.sh for newly-issued TLS certs matching disposable-mail patterns. A brand new throwaway provider that issues its first cert at 10am is in our database by 2pm. Detailed in our CT-log pipeline write-up.
• Customer-consensus promotion. When ≥3 distinct vrfymail customers report bounces or spam complaints on the same domain within 30 days, the domain promotes to a global is_spam_trap=1 flag. Free-mail providers (Gmail, Outlook, Yahoo) are explicitly excluded from this rule.
• Manual review. Patterns we want to investigate before adding (or rejecting) land in a domain_candidates queue. Operators that should ship same-day go straight in; ambiguous cases get human eyes.

The combined effect: even the long tail of one-domain operators eventually gets caught, just through slower channels than the operator-graph hot path.

What this looks like in your verify call

Every /v1/check request runs all four tiers against the domain, returning the verdict in 50ms p50. Sample response on a disposable-domain hit:

{
  "result": "undeliverable",
  "reason": "disposable",
  "reason_message": "This email provider doesn't deliver mail reliably. Please use a real address.",
  "disposable": true,
  "score": 0.0
}

The operator graph is invisible to the API consumer — you get the verdict, not the cluster analysis. The graph is the machinery; the verdict is the product.

FAQ

Why 638 operators when the total registry shows 945?

945 is the operator registry (every entity we’ve ever discovered, including ones still in the candidate queue). 638 is the subset whose domains have actually been classified and linked. The gap is mostly pending-review candidates and operators we’ve identified by fingerprint but haven’t fully scraped yet.

How many of those operators are actively running new domains?

Hard to give a clean number — operator activity has a long tail. Roughly: top 50 operators ship new domains weekly, the next 200 ship monthly, the rest are largely static.

Can I get the full operator list?

The list itself isn’t published as a feed, but every domain you query via vrfymail’s /v1/check endpoint returns the verdict tied to its operator classification. The detection table at the API surface is what we publish; the underlying graph stays internal to keep adversarial scraping costs high.

Does the operator graph improve detection for new disposable providers?

Yes — that’s the whole point. A brand new domain we’ve never seen whose MX matches a known operator pattern gets caught at Tier 2b in 50ms, not 8 weeks later when someone updates the npm package. Same operator, same MX, same verdict.

Are the 16 alias-forwarder operators a security risk?

They’re a category, not a risk. Some (SimpleLogin, AnonAddy, Firefox Relay, DuckDuckGo Email) are legitimate consumer privacy services. Others (Yopmail) function as public temp-mail with the mechanical pattern of a forwarder. The detection returns risky rather than undeliverable so your handler can choose based on your fraud-tolerance.

Use the graph from one API call

Every /v1/check hits the operator graph on the hot path — 5µs Tier-1, 50ms p50 end-to-end. Free tier: 5,000 verifies/month, no card. Get an API key →

Updated 2026-05-16