How disposable email services hide, and how shared mail servers give them away

What is a disposable email domain, and why do lists lag?#

A disposable email domain is a domain whose addresses exist so that someone can receive one message and abandon the inbox. Operators of these services register domains in bulk and rotate them, because a domain that ends up on a blocklist stops being useful to their users. Lists are maintained by volunteers who add domains after seeing them, so a list always trails the newest domains.

A list is a memory of domains already seen. It says nothing about a domain registered yesterday.

What do the upstream lists contain?#

StormDoor builds its list from two public sources, both with licences that permit commercial use. Counts below are from fetching both files on 2026-10-10 and normalising them with the same rules as the build (lowercase, punycode, bare hostnames only).

The union is one more than the committed list of 61,888 because StormDoor removes nus.edu.sg after merging (next section). Overlap is low. 41.7% of the smaller list is also in the larger one, so neither list is a subset of the other, and a single source would miss most of what the pair covers.

Do blocklists contain real organisations?#

Yes, occasionally, and any list built from reports and scraping can. The National University of Singapore’s domain, nus.edu.sg, appears in the FGRibreau/mailchecker list [2] and in the willwhite/freemail free-provider list [3], both fetched 2026-10-10. StormDoor’s allowlist note records its MX as hosted by Trend Micro, an email security vendor, and the existing list check had flagged the university as disposable before the entry was removed [4].

StormDoor keeps a small allowlist that removes such entries from both lists at build time. An entry is added only after confirming the domain receives mail for a real organisation. A list of 60,000 entries maintained by volunteers will have rare errors like this one, and a consumer that blocks on list membership alone needs a way to correct them. In the legitimate-domain test set, this was the only list false positive in 339 domains [4].

Why are most listed domains dead?#

In StormDoor’s measurement, 17,001 of the 61,733 listed domains (27.5%) had MX records, 36,495 (59.1%) did not exist, and 7,020 (11.4%) existed without MX records. The rest failed to resolve in that run [4]. A domain with no MX record cannot receive mail, so a signup using it fails the email.no_mx check anyway. In the 500-domain held-out sample, 284 did not exist and 54 had no MX, leaving 144 live domains to measure.

Dead entries cost memory and add nothing to detection. They also mean the headline size of a list says little about how many working throwaway domains it covers: about one in four.

How do shared mail servers give a new domain away?#

Registering a domain is cheap and automated. Running mail servers that accept mail for thousands of addresses is not, so operators point many domains at the same few hosts. A domain’s MX record names the host that receives its mail, and that record is public.

StormDoor’s email.disposable_infrastructure check works as follows [4]:

1. Resolve MX for every domain on the list.
2. Remove hosts of shared providers (Google, Microsoft, Zoho, Proton, Cloudflare Email Routing, large registrars and similar), since many ordinary domains use them.
3. Keep each remaining host that serves at least three listed domains. This gave 256 hosts on the full list.
4. At request time, flag an unlisted domain whose MX hostname is in that set. The check reuses the MX answer email.mx already fetched, so it adds no network call.

How well does it work on domains the list has never seen?#

The test held out a random 20% of the list (seed 20261009), removed those domains from the list, and rebuilt the host set from the remaining 49,387 domains only. The first 500 held-out domains were screened with live DNS [4].

The list-only row is 0% by construction: the held-out domains were removed from it. Run-to-run variation is about 3 points because of DNS timeouts. The minimum host size of three is the smallest value that needs three independent listings. Recall was 56.3% at two and 53.0% at ten, so the setting matters more for false positives than for recall.

What does it miss, and what does it wrongly flag?#

The other 46.5% of live held-out domains are not caught. Operators that give each domain its own mail host, or that hide behind a shared provider, do not leave a shared-host signature, and shared providers are excluded on purpose [4].

On false positives, the check flagged none of 339 hand-picked company, university, government and organisation domains, and none of the first 4,000 domains on a free-provider list. Before StormDoor skipped free providers, 108 of those 4,000 would have been flagged, because some legacy vanity-domain hosts share servers with a few listed domains. The limit of this evidence is its size: a legitimate business on a small host that a disposable operator also uses would be a false positive that a 339-domain set cannot show.

What should you do with this?#

Treat a list hit (email.disposable_domain) and a mail-server match (email.disposable_infrastructure) as different strengths of evidence, and combine them with MX and domain-age signals (and see email validation vs verification for where each check sits); see how old disposable domains are and which mail servers they use. You can try the list on a single address in the disposable email checker. StormDoor makes the checker and the API gate described here; other vendors cover this too, compared in best disposable email detection APIs.