Catch-All or Role Aliases — Which Email Setup Fits Your Team?

When you add a custom domain in Biza Email, two routing decisions come up almost immediately. First: should you create explicit addresses like sales@, support@, and billing@? Second: should you enable a catch-all so that anything sent to an unknown address on your domain still lands somewhere instead of bouncing? Both are easy to configure. Whether each is a good idea depends on your team size, how you acquired your domain, and your tolerance for spam.

What a catch-all actually does

A catch-all is a fallback rule: if no specific mailbox or alias matches the recipient address, deliver it here anyway. In Biza Email, you enable it under Domain Settings → Routing → Catch-all destination and point it at any inbox or shared mailbox.

[email protected]  →  [email protected]  (catch-all)
[email protected]            →  sales team inbox      (explicit alias, wins first)

Explicit aliases always take priority. The catch-all only fires when nothing else matches.

When a catch-all makes sense:

• You are a solo operator or a two-person team and you genuinely cannot afford to miss email sent to a mistyped address (supprot@, sale@, billing2022@).
• Your domain is freshly registered and you have not yet decided which addresses you need. A catch-all is a good temporary net while you figure out your routing.
• You handed out several custom addresses to different contexts over the years (newsletters@, hello@, a conference badge scan) and do not want to enumerate them all upfront.

When a catch-all is a liability:

Your domain's age and reputation are the key variables. Spammers routinely run dictionary attacks against domains — they fire off thousands of messages to a@, aa@, aaron@, ab@, ... and see what sticks. A catch-all means every one of those sticks. On a domain older than a couple of years that has appeared in any public list or WHOIS record, a catch-all inbox can fill with hundreds of junk messages per day within weeks of enabling it.

If you inherited a domain that has been registered for a while, test before committing. Enable the catch-all pointed at a dedicated mailbox, watch it for 72 hours, and look at the volume. If it is already receiving obvious dictionary-attack traffic, turn it off and enumerate your real aliases explicitly instead.

Role aliases: explicit and boring in the best way

A role alias (sales@, support@, billing@, info@, hello@) is an address you declare, pointed at one or more real inboxes or a shared mailbox. In Biza Email these live under Domain Settings → Aliases.

Explicit aliases have two advantages over a catch-all:

1. Unknown addresses hard-bounce. If someone miskeys your address, they get a delivery failure immediately and can correct it. This is arguably better for them than silent delivery to a mailbox you never check.
2. Spam filters have a clean signal. Mail to an address that does not exist on your domain never enters your system. That keeps your shared inboxes clean and your storage usage honest.

The downside is maintenance: you have to create the alias before handing it out. If you give your address as enquiries@ at a trade show and the alias does not exist yet, those emails bounce.

A sensible starting set for a small team:

Alias	Route to
hello@ or info@	Owner or shared general inbox
support@	Support shared mailbox
sales@	Sales shared mailbox or individual
billing@	Finance or owner
noreply@	Null route (discard)

In Biza Email's routing rules, a null route is a valid destination — useful for noreply@ so it accepts mail (avoiding backscatter) but discards it silently.

Spam tradeoffs, directly

Neither approach is spam-proof, but they fail in different directions.

Catch-all exposes you to dictionary spam and makes spam filtering harder because the filter cannot use "this address doesn't exist" as a signal. Your spam folder ends up being the only line of defense.

Explicit aliases mean unknown addresses never enter your system at all. But spammers also know your real addresses once you use them publicly. support@ and info@ are guessable and will get probed. The difference is that the volume is lower and your filters can use reputation and header analysis without being flooded by pure dictionary noise first.

One pattern that works well: use explicit aliases for any address you make public, and a catch-all pointed at a quarantine mailbox (one you check weekly, not hourly) as a safety net for the rest. You get the routing clarity of aliases and the typo-resilience of a catch-all, without mixing catch-all noise into your active inboxes.

A quick decision guide

• Domain is less than one year old and not widely published → catch-all is low risk, convenient while you are still figuring out your address structure.
• Domain is older or has appeared in public records → skip the catch-all or route it to a low-priority quarantine inbox.
• Team has defined functions (support, sales, billing) → create explicit role aliases regardless. They clarify ownership and make shared inboxes easier to staff.
• Solo operator who moves fast → catch-all plus a few explicit aliases for anything you print on business cards. Review the catch-all folder weekly.
• You are migrating from another provider → enumerate all addresses that currently receive real mail, create them as explicit aliases first, then decide whether you still need a catch-all for anything you missed.

You can change either setting at any time in Biza Email without affecting delivery of mail to your explicit aliases — they always resolve first. Start conservative, watch the spam volume for a week, and adjust from there.