Catch-All Mailboxes Are Directory Harvest Targets
A catch-all mailbox looks like a safety net: every misspelled address, every old alias, every message to a random string still lands somewhere a human can read it. The pitch is simple and it sells. The problem is that the same feature is a directory harvest accelerant, and Microsoft says so in its own documentation. A catch-all does not just collect more spam; it tells spammers the domain accepts everything, and that confirmation multiplies the next wave.
The delivery confirmation problem that turns a catch-all into a harvest target
Directory harvest attacks work by guessing. A bot sends mail to jsmith@, j.smith@, john.smith@, sales@, and a hundred random strings, then watches what happens. On a normal tenant, unknown recipients get rejected at the edge, so the guesses die quietly. On a tenant with a catch-all, every guess generates a delivery. The attacker does not need a bounce or a read receipt. The absence of a rejection is the signal. That is the mechanism Microsoft warns about when it says catch-all mailboxes increase spam, and it is worth understanding why the warning is stronger than a simple volume complaint.
Once a domain is confirmed to accept all addresses, it gets promoted on the lists that harvesters maintain. The next campaign does not guess a hundred addresses; it guesses ten thousand, because the economics changed. Expect future spam to rise by roughly an order of magnitude after a catch-all has been live long enough to be catalogued, and expect the sender reputation of your domain to take collateral damage along the way. A catch-all mailbox is a directory harvest target first and a convenience feature second.
Microsoft 365 lacks a native catch-all setting, which is why the workaround exists at all. People build it, then discover the trade-off after the spam arrives. The workaround itself is not subtle. It requires an Exchange administrator role and a deliberate break in the default accepted-domain model, which is exactly the kind of change that should make an admin pause.
What the workaround actually changes, and the safer alternatives
The standard trick is to convert the domain to an internal relay domain and add a mail flow rule that redirects unknown-recipient mail to one mailbox. In the accepted domains list, an internal relay domain relays mail for unknown recipients onward, so Exchange Online accepts the message even when no recipient matches and hands it to the transport rule. Authoritative accepted domains behave differently: they enable Directory-Based Edge Blocking, which rejects mail for unknown recipients at the edge before it enters the organization. That rejection is the protection the workaround removes. Microsoft documentation advises against selecting internal relay when all recipients are in Microsoft 365, and the reason is structural. Internal relay expects a connector to an on-premises mail server, so in a cloud-only tenant the setting describes a topology that does not exist.
There is a narrower option that keeps the domain authoritative. A shared mailbox with aliases preserves an authoritative domain while giving you a single inbox that accepts mail for a defined set of addresses. You enumerate the aliases you actually want, and everything else still gets rejected by DBEB. That covers the legitimate use cases, such as a former employee’s address or a department alias that changed names, without opening the domain to arbitrary strings. The catch-all workaround trades edge rejection for a redirect message rule, and the trade is rarely worth it.
If you inherit a tenant where the workaround is already in place, check three things before you touch anything. Confirm the accepted domain type, review the transport rule that redirects unknown-recipient mail, and look at the connector configuration for anything pointing at an on-premises mail server that no longer exists. Removing the internal relay setting and the rule restores DBEB, and the spam volume usually drops within days as harvesters stop getting confirmations. Anti-spam and anti-malware policies do not fix this problem; they filter content, not address enumeration. The enumeration happens at the SMTP layer, which is where the accepted domain decision lives.
Compare the alternatives honestly. Google Workspace has no catch-all toggle either, and cPanel-style hosts offer one because they assume a single mailbox per domain and no edge filtering. Exchange Online is built around authoritative domains and recipient validation, and that design is the feature. If you need a catch-all for a legacy domain, consider routing that domain through a service such as allmail.one or a subdomain dedicated to it, so the primary domain keeps its authoritative status and its DBEB protection. If you need it for a handful of addresses, use aliases on a shared mailbox. Either path keeps the rejection behavior that stops harvesters cold.
The practical takeaway is that a catch-all is not a neutral convenience. It is a published statement that your domain accepts any address, and harvesters treat that statement as an invitation. Audit your accepted domains in the Exchange admin center, confirm every domain is authoritative unless you genuinely run a hybrid topology with a connector to an on-premises mail server, and remove any internal relay mail flow rule that redirects unknown-recipient mail to a single mailbox. Microsoft Learn documents the behavior clearly enough that the decision should be deliberate rather than accidental. If a stakeholder insists on the catch-all, show them the delivery logs for a week and count how many messages went to addresses no one recognizes. That number is the cost, and it grows.