Default answer: Leave catch-all off on a new company domain. Prefer explicit mailboxes (hello@, billing@, support@) so unknown local-parts are rejected at SMTP time. Enable catch-all only when you can name a specific miss you cannot afford—legacy printed addresses, a just-retired local-part, or a sales domain that must not bounce leads. If you cannot name the miss, keep it off.
Why catch-all is usually a trap
Catch-all accepts mail for any local-part that does not match an active mailbox. That removes the cheapest anti-spam control available: rejecting unknown recipients before the message is accepted. Dictionary attacks and bulk spam then deliver into the catch-all mailbox instead of bouncing.
Most teams turn it on “just in case.” The result is an inbox that fills with noise while legitimate role addresses remain uncreated. Outbound deliverability is unaffected—catch-all is purely inbound—but the operational cost is real: someone must triage the dump daily or the useful messages are buried.
When catch-all actually helps
Two narrow cases justify turning it on:
- Legacy or printed addresses still in the wild. Letterhead, invoices, or vendor forms still show info@ after the team standardized on hello@. Enable catch-all for a fixed window (e.g., 90 days) while you create the named mailboxes and update external records, then turn it off.
- One-person or very small operations that cannot pre-list every vendor typo. If the operator checks the catch-all mailbox daily and treats it as a temporary safety net rather than a permanent dumping ground, the tradeoff can be acceptable.
If billing@ does not exist yet, create billing@ instead of relying on catch-all. Explicit role mailboxes scale; catch-all does not.
Catch-all vs aliases vs shared role mailboxes
These are not interchangeable:
- Explicit mailbox — a real account ([email protected]) with its own login, storage, and sending identity.
- Alias — a secondary local-part that delivers into an existing mailbox (planned coverage in a follow-up piece). No separate login.
- Catch-all — a domain-level fallback that accepts any unmatched local-part and delivers it to one designated active mailbox.
Prefer named mailboxes first, then aliases for controlled variants, and catch-all last and only for a named reason.
How ArawaMail resolves inbound recipients
Receiving must be active before any mailbox can be created. Once mailboxes exist, an administrator selects at most one active mailbox as the catch-all destination on the domain details page. A disabled mailbox cannot serve as the catch-all.
Resolution order for each inbound envelope recipient:
- Exact active mailbox match.
- Active catch-all mailbox for the domain (if configured).
- Discard.
The original envelope recipient is preserved on the stored message, so the catch-all mailbox can see which address was used. Mail addressed to an exact but disabled mailbox follows the same fallback. Disabling the mailbox currently selected as catch-all automatically disables the domain catch-all until another active mailbox is chosen.
Forwarding side-effects
If the catch-all mailbox has verified forwarding destinations, catch-all messages are also forwarded while local copies are retained. Forwarding destinations must confirm within 24 hours. Plan limits apply: Free 1, Pro 5, Business 10 verified destinations per mailbox. Forwarded copies count toward the monthly transactional allowance.
Forwarded messages keep a local copy; a forwarding failure does not remove it. Prefer reading catch-all mail inside the ArawaMail mailbox rather than forwarding everything to Gmail or Workspace—forwarding hops can break SPF alignment for the next hop unless the provider rewrites the envelope or the receiver trusts ARC. ArawaMail does not document SRS or ARC rewriting for customer forwarding.
One-screen decision rule
- New domain, no legacy addresses in print or vendor systems → leave catch-all off.
- You can name a concrete miss you cannot afford (and will triage daily) → enable for a time-boxed period, then revisit.
- You are using it because “we might need it later” → leave it off and create the explicit role addresses instead.
Catch-all does not improve outbound deliverability. It only changes what happens to mail that would otherwise be rejected. For related inbound and deliverability context see Why emails go to spam, IMAP vs POP3 for business email, Stop using noreply@, and Move business email off Google Workspace. Role addresses and plan options are covered on the business email and pricing pages.
FAQ
Should a new company domain enable catch-all on day one?
No. Create the role mailboxes you actually need and keep unknown local-parts rejected.
If billing@ does not exist, is catch-all the right fix?
Usually no. Create billing@ as an explicit mailbox.
What happens to mail for a disabled user?
It falls through to the domain catch-all if one is configured; otherwise it is discarded.
Does catch-all hide which address the sender used?
No. The original envelope recipient is preserved on the stored message.
Does catch-all help outbound deliverability?
No. It is an inbound-only setting.