The sixty-second answer
Generally no. A catch-all accepts mail for every address at your domain that has never existed, so guessed and harvested addresses stop bouncing and start arriving. It also discards the 550 rejection that tells honest senders they got the address wrong. Named aliases give you the same coverage without the spam.
What a catch-all is, precisely
A catch-all is a rule that says: deliver mail addressed to anything at this domain to this one mailbox. Not just the addresses you created - every string that could appear before the @ sign, forever.
People turn it on for a good reason. They do not want to lose a message because a customer typed sale@ instead of sales@, or because an old address from a previous owner is still on a business card somewhere. That instinct is sound. The implementation is what causes trouble, because "never lose a typo" and "accept every address in the dictionary" are the same setting.
The rejection you gave up was doing work
Start with what normally happens when someone writes to an address that does not exist. The SMTP standard is specific: where the recipient "is known not to be a deliverable address, the SMTP server returns a 550 reply, typically with a string such as 'no such user'" [1]. That happens inside the conversation between the two servers, before the message body is accepted.
Three good things follow from that rejection. The sender finds out immediately, while they still remember writing the message. Your server never takes custody of the message, so it has no obligation to deal with it. And the sending party learns that the address is invalid - which matters enormously when the sender is not a customer.
A catch-all removes all three. Every address becomes deliverable, so nothing is ever rejected, so no one is ever told they got it wrong.
What it does to your spam load
Here is the part people underestimate. Address-guessing is a standard technique, and the SMTP standard describes it from the defender's side: a server that "determines that a large number of RCPT TO commands are being sent, most or all with invalid addresses, as part of such an attack" is entitled to close the connection after issuing an appropriate number of 550 replies [1]. The specification treats invalid-address floods as an attack to be repelled.
A catch-all is a standing instruction not to repel it. Every guess succeeds. The attacker does not have to know a single real address at your domain, because there are no wrong answers.
The second-order effect is worse than the volume. The standard notes that "accepting a message may trigger additional undesirable traffic by providing verification of the address" [1]. A domain that accepts everything advertises itself as a domain where everything works, and that information travels. The spam you get in month one is not the spam you get in month six.
The bounce problem
There is a mechanical consequence too. Once your server answers a message with 250 OK, it "is accepting responsibility for delivering or relaying the message", and if delivery later fails it "MUST formulate and mail a notification message" back to the envelope return path [1].
Now recall that plain SMTP "places no restriction on what a sending host can use as the MAIL FROM of a message" [3]. Spam forges that return path routinely. So a catch-all domain that accepts a flood and then fails to file it can end up mailing delivery notifications to strangers whose addresses were forged into the envelope. You become a small, unwilling participant in somebody else's campaign, using your own domain's reputation to do it.
The same reasoning applies to automatic replies. Auto-responders are a known source of "significant numbers of useless or unwanted responses" and "responses sent to inappropriate addresses" [4]. If you run an out-of-office or an autoresponder on the mailbox behind a catch-all, you are answering spam. At minimum, suppress responses to anything carrying an Auto-Submitted header with a value other than "no", and mark your own automatic replies as auto-replied so other systems can do the same [4].
The privacy angle nobody mentions
A catch-all mailbox accumulates other people's personal information that you never asked for: misdirected mail meant for a similarly named business, forwarded threads, attachments sent to a departed employee's guessed address.
Under PIPEDA's Schedule 1, personal information you hold has to be protected by safeguards appropriate to its sensitivity, regardless of the format in which it is held [5]; and information no longer required for an identified purpose "should be destroyed, erased, or made anonymous", with organisations obliged to "develop guidelines and implement procedures to govern the destruction of personal information" [5]. A mailbox designed to accept anything is a mailbox designed to accumulate material you have no identified purpose for. Our wider treatment is in business email privacy obligations in Canada and business email retention and records in Canada.
What to do instead
Three moves cover everything a catch-all was buying you.
Create the standard role addresses as aliases. INFO, SALES and SUPPORT on the business side; ABUSE, NOC and SECURITY for operations; POSTMASTER because any host with an SMTP server is expected to have one [2]. The standard is explicit that additional names and aliases are not prohibited [2], so add whatever else your business genuinely uses. Aliases cost nothing to run: expansion replaces the address in the envelope and leaves the rest of the envelope and the message body unchanged [1].
Alias the typos you actually get. Not every possible typo - the two or three real ones. Read a month of your existing mail, note the misspellings that appear, and create aliases for those. This is the entire legitimate value of a catch-all, delivered in ten minutes and then finished.
Keep old addresses alive deliberately. A departed employee's address, a former trading name, an address printed on old signage - these deserve named aliases with a decision behind each one, not blanket acceptance. The staff case has its own article: what to do with an employee's email account when they leave.
The related question of how many real mailboxes you need, as opposed to addresses, is answered in how many email addresses your small business actually needs.
One thing a catch-all does not cause
Be fair to it: a catch-all does not, by itself, make your outbound mail land in junk. That is a separate set of causes - missing authentication records, shared sending infrastructure, poor list hygiene - covered in why your business email goes to spam and SPF, DKIM and DMARC explained for small business. The catch-all's damage is inbound, and it is cumulative rather than sudden.
It is also worth knowing that publishing an address on your website has a legal consequence in Canada, independent of any catch-all. Under CASL, consent may be implied where a person has conspicuously published the address, the publication carries no statement declining unsolicited commercial messages, and the message is relevant to that person's business role [6]. That applies to a published info@ just as it does to a named address - which is an argument for choosing which addresses you publish, not for accepting all of them.
Where we sit
MapleMail does not meter aliases. That is deliberate, because the honest answer to "should I use a catch-all" is "no, use aliases instead", and that answer is worthless if aliases are the thing your provider charges for. You can create the role names, the typo variants and the legacy addresses your business genuinely needs, and let everything else be rejected the way the protocol intends.
We will turn a catch-all on for a migration window if you have inherited a domain and do not yet know what was in use. We will also ask you, at the end of that window, for the list of addresses worth keeping - and then turn it off.
Plans and what each mailbox includes are on the pricing page. The setting itself is free either way; the difference is what shows up in the morning.