The disposable email problem in 2026

“Disposable email” is one of those phrases that means six different things depending on who is using it. To a privacy-conscious user, it is a way to sign up for a newsletter without exposing their personal Gmail. To a fraud-detection vendor, it is a signal to block. To an SRE, it is a wildcard MX record on a domain they do not own. To a developer trying to test an OTP flow, it is the cheapest available option that occasionally works.

This post is about why those six interpretations are in tension, what abuse actually looks like in 2026, why a real signup flow is right to block disposable domains, and what a programmable inbox does differently.

What “disposable email” means

Three categories tend to get conflated.

Category 1: ad-supported web disposable inboxes

Sites like the ones that show up when you search “10 minute mail.” A wildcard MX record on a domain the operator owns, a webmail-style UI, ad inventory paying the bill. You visit the URL, you get a randomly-generated address on a public domain, you read incoming mail in a browser tab. The address typically lasts 10-30 minutes, after which the inbox is wiped.

The signup-blocklist databases (disposable-email-domains on npm, the Spamhaus ADL, the various paid feeds) exist almost entirely to identify these.

Category 2: email-aliasing services

Services like SimpleLogin, AnonAddy, Apple’s Hide My Email, Firefox Relay, DuckDuckGo Email Protection. These forward to a real personal inbox. The address is “burner” in that the user can revoke it, but the underlying inbox is not disposable — it is a privacy-preserving alias.

These are usually not on disposable-email blocklists, because they are forwarding to a real user, and blocking them blocks privacy-conscious users rather than abusers.

Category 3: programmable email APIs

What catchotp is. A REST API that creates inboxes on a real domain and exposes received mail as structured JSON. Used by developers for OTP testing, E2E signup flows, AI agents, and burner addresses for evaluating SaaS products without exposing a personal inbox.

These are typically not on blocklists either, because they are scriptable, scoped to API keys, and traceable through an audit log. Domains rotate, abuse is rate-limited, and the operator has a billing relationship with the user.

The blocklist databases generally only catch Category 1, but the language used to describe all three is the same. That is the source of most of the confusion.

Why apps block disposable domains

The defensive posture is rational. Three concrete abuse patterns:

1. Free-tier farming

A SaaS product offers a free tier. Cost of acquisition is “the email address.” Abusers register hundreds of accounts at disposable domains, exhaust the free tier on each, and arbitrage the result. The classic version is image-generation credits; the modern version is LLM tokens.

The block: any signup from a known disposable domain is denied, with a “please use a corporate or personal email” error message.

2. Review bombing and signal manipulation

An app has user-generated content, ratings, or upvotes. Burner accounts are cheap to create. The abuse is review-bombing competitor products, upvoting your own SEO content, or flooding a Q&A site with promotional answers.

The block: read-only access for accounts on disposable domains, or a hold-and-review queue.

3. Trial-credit farming

A platform offers free credits to new accounts ($10 of compute, $5 of usage, etc.). Abusers register at scale. The economic shape is identical to free-tier farming but the asset is more directly fungible (sometimes resellable).

The block: aggressive friction (phone verification, payment method on file) for accounts on disposable domains.

All three blocks are rational. None of them target the legitimate uses of programmable email or aliasing services. The collateral damage is usually friction, not denial — a phone-verification step, an additional captcha, a delayed activation. Tolerable.

How blocklists work

The actual mechanics, because they shape what catchotp can and cannot promise.

Domain-level blocklists

The most common implementation. A static list of known disposable domains, updated on some cadence, queried at signup. Examples: disposable-email-domains on GitHub (~3,000 domains, weekly updates), commercial vendors like Kickbox or DeBounce, MaxMind’s email scoring.

Programmable-email services are generally not included on these lists — domain operators deliberately rotate domains to avoid catchall blocking, and the operators have a contact path for getting un-listed if a domain accidentally gets added.

MX-pattern detection

A more sophisticated layer. Some fraud-detection vendors look for wildcard MX records, MX records that point at known disposable infrastructure, or domains with anomalous DNS lifecycle (registered yesterday, MX changed in last 7 days). This catches some Category 1 services that would otherwise rotate domains to evade list-based blocking.

Programmable-email services usually pass this layer because the MX setup is identical to legitimate transactional providers — pointing at AWS SES inbound, with normal DNS lifecycle, no wildcards.

Behavioral signals

The newest layer. Fraud-detection vendors look at the signup velocity from a domain, the delivery success rate, the conversion to paid, the absence of a real human pattern (no opens, no clicks, no engagement after signup). This catches abuse independent of domain reputation.

Programmable-email services intentionally have low engagement signals (the use case is automation), so behavioral filters that key on engagement will sometimes flag them. The fix is a per-customer reputation signal — verified payment method on the API account, audit log of legitimate test usage, etc. — that vouches for the addresses.

Why catchotp is different

Three properties make a programmable inbox not the abuse-vector that domain-blocklists are designed to stop.

1. Account-scoped, not anonymous

Every catchotp address is created via an API call from an authenticated account. The account has an email, a payment method on file (above the free tier), and an audit log. Abuse traces back to an identifiable customer, who can be banned and (above the free tier) charged for damages. This is the same shape as Twilio for SMS and Stripe for payments.

A web-disposable-inbox site, by contrast, has no account — anyone with a browser is “the customer.” There is nobody to ban.

2. Per-pipeline scoped credentials

API keys are scoped to specific pipelines. A leak in one pipeline does not blast-radius into others. If a key is misused, only that key gets revoked — the customer’s other integrations keep working.

This means the unit of abuse-response is “a single CI pipeline” rather than “an entire domain.” Fine-grained takedown is achievable.

3. Audit logs and rate limits

Every inbound message records sender, recipient, message ID, and timestamp into a 365-day audit log. Per-account rate limits are visible to the customer in the dashboard. Per-domain abuse signals (sudden spike in inbound from a new sender, unusual address-pattern usage) are detectable and acted on.

This is the cost of operating a real service rather than a free-tier farm. It is also the reason why apps that are right to block Category 1 can safely allow Category 3.

What this means for your signup flow

Three concrete recommendations if you operate a signup flow in 2026.

Recommendation 1: block Category 1, allow the rest

Use the standard disposable-email-domains list (or your vendor’s equivalent) to deny known web-disposable domains. Do not block the entire concept of “any non-Gmail address.” Most of the false positives we see in the wild are corporate addresses on small-domain mail providers, not disposable inboxes.

import disposableDomains from 'disposable-email-domains';

function isLikelyDisposable(email: string): boolean {
  const domain = email.split('@')[1]?.toLowerCase();
  return domain ? disposableDomains.includes(domain) : false;
}

This handles 95% of the abuse vectors and almost none of the legitimate use cases.

Recommendation 2: add friction, not denial

For domains that score “ambiguous” (recent registration, low-engagement signals, but not on the blocklist), add a phone-verification step. Most legitimate users complete it; most abusers do not. The conversion-rate cost of the friction step is usually under 5%.

Recommendation 3: do not block transactional providers’ return paths

The single most common self-inflicted wound. Apps block the email domain bounces.transactional-provider.com, then are surprised that bounce-handling for legitimate signups stops working. Whitelist the major providers’ bounce domains explicitly.

What this means for your tests

If you are testing your own signup flow, you need real DNS, real DKIM, and a domain that is not on the disposable-email blocklist. That is what a programmable email service gives you.

If you point your test fixtures at a Category 1 disposable inbox, you are testing nothing useful — half the time your test will hit the disposable-domain block in your own product and fail for the right reason. The other half, the disposable inbox will be down or rate-limited and the test will fail for the wrong reason.

The right pattern, as covered in the OTP testing guide, is one programmable inbox per test, with a long-poll waiter and a TTL.

How catchotp helps

We are Category 3. Real domain, real DNS, real DKIM, account-scoped, audit-logged, not on disposable-email blocklists. The free tier is rate-limited to 1,000 messages a month and 5 concurrent inboxes — abuse-resistant by design while still being free for actual use.

Free tier: 5 inboxes, 1,000 messages a month, no credit card. Start free or read the programmable vs disposable comparison for the side-by-side.

Related reading

• Programmable Email vs Disposable Email — the developer’s-eye view of the same difference.
• Best Email Testing Tools for Developers in 2026 — where catchotp fits in the broader landscape.
• The burner emails use case covers privacy-first signup patterns.

The shorter version: blocklists exist for a reason. Programmable inboxes are a different category, and apps that want to defend against abuse should defend against the actual abuse pattern, not the word “disposable.”