Disposable Domain Blocklists

In short. The lists that decide whether your address is accepted are text files maintained by volunteers and vendors. Nobody arbitrates them, they disagree with each other, and a domain that lands on one never really comes off.

What a blocklist actually is

Strip away the terminology and it is a text file with one domain per line, kept in a public repository, updated by pull request. Tens of thousands of lines, no schema, no metadata, no explanation of why any particular line is there.

That plainness matters, because it sets the ceiling on how good the mechanism can be. There is no confidence score attached to an entry, no date, and no way to say "this domain was disposable in 2021 and is a real company now". A domain is on the list or it is not, and that binary is what a signup form sees.

Who keeps them

Volunteers. The best known lists are hobby projects that grew. Someone started collecting domains, other people contributed, and now thousands of sites depend on a file that one person merges pull requests into in their spare time.

Validation vendors. Commercial services maintain private lists as part of a paid product. These are usually more accurate and always more expensive, and they draw on data volunteers cannot see, such as how mail to a domain behaves across many customers, including whether its addresses turn up in the traps that score sender reputation.

Companies for themselves. Any site with a real abuse problem eventually builds an internal list from its own signups. These never leave the company and are usually the most accurate of all, because they reflect the actual abuse that particular business suffers.

How a domain lands on one

Scraping the front page. The most common route by far. A script visits throwaway mail services, reads the list of domains offered to visitors, and adds anything new. This is automatic, unattended, and the reason no public service can stay undetected: the page that tells users which domains exist tells the scraper the same thing.

A complaint. Someone abuses a site using an address on the domain, the site operator investigates, and the domain gets contributed to a public list along with a one-line note.

Pattern detection. Names containing mail, temp, box, trash or drop, combined with a young registration and no website, get flagged automatically by some maintainers.

Manual addition after an incident. A wave of fake signups is traced to a domain and it goes on the list the same day.

How long it takes

Weeks to months, and we are not going to give you a number with a decimal point in it.

We watch our own domains go through this and the spread is genuinely wide. A domain published on a busy front page can be scraped and listed within a couple of weeks. One handed out only to signed in users can go much longer, because scrapers cannot see what they cannot load. The variable that matters most is not time, it is exposure.

Anyone quoting an exact average is either measuring one specific list or making it up. What is reliable is the direction: every published domain trends towards being listed, and none of them trend back.

Why the lists contradict each other

There are dozens of them. They copy from each other selectively, at different intervals, with different thresholds for what counts. One maintainer includes masking services; another considers them legitimate. One removes domains that stop responding; another keeps every line ever added.

This is why the same address is refused by one site and accepted by the next. The sites are not applying different judgement, they are consulting different files that happen to disagree. From the user's side it looks like randomness, and for practical purposes it is.

Why removal requests fail

There is no authority to appeal to. A volunteer list is one repository among many forks, and a maintainer who agrees to remove a line has changed one copy. Every project that already copied it still has it, and the next automated sync may well add it back.

There is also the awkward fact that the entry is usually correct. The domain does host throwaway mail. Asking for removal amounts to asking a maintainer to make their list less accurate, and they decline, politely or not at all.

The exception is a genuine mistake, and even then success depends entirely on finding the specific maintainer of the specific list a specific site uses. Most people never get that far.

Who gets caught by accident

Blocklists have collateral damage, and it falls on people who have nothing to do with throwaway mail.

Young company domains. Registered recently, privacy protected, no website yet. Indistinguishable from a new disposable service by the automatic heuristics.

Domains with unlucky words. A legitimate business called something with mail or box in the name gets pattern matched.

Domains that changed hands. A domain used for throwaway mail in 2019, sold, and now running a real business. The line stays.

University and organisation aliases. Forwarding addresses that look like relays to a heuristic looking for relays.

The people affected experience it as their own address mysteriously failing on some sites, with no explanation and no obvious fix. If you run a signup form, this is the loss you cannot see in your analytics.

What we conclude as an operator

We plan for replacement, not for defence.

There is no trick that keeps a published domain off the lists. Choosing inconspicuous names helps against pattern matching and does nothing against scraping. Rotating faster spends supply faster. Buying older domains helps with age checks and costs real money.

So domains are consumables here: bought ahead, used, worn out, replaced. Understanding that this is a business model rather than a malfunction explains most of what you see across services in this category, including why the ones promising permanent domains tend not to be around in two years.