On the surface, it seems trivial: type any address and the mail arrives. In real terms, that instant feel is an engineering choice: accept first, decide context later. This explainer unpacks how catch‑all and random alias generation remove friction while controlling abuse. For broader mechanics across MX routing, inbox lifecycles, and tokenized reuse, see the pillar Temporary Email Architecture: End‑to‑End (A–Z).

TL;DR / Key Takeaways

Catch‑all lets a domain accept any local‑part before @, eliminating pre‑creation of mailboxes.
Random aliases copy in a tap, reduce collisions, and avoid guessable patterns.
Controls matter: rate limits, quotas, heuristics, and short TTLs keep speed without chaos.
Use a reusable inbox for receipts/returns and resets; use short-lived for one‑time OTP.
Per policy, attachments are rejected; HTML is sanitized; email bodies expire automatically.

Catch‑All That Just Works

Reduce clicks by skipping pre‑creation and mapping messages dynamically to a mailbox context.

How Catch‑All Works

A catch‑all domain accepts any local part (left of the @) and resolves delivery at the edge. The SMTP envelope (RCPT TO) is validated against domain policy rather than a pre‑existing mailbox row. Depending on rules and user state, the system routes the message into a mailbox context that may be ephemeral (short-lived) or token‑protected (reusable).

Surprisingly, this flips the usual flow. Instead of “create → verify → receive,” it’s “receive → assign → show.” There’s a catch: you must bound acceptance with size limits and safe rendering.

Mapping: Domain → Handler → Mailbox Context

Domain policy: catch_all = true toggles acceptance; blocklists allow precise carve‑outs.
Handler: a router inspects local parts, headers, and IP reputations, then picks a context.
Mailbox context: ephemeral or reusable; contexts define TTL (e.g., 24h display window), quotas, and token requirements.

Pros and Cons

Pros

Zero‑step onboarding; any local part is viable immediately.
Lower friction for OTP and signups; fewer abandoned forms.
Works well with temp mail basics and domain rotation.

Cons

More unsolicited mail if not guarded.
Extra care for rendering: sanitize HTML and block trackers.
Requires robust abuse controls to avoid backscatter and resource waste.

Acceptance Policy (Safe by Default)

Maximum size: reject large bodies/attachments at SMTP; enforce message bytes quota per context.
Attachments: reject outright (receive‑only, no attachments) to reduce risk and storage load.
Rendering: sanitize HTML; proxy images; strip trackers.
Expiry: display window ~24h for received mail in ephemeral contexts; purge on expiry.

Generate Smart Random Aliases

Create an alias instantly, copy it in one move, and keep patterns difficult to predict.

How Aliases Are Created

When a user taps Generate, the system forms a local‑part using entropy from time and device signals. Not all generators are equal. Strong ones:

Use base62/hex mixes with bias checks to avoid readable patterns like aaa111.
Enforce minimum length (e.g., 12+ chars) while keeping form‑friendly.
Apply character set rules to avoid mail‑host quirks (. sequencing, consecutive -, etc.).

Collision Checks and TTL

Collision: a fast Bloom filter + hash set detects prior use; regenerate until unique.
TTL: short‑life aliases inherit a display TTL (e.g., ~24h post‑receipt); reusable aliases bind to a token and can be reopened later.

UX That Encourages the Right Use

One‑tap copy with visible alias.
Regenerate the button when a site rejects a pattern.
TTL badge to set expectations for short-lived inboxes.
Warnings for unusual characters, a few sites won’t accept.
Cross‑link to 10‑minute‑style inboxes when the intent is disposable.

Subaddressing (user+tag)

Plus‑addressing (user+tag@domain) is handy for sorting, but websites inconsistently support it. On balance, subaddressing is excellent for personal domains; for friction‑free signups at scale, random aliases on a catch‑all domain tend to pass more validations. For developer clarity, we briefly compare it with catch‑all routing in the FAQ below.

