language	en
license	cc-by-4.0
pretty_name	Disposable Email Compatibility
size_categories	n<1K
tags	disposable-email email-testing privacy signup-compatibility

Disposable Email Compatibility

Which platforms accept a disposable email address at signup — and which reject it.

A machine-readable dataset, kept current by pull request.

Browse the web edition, including the methodology, current verdict table, JSON download, and reuse terms.

Available as JSON and CSV, with a standards-based Data Package descriptor. GitHub also exposes the citation metadata in CITATION.cff.

curl -s https://raw.githubusercontent.com/sathishbanoth-coder/disposable-email-compatibility/main/data/platforms.json

{
  "slug": "notion",
  "name": "Notion",
  "accepts_disposable": "works",
  "notes": "Notion generally accepts disposable addresses for a personal-plan signup. It sends a numeric login code rather than a clickable link.",
  "last_checked": "2026-08",
  "source": "hand-tested"
}

Why this exists

If you build signup flows, test them, or write about email privacy, you keep needing the same fact: does this platform accept a disposable address? The answer is scattered across forum threads, is frequently out of date, and is usually asserted without anyone having checked.

This is that answer in one file, with the reasoning attached and a date on every row.

It is also useful in the other direction. If you run a service and are deciding whether to block disposable domains, the blocked rows show what that decision costs your users, and the notes explain why each platform made the call it did — KYC obligations, abuse economics, or account recovery.

The three verdicts

verdict	meaning
works	Disposable addresses are generally accepted at signup.
partial	Often accepted, but with a caveat that commonly bites. Read the note.
blocked	Reliably rejected, or the account becomes unrecoverable without a durable address.

partial is the most useful category and the one most lists omit. A platform that accepts the address at signup but then emails your login code to it every time you sign in has not really accepted it — it has deferred the problem. Adobe, Figma and Cursor all sit here for different reasons.

Current coverage

34 platforms: 11 works · 7 partial · 16 blocked

Twenty are hand-tested — someone completed the signup flow and recorded what happened. Fourteen are survey, meaning the behaviour is well documented and consistent but was not individually re-tested for this dataset. The source field on every row tells you which, so you can weight them yourself.

Methodology, and its limits

Being straight about what this is and is not:

• Point-in-time. Every row carries last_checked. Platforms change their filtering without announcement, and a row six months old is a hint rather than a fact.
• Signup only. This records whether the address is accepted at account creation. It does not track whether an account is later restricted, nor whether a platform tolerates disposable addresses on existing accounts.
• Region-dependent. Some platforms filter more aggressively in some countries. Results were observed from a single region.
• Domain-dependent. Disposable-email blocklists cover different domain sets. A platform that rejects one provider's domain may accept another's. Treat blocked as "expect rejection", not "provably impossible".
• Not an endorsement. A works verdict describes observed behaviour. It is not advice to violate any platform's terms, and several platforms that technically accept these addresses prohibit them in their terms.

Contributing

Corrections are the point. Platforms change, and a dataset nobody updates is worse than no dataset.

To add or correct a row, edit data/platforms.json and open a PR. Please include:

1. When you tested it — last_checked as YYYY-MM
2. What actually happened — rejected at the form, accepted then locked, code delivered but unusable later
3. Which disposable domain you used, in the PR description — not the row, since blocklist coverage varies by provider

CONTRIBUTING.md has the full field reference. npm run validate checks your edit against schema.json before you push.

Rows changed from works to blocked are especially welcome. Those are the ones that go stale silently.

Using it

The file is plain JSON with no dependencies. Fetch it, vendor it, or add this repo as a submodule.

const data = await fetch(URL).then(r => r.json());
const blocked = new Set(
  data.platforms.filter(p => p.accepts_disposable === 'blocked').map(p => p.slug)
);

For testing your own signup flows against real inboxes, see tempmailgrab — a disposable-inbox client with server-side OTP extraction, which is where this research came from.

Licence

Data is CC BY 4.0 — use it anywhere, including commercially, with attribution. Scripts are MIT.

Suggested citation: TempMailGrab (2026), “Disposable Email Compatibility”, version 1.0.0, CC BY 4.0. Link to the canonical research page or this repository.

Compiled and maintained alongside TempMailGrab.