Most companies own more domains than they use. There's the brand you acquired and never migrated, the common misspelling you bought defensively, the campaign domain from two years ago, and the country variant somebody registered because it was cheap.
None of them need mailboxes. All of them receive mail — a customer who typed the old brand name, a supplier still using an address from before the acquisition, an automated system nobody has updated. Right now that mail is almost certainly bouncing, and nobody knows how much of it there's.
An external catch-all handles this without provisioning anything: it points the whole domain at an address you already read. No mailbox, no storage, no per-seat cost, no password to manage. There are real trade-offs, and they're worth knowing before you switch one on.
Three Ways to Handle an Address
| Mechanism | What exists | Storage | Can send as it |
|---|---|---|---|
| Mailbox | Real storage, its own login | Yes, its own quota | Yes |
| Alias | An extra address on an existing mailbox | No — shares the target's | Yes, if sending is enabled |
| Catch-all routing | Nothing — a rule at the domain level | None | No |
A catch-all is the only one where no address is ever defined. Any local part at the domain — sales@, john@, qwerty@ — is accepted and delivered to the destination you named. That's its strength and its problem, in the same sentence.
What an External Catch-All Does
A catch-all destination can be a mailbox on the same domain, or an address somewhere else entirely — your main working address, a shared team inbox on your primary domain, or a helpdesk queue. The second case is the external catch-all.
An external catch-all is what makes this useful for domains you own but don't staff. There's nothing to provision on the parked domain at all. Add it, point MX at us, set the destination, done. Mail that would have bounced now arrives where somebody reads it.
Two guardrails apply, and both exist for good reasons.
A same-domain destination must be an active mailbox. Pointing a domain's catch-all at an address on that same domain which isn't a real mailbox would feed the delivery attempt straight back into the same catch-all rule — a loop that generates mail until something gives out. The rule is refused rather than accepted and left to fail later.
An external catch-all requires Pro or Agency. Routing to an outside address means we accept mail on your behalf and re-send it to a third party. That's a sending operation with reputational consequences, and it's gated to plans where sending is part of the deal.
Where an External Catch-All Is Exactly Right
Parked and defensive domains. acme-inc.com when you operate acme.com. There's no reason anyone should have a mailbox there, and every reason not to bounce mail that arrives.
A brand you acquired. Mail keeps arriving at the old company's addresses for years. An external catch-all sends all of it to whoever now owns that relationship, with no mailbox migration and no guessing which addresses were in use.
Domains that only send. A campaign or transactional domain sends but has no human recipients. It still needs to accept replies and bounces — silently discarding them means you never see out-of-office notices, complaints, or the customer who hit Reply.
Working out what an old domain actually receives. Route it to a folder for a month and read the log. Frequently the answer is "two real messages and a lot of noise", which tells you whether to build something properly or leave the catch-all running.
What an External Catch-All Costs You
An external catch-all accepts everything, which has consequences that show up on a delay.
Directory harvest attacks stop failing. Spam tooling probes domains with dictionary lists — info@, admin@, a@, ab@. A domain without a catch-all rejects the invalid ones at the SMTP conversation, cheaply. A catch-all accepts every single one, so a probe that should have cost you nothing costs you the full message.
Volume is unbounded and unpredictable. Once a domain running an external catch-all is known to accept everything, the address list circulates. This isn't a gradual trend; it tends to be quiet for months and then very loud.
Your domain becomes unverifiable. Anyone checking whether an address at your domain exists gets "yes" for every address, because you say yes to everything. This makes your domain look accept-all to verification services and pushes your addresses into their risky bucket — including the real ones. See what verification checks actually prove.
Typos get delivered silently. With no catch-all, mail to jhon@ bounces and the sender fixes it. With an external catch-all it lands in the sink and the sender assumes it reached John. Half the time nobody notices for weeks.
The general treatment of the trade-off is in how catch-all mail actually behaves. The short version: it's a good fit for a domain nobody works in, and a poor fit for one people do.
The External Catch-All Authentication Problem
An external catch-all is forwarding, and forwarding breaks SPF authentication. The message keeps its original sender but now arrives at the destination from our servers, which the original sender's SPF record never authorised.Sender Rewriting Scheme repairs the SPF half automatically by rewriting the envelope sender to a domain that does authorise us. It's applied without configuration. What it can't repair is a DKIM signature broken in transit, and it can't help if the original domain publishes p=reject and the receiving side is strict about it.
The practical consequence: routing an external catch-all into Gmail means some of it will land in spam, and the messages most likely to do so are the ones from domains with the strictest policies — which is to say the legitimate ones. Check the destination's spam folder for the first fortnight. Background in SRS and forwarded mail.
When Aliases Are the Better Answer
For a domain people actually work in, aliases beat an external catch-all on every axis.
Most organisations use fewer than ten real addresses: info@, sales@, support@, billing@, and a handful of names. Defining those explicitly means every other address is rejected at the SMTP conversation, which costs nothing, blocks harvesting, and lets a sender's typo bounce so they can correct it.
Aliases also do things a catch-all can't. You can send from an alias, so a reply to billing@ comes from billing@ rather than from your personal address. You can route different aliases to different mailboxes. And an alias delivers into a real mailbox, so it's searchable, filterable, and backed up.
The decision reduces to one question: does anyone work in this domain? If yes, aliases. If no, an external catch-all. See aliases versus mailboxes.
Setting Up an External Catch-All
- Add the domain and complete DNS so MX points at us. Without MX, none of this applies — mail still goes wherever it went before.
- Open the domain's Routing tab.
- Enable catch-all and enter the destination address.
- Save. It takes effect immediately, with no propagation delay on our side.
Then do the part people skip: send a test message to a nonsense address at the domain and confirm it arrives. It's the only way to know the rule is live rather than merely saved, and it takes thirty seconds.
If you route into an inbox you actually read, add a filter that files catch-all mail into its own folder. Otherwise the sink volume drowns the mailbox, which is how a sensible configuration gets turned off in irritation three weeks later. Server-side filters do this at delivery, before anything reaches your phone.
Frequently Asked Questions
Do I need a mailbox on the domain to use an external catch-all?
Not if the destination is external. That's the whole point for a parked domain — nothing is provisioned on it. If the destination is on the same domain, it must be an active mailbox, because otherwise the rule loops.
Does catch-all mail use my storage?
Routing to an external address uses none. Routing to one of your own mailboxes stores the mail there, against that mailbox's quota.
Can I reply from the catch-all address?
No. A catch-all defines no addresses, so there's nothing to send as. Replies come from whatever mailbox received the mail. If you need to send as a specific address, create an alias for it.
Why is the external catch-all restricted to Pro and Agency?
Routing to an outside address means we re-send mail on your behalf, which is a sending operation with reputational consequences. It's available on plans where sending is included.
Will external catch-all mail land in spam?
Some of it. Forwarding breaks the original SPF authorisation; SRS repairs that automatically, but a DKIM signature broken in transit can't be repaired by anyone. Check the destination's spam folder for the first couple of weeks.
How do I stop the flood once it starts?
Turn the catch-all off and define explicit aliases for the addresses that turned out to be real. Filter the sink into its own folder in the meantime so it stops competing with your inbox.
Can I configure an external catch-all over the API?
Yes — catch-all configuration is available through the REST API and to agents over MCP, which is the sane way to handle it across a portfolio of client domains.