Quick How‑To: Generate and Use an Alias

Step 1: Create an alias

Tap Generate to receive a random local‑part; copy it with one tap. If a website rejects it, tap Regenerate for a fresh pattern.

Step 2: Choose the proper context

Use short-lived for one‑time codes; use reusable addresses when you need receipts, returns, or password resets later.

Control Abuse Without Slowing

Keep the experience instant while rate‑limiting blatant abuse and unusual traffic spikes.

Rate Limits and Quotas

Per‑IP & per‑alias throttles: burst limits for OTP bursts; sustained caps to deter scraping.
Domain quotas: cap per‑domain deliveries per user/session to stop one site from flooding an inbox.
Response shaping: fail fast at SMTP for banned senders to save CPU and bandwidth.

Heuristics and Anomaly Signals

N‑gram & pattern risk: flag repeated prefixes (e.g., sale, verify) that indicate scripted misuse.
Sender reputation: weigh rDNS, SPF/DMARC presence, and prior outcomes
[Suy luận: combined signals improve triage, but exact weights vary by provider].
Per‑site domain rotation: rotate across domains to avoid throttling, while keeping continuity when needed, as discussed in the pillar.

Short TTL and Minimal Storage

Short display windows keep data lean and reduce abuse value.
No attachments; HTML sanitized reduces risk surface and rendering costs.
Delete on expiry: remove message bodies after the display window ends.

For mobile convenience, users who often sign up on the go should consider temp mail on Android and iOS for quicker access and notifications.

Choose Reusable vs Short‑Life

Match the inbox type to your scenario: continuity for receipts, disposability for codes.

Scenario Comparison

Scenario	Recommended	Why
One‑time OTP	Short‑life	Minimizes retention; fewer traces after code use
Account signup you may revisit	Reusable	Tokenized continuity for future logins
E‑commerce receipts & returns	Reusable	Keep proof of purchase and shipment updates
Newsletter or promo trials	Short‑life	Easy opt‑out by letting the inbox expire
Password resets	Reusable	You need the same address to recover accounts

Token Protection (Reusable)

Reusable addresses bind to an access token. The token reopens the same mailbox later without exposing personal identity. Lose the token, and the mailbox cannot be restored. As a matter of fact, that rigid boundary is what protects anonymity at scale.

For newcomers, the temp mail overview page offers a quick primer and links to FAQs.

FAQ

Does a catch-all domain increase spam?

It increases acceptance surface area, but rate-limits and sender reputation controls keep it manageable.

Can random aliases collide?

With sufficient length and entropy, practical collision rates are negligible; generators re-roll on conflicts.

When should I use plus-addressing?

Use it when websites support it reliably. Otherwise, random aliases pass validation more consistently.

Is a reusable inbox safer than a short-lived one?

Neither is “safer” universally. Reusable gives continuity; short-life minimizes retention.

Can I block attachments entirely?

Yes. Receive-only systems reject attachments by policy to prevent abuse and reduce storage.

How long are messages kept?

Display windows are short—roughly a day for ephemeral contexts—after which bodies are purged.

Will image tracking be blocked?

Images are proxied; trackers are stripped during sanitize to reduce fingerprinting.

Can I forward messages to my personal email?

Use reusable contexts with token access; forwarding may be intentionally limited to preserve privacy.

What if an OTP doesn’t arrive?

Resend after a short interval, check the exact alias, and try a different domain via rotation.

Is there a mobile app?

Yes. See temp mail on Android and iOS for apps and notifications.

Conclusion

The bottom line is this: catch‑all acceptance and smart alias generation remove setup friction. At the same time, guardrails keep the system fast and safe. Choose a short‑life inbox when you want to disappear; choose a reusable address when you need a paper trail. In practice, that simple decision saves headaches later.

Read the Temporary Email Architecture: End‑to‑End (A–Z) pillar for a deeper end-to-end pipeline view.