# disposable/disposable: Choosing and Updating Disposable Email Domain Lists

> This Python project generates and publishes several classifications of disposable, anonymous-signup, forwarding, and alias-service domains. It suits applications that need an updated screening list, but its strict and forwarding modes serve different policy decisions.

**disposable/disposable** — A list of disposable/temporary email address domains

- Repository: https://github.com/disposable/disposable
- Stars: 1,466 · Forks: 163
- Language: Python
- License: MIT
- Published: 2026-10-16 · Updated: 2026-10-16 · Language: en
- Canonical page: https://hysenlabs.com/projects/disposable-disposable

## Why disposable/disposable Maintains Separate Domain Classifications

disposable/disposable addresses a narrow but recurring application problem: identifying email domains associated with temporary mailboxes, anonymous signup, forwarding, or aliasing. The README names signup validation and counting real addresses in an existing system as intended uses. That makes the project relevant to account registration systems, analytics pipelines, and applications that want to filter obviously short-lived addresses before sending messages or allocating per-user resources.

The project does not treat every unusual mailbox provider as one interchangeable category. `domains.txt` is the sorted normal-mode list. `domains_strict.txt` adds greylisted services that allow anonymous signup. `domains_forwarding.txt` combines disposable domains with forwarding and alias services such as SimpleLogin, Firefox Relay, and Apple Hide My Email, while excluding freemail mailbox providers.

That distinction matters because an address used through a forwarding service may belong to a person with a stable identity even though the domain is shared by many users. A disposable mailbox often serves a different purpose and may expire. An application cannot infer those differences from the domain alone, so choosing between the published files is part of the policy decision rather than a technical detail.

## Generated Files, Metadata, and the Daily Update Flow

The repository publishes generated text files rather than requiring every consumer to run the crawler. The normal list contains one domain per line and is described as autogenerated every 24 hours. The strict file follows the same line-oriented format, while `domains_forwarding.json` attaches metadata such as provider name, service type, verification, and contributing sources.

Based on the repository layout and README, the generation process aggregates external disposable-email data, processes explicit classification files, and writes the resulting domains. The repository includes `disposable.py`, `src/`, source-related tooling, tests, `greylist.txt`, `mailservices.json`, and a `.generate` entry point. The exact implementation of every crawler is not reproduced in the README, so the supported public workflow is the documented generator command rather than assumptions about individual source adapters.

Two guard mechanisms affect output stability. Domains from eligible sources can remain in `source_cache.json` for 30 days by default, controlled by `--retention-days`. Retention is enabled per source with `"retain": true`, so a temporary fetch failure does not immediately remove a domain. The generator also aborts without writing output when more than 20 percent of the previous list would be removed. That threshold can be changed with `--max-delta-ratio`, while `0` disables it. Runs restricted with `--src` or `--file` are exempt from this delta guard.

## Fetching the Normal Disposable Domain List with curl

The quickest useful integration requires no Python installation. Fetch the published normal list and use each line as a domain entry. The following is the exact command documented by the project.

```shell
curl https://raw.githubusercontent.com/disposable/disposable-email-domains/master/domains.txt
```

The response is a sorted, newline-separated text file. An application can compare the domain portion of a submitted address against this file, but the project does not prescribe an exact normalization or matching implementation. Internationalized names and public suffixes are especially relevant here because the Python dependencies include `idna` and `tldextract`. Those libraries are part of the generator package, but the README does not document them as a supported consumer API.

For production use, fetching the raw file during each request would add unnecessary network work. The README documents the autoupdated publication but does not specify caching intervals, update failures, or deployment policy. A consumer therefore needs to decide how stale its local copy may become. It should also choose whether to match the full domain or only the registrable portion. Those matching rules are application concerns, not behaviors guaranteed by this repository.

## Selecting Strict or Forwarding Modes for Signup Policy

The strict list is not simply a higher-confidence version of the normal list. It includes greylist domains from forwarding and alias services, plus providers that permit anonymous signup. The README says greylist membership comes from `mailservices.json` and explicit entries in `greylist.txt`. This mode can reject legitimate use cases when stable users rely on shared forwarding domains.

The forwarding list covers disposable and aliasing addresses but deliberately leaves freemail providers out. It is the clearer fit when a product wants to block temporary inboxes and shared aliases without treating consumer mailbox domains as disposable. Fetch it with the documented raw URL:

```shell
curl https://raw.githubusercontent.com/disposable/disposable-email-domains/master/domains_forwarding.txt
```

If classification details are needed, the companion JSON file maps domains to metadata. The repository does not define a stable schema beyond the fields named in the README, so consumers should not assume undocumented keys or values. In particular, a `verification` field should not be read as proof that the domain owner matches the person behind an individual mailbox. The list operates at domain granularity.

A service can also choose to allow the classification through while using email verification or another ownership check. The README does not claim that the project supplies mailbox-level validation. Domain screening is consequently a policy input, not a complete identity system.

## Installing the Python Generator with uv

The development workflow requires Python 3.13 or another later 3.x release, as declared by `pyproject.toml`, and `uv`. The README gives this setup sequence:

```shell
pip install --upgrade uv
uv sync --dev
uv run python disposable.py --help
uv run disposable --help
uv run ./.generate
```

The first command installs or updates `uv`. `uv sync --dev` resolves the locked development environment. The two help commands expose the repository script and module entry points, while the final command runs the generator. Seeing help text from the first two commands confirms that the local entry points load. The generator output should report fetched domain and hash counts plus additions and removals, as illustrated by the README.

This setup is for producing or updating data. A service that only needs screening can consume the raw text files without installing Python 3.13 or cloning the repository. Contributors and operators that modify collection logic need the development environment. The `pyproject.toml` also defines linting, type checking, security analysis, complexity checks, and pytest configuration, so local changes can follow the repository's own validation targets through the `Makefile`.

## External Keys, Cloudflare Retries, and Source Failure Modes

Most documented generation work uses public external sources, but two integrations can require environment configuration. Setting `DUSTMAIL_API_KEY` enables the dustmail.net shared-inbox source. The README explains that a Dashboard key beginning with `dm_live_` is required. Without that variable, the repository does not claim that this source will contribute.

`FLARESOLVERR_PROXIES` accepts comma-separated proxy URLs for temp-mail.org mailbox sampling. The documented shape is `http://user:pass@host:port`, and each mailbox request is assigned a different IP. Separately, setting `FLARESOLVERR_URL` to a running FlareSolverr instance allows sources that return a Cloudflare challenge page to be retried through that service. The README gives `http://127.0.0.1:8191` as an example endpoint, not as a required project configuration.

These retries create operational dependencies. A generator operator must be able to run FlareSolverr when that feature is enabled, and proxy availability can affect sampling. The retention cache reduces short-term data loss only for sources configured with `"retain": true`; upstream compilation sources remain unflagged. The large-removal guard is also limited: it protects against abnormal deltas, but it cannot establish that every retained domain is still trustworthy.

## Maintenance Signals, Release Gaps, and MIT Upgrade Work

The repository is not archived, and its last push was on 2026-10-14. There are no GitHub releases, so users should not expect semantic release notes or packaged release artifacts from that channel. `pyproject.toml` identifies the package version as `0.4` and uses `uv.lock`, `hatchling`, `pyproject.toml`, and a `src/` package layout. Dependency upgrades therefore involve reviewing both the project constraints and the lockfile.

The generator itself has recurring maintenance costs. Operators may need to repair or replace sources as websites, APIs, and anti-bot pages change. DNS, HTTP, WebSocket, public-suffix, timezone, HTTP/2, and DuckDB dependencies can also require version review, although the project constrains those dependencies in `pyproject.toml`. Source-specific keys and optional proxy infrastructure must be monitored by the person running generation.

The repository identifies its license as MIT. That designation does not remove the need to read `LICENSE` and preserve any applicable notices. It also does not transfer responsibility for the external services being queried. Consumers should review both the generated-data use case and their own obligations before incorporating the files.

## Disposable Domain Screening Versus Mailbox-Level Verification

A real alternative is an email verification service or an application-owned confirmation flow that sends a message and verifies access to the mailbox. Such systems evaluate a specific address and code at signup time. disposable/disposable instead evaluates a domain shared by potentially many users, which is faster to integrate and useful when an application only needs a screening signal.

The approaches answer different questions. A disposable-domain list can flag known short-lived providers before a message is sent, but a legitimate service can share infrastructure with abusive accounts. Mailbox verification can prove control of one inbox at one moment, but it does not by itself tell an application that the domain routinely offers temporary mail. An application may use the list first and email verification second, accepting that this is layered policy rather than a definitive classification.

The project is therefore the wrong tool for detecting newly introduced disposable providers before they appear in its sources, measuring message deliverability, or establishing an individual user's identity. Its generated files are also not a substitute for provider reputation intelligence, which the repository does not claim to provide.

## Conclusion

Application teams that need a maintained disposable-domain data source should start with `domains.txt` for broad screening, or `domains_forwarding.txt` when alias services must also be rejected while freemail remains acceptable. Teams that need verified mailbox ownership, provider reputation, or definitive evidence that an address is temporary should first inspect those capabilities in `domains_forwarding.json` and decide which generated mode matches their signup policy.

## FAQ

### Which disposable/disposable file should I use for signup validation?

Use `domains.txt` for the broad disposable-domain classification. Use `domains_forwarding.txt` when alias and forwarding domains should also be rejected while freemail providers remain acceptable.

### Does disposable/disposable verify individual temporary email accounts?

No. The project publishes domain classifications and metadata, not mailbox-level verification results. The README describes uses such as signup validation, but does not claim that a listed domain proves how any individual account will behave.

### How do I update the disposable/disposable domain lists?

Install `uv`, run `uv sync --dev`, and then execute `uv run ./.generate`. The generator refreshes domain and hash data and can be followed by a pull request according to the README.

## Sources

- [disposable/disposable on GitHub](https://github.com/disposable/disposable)
- [Issues](https://github.com/disposable/disposable/issues)
- [License: MIT](https://github.com/disposable/disposable/blob/master/LICENSE)
- [README](https://github.com/disposable/disposable/blob/master/README.md)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/disposable-disposable