Catch-All Domains: One Domain, Unlimited Email Aliases
Catch-all domain email aliases let you use new recipient names without creating a separate mailbox for each one. Mail for otherwise unregistered addresses is routed to a configured default destination. That makes per-service naming and controlled email tests convenient. However, “unlimited aliases” describes on-demand recipient naming, not unlimited storage, separate private inboxes, or guaranteed platform acceptance. Your provider's configuration, quotas, and access rules still apply.
This guide includes a current first-hand review of Inboxto's public application implementation, not a live email-delivery test.
What Catch-All Actually Collects
In an address such as coffee@inbox.example.com, coffee is the local part and inbox.example.com is the domain. A catch-all handles local parts that do not have their own registered route. You can invent names for legitimate uses and collect their mail at one destination.
Catch-all is not the same as plus-addressing. A name such as signup+x depends on the provider's handling of subaddresses; do not assume the plus sign is automatically stripped or normalized. Use straightforward recipient names when you need predictable tests.
Cloudflare's official Email Routing documentation illustrates catch-all forwarding, including misspelled recipients. Its implementation-specific rules are not Inboxto's configuration instructions. For the wider architecture, see Inboxto for developers.
What We Verified in Inboxto Today
First-hand public implementation review, October 8, 2026: We inspected the deployed application modules linked from h5.inboxto.app. The new-domain flow exposes Advanced Options, Enable catch-all address, and Default catch-all address. Its explanatory text says mail to unregistered addresses will be delivered to that default address.
The settings use catch_all_enabled and catch_all_forward_address; the latter combines your chosen local part with the domain. The existing-domain page offers Edit Settings, Save, and a Forwards to display. Its DNS flow checks MX and TXT verification results separately.
This verifies the current interface labels and configuration shape. We did not sign into a private account, change DNS, send messages, or verify backend routing. It does not prove that an arbitrary recipient will work in your account. Complete the acceptance checks below after your own authorized setup.
Five Steps to Configure a Monitored Destination
- Choose an unused domain boundary. If your main domain already receives work or personal email, do not replace its MX records casually. Prefer an unused dedicated subdomain such as
inbox.example.com, where the product supports your intended setup. Record existing DNS values for rollback before making changes. - Add the domain under your Premium account. Inboxto's public plan information places custom domains in Premium. Enter the hostname without
https://, paths, or an email local part. For the complete domain workflow, follow the custom-domain setup guide. - Enable the explicit fallback. Open Advanced Options, turn on Enable catch-all address, and supply Default catch-all address. For example, choose
qafor a destination displayed asqa@inbox.example.com. Ensure you can actually open and monitor that receiving address; enabling a toggle is not an access test. - Publish and verify the displayed DNS records. Copy the current MX destination and the domain-specific TXT verification value from your own setup screen. The TXT name shown in the reviewed flow is
inboxto-verify. Use Verify DNS and check both results. Do not copy an old endpoint or someone else's verification token. - Review the destination and test deliberately. On the existing-domain page, check Forwards to; use Edit Settings and Save if changes are needed. Perform the following acceptance checks with harmless messages and addresses you control. Avoid customer data, active reset secrets, or production traffic.
A Three-Recipient Acceptance Plan
Do not equate “domain verified” with “every recipient tested.” Our proposed checklist separates fallback routing from an explicitly registered route and from access to the receiving inbox:
| Proposed check | What to inspect | What it does not prove |
|---|---|---|
Send to unregistered test-20261008-01@inbox.example.com |
Message appears at your configured default destination | All senders will deliver successfully |
Send to a second unregistered name, test-20261008-02@inbox.example.com |
Both messages can be distinguished by recipient and test marker | Two recipient names create two isolated mailboxes |
| Send to an explicitly registered address on that domain | Its configured receiving behavior and your access are correct | Catch-all overrides explicit routes or grants another user access |
These are reader acceptance steps, not tests completed for this article. If your tools expose insufficient recipient information to distinguish parallel runs, do not assume safe isolation. Check the current API and message fields before automating; our email-verification automation guide explains the broader testing workflow.
Useful Names Need a Small Registry
For per-service email, record which name you gave to which service, its purpose, and whether you still need it for recovery. A naming scheme saves time only if you can later identify the correct destination and account.
For QA, use unique run markers and harmless test content. Catch-all avoids individually provisioning every recipient name, but messages may still share one destination. Filter and correlate by the actual fields your provider exposes rather than treating different names as different authorization boundaries.
If spam arrives at an address used for one service, it is a useful investigation clue, not proof that the service leaked it. Addresses can be guessed, forwarded, or exposed through other routes. See how spammers obtain email addresses before attributing blame.
The Trade-Off: Typos, Spam, and Weak Isolation
Catch-all can collect typo mail: cofee@inbox.example.com may be accepted alongside coffee@inbox.example.com. That is convenient but broadens the set of recipients that can attract unwanted messages. Use it when the naming flexibility justifies the monitoring burden; otherwise prefer explicit addresses.
Deleting an explicitly created address is not necessarily a way to reject mail to that name while catch-all remains enabled. The name could fall back into the unregistered-address route. Verify rejection behavior before promising yourself that an alias is retired.
Multiple names on the same domain can also be correlated. Catch-all is neither anonymity nor a separate security boundary. It does not bypass platform blocks, guarantee “non-blacklisted” status, or justify coupon abuse or evading account restrictions. Our email privacy guide covers the broader limits. Inboxto is an email product, not an SMS service.
Persistent Addresses Still Have Storage and Access Limits
Inboxto's public FAQ says addresses persist until deleted. Free includes 3 persistent addresses, 7-day ordinary-mail retention, 5 permanently starred messages, and 5 AI summaries per day. Premium includes unlimited addresses, 90-day ordinary-mail retention, unlimited starred messages and AI summaries, and custom domains.
Address persistence does not mean every message remains forever. Catch-all does not remove storage or operational limits. Star useful non-sensitive records, not a collection of active login codes or reset links. AI summaries assist reading; they do not determine whether mail is safe.
Keep account access, domain renewal, registrar security, and DNS ownership in order. Do not depend on an unsigned browser session as your sole recovery path for an important account. This receiving setup is not proof of outbound sending capability or acceptance by another platform.
Sources and Your Next Step
Public sources reviewed on October 8, 2026:
- Cloudflare: Email Routing addresses and catch-all rules.
- Inboxto: Public plans and FAQ.
- Inboxto application: Current public custom-domain setup implementation.
For controlled per-service naming or QA, open Inboxto, review Premium custom-domain settings, and configure a destination you can monitor. Confirm routing and access with harmless messages before depending on it. One catch-all domain can simplify recipient naming; it does not create unlimited independent inboxes.