If a signup form rejected your address with a message that did not explain itself, there is a decent chance it queried a blocklist. The largest community-maintained one is worth understanding precisely, because its shape explains both why it works and why it is blunt.
The list in numbers
The repository disposable-email-domains/disposable-email-domains holds 5,614 GitHub stars and publishes a single flat file, disposable_email_blocklist.conf, one domain per line. On 24 October 2026 that file contains 9,927 domains. It is a plain text file, not a database, not an API. That design is the point: any service can fetch it, cache it, and check membership in a set lookup.
The file is not versioned by category. There is no "good throwaway" versus "abusive throwaway" distinction inside it, because a domain either accepts mail without identity verification or it does not.
The Firefox Relay case, and why it was rejected
A pull request in January 2022 proposed adding relay.firefox.com — Mozilla's email masking service — to the list. It reached the front page of Hacker News with 258 points. The pull request was closed without merging.
That outcome is the clearest available statement of what these lists are for. Firefox Relay is a privacy tool that gives a real person a forwarding alias. It is not an anonymous throwaway that anyone can mint by the thousand. The maintainers drew the line at "does this domain represent a disposable identity," not "is this domain not a normal mailbox." Understanding that distinction is the difference between using the list responsibly and cargo-culting it.
What a blocklist can and cannot tell you
A blocklist answers one question: is this domain known to be a throwaway service. That is a useful signal for abuse prevention and a poor signal for almost anything else, because it shares two failure modes with every list of its kind.
- It lags. New disposable domains appear faster than a community file can absorb them. A domain minted last week is not on today's list.
- It over-blocks by design. A developer testing their own signup flow with a throwaway address will be treated exactly like an abuser, because the list cannot see intent.
The inverse also holds. Being absent from the list does not mean a domain is legitimate, only that nobody has added it yet. Any decision built on "it passed the blocklist" is a decision built on a lagging snapshot.
The legitimate reason to test against the list
If you operate a disposable mail service, the blocklist is a compatibility target, not an enemy. Knowing whether your domains are listed tells you which customers will fail where, and that is worth monitoring deliberately rather than discovering through a support ticket. It also clarifies product boundaries: a consumer-facing inbox on a listed domain should expect to be refused by security-conscious signups, and the honest answer to that user is "this address is designed for testing, not for identity."
When your own flow is blocked
Two paths, and only one of them respects the system:
- Use an address that is not disposable. If the service wants a durable identity, a throwaway address is the wrong instrument and no amount of retrying changes that.
- If you operate the mail service and believe the listing is wrong, the mechanism is a pull request with evidence that the domain is not a throwaway service, exactly as the Firefox Relay proposal did. That is the legitimate channel, and it is a public one.
What does not work, and should not, is cycling through fresh domains to get past a check that exists to stop exactly that. The list updates; the work compounds; nothing is gained.
The takeaway
9,927 domains in a flat file, maintained by volunteers, with a documented precedent for who belongs on it and who does not. Read it as an intent classifier rather than a truth table, monitor it if you operate mail infrastructure, and stop treating a blocklist rejection as a technical problem to route around.