A catch-all address is the setting that makes every possible address at your domain work at once. You do not create them, you do not register them, they simply resolve. Mail to hello@, to accounts@, to a string you invented at a checkout page two years ago and never wrote down, all of it arrives in the same place.
That is a genuinely useful thing to own, and it is also the setting people switch off again a few months later, usually in a hurry. The reason is not complicated. A catch-all cannot say no. Saying yes is its entire function, so the moment a machine starts guessing names at your domain, every guess is a real address.
Both facts are true at once, so the interesting question is not whether a catch-all is good or bad. It is what you put around it. This guide covers what one actually does at the protocol level, why it attracts the traffic it does, the tamer patterns that get most of the benefit for a fraction of the noise, and how the approach compares with creating addresses one at a time.
What a catch-all address is
When a message arrives, the sending server names the recipient before any content is transferred. The receiving server takes the local part, the piece before the @, and checks it against the addresses it knows: mailboxes, aliases, groups, forwarding entries. If nothing matches, the normal answer is a refusal. RFC 5321 describes the 550 reply for a recipient the server knows it cannot deliver to, and the sending server turns that into a bounce.
A catch-all replaces that refusal with a destination. Any local part that does not match something explicit is delivered to one nominated mailbox instead. Providers name it differently: cPanel calls it the default address, Google Workspace exposes it as a routing rule covering unrecognised accounts, others just say wildcard. The ordering matters more than the name. A catch-all sits underneath your explicit addresses rather than replacing them, so real mailboxes still receive their own mail and the wildcard only handles the leftovers.
One side effect is worth naming early. From outside, a catch-all domain answers yes to every recipient probe, so nobody can work out which of your addresses are real. That is a genuine benefit, and it is also the mechanism behind the problem two sections down.
The genius part: inventing an address on the spot
The workflow that makes a catch-all worth the trouble is this. You are on a sign-up form. In the email field you type something you have never used before, named after whoever is asking: hardware-shop@yourdomain, or council-tax@yourdomain. You do not open an admin panel and you do not wait for anything to propagate. The address works because all of them do.
Two things follow. The first is attribution: when junk starts arriving at hardware-shop@, you do not have to guess which of forty companies leaked, sold or lost your details, because the address is the receipt. The second is revocation: that one address can be shut off without touching anything else, which is the difference between a five second fix and changing your address everywhere.
Plus-addressing gets you part of the way for free. Adding a detail part to an existing address, as in name+shop@example.com, is a widely supported convention rather than a standard. RFC 5233 defines a Sieve filtering extension for matching that detail part, and its abstract opens by saying it applies on email systems that allow for subaddressing: it presupposes the convention and leaves the separator to each system. The catch is visibility. The base address is sitting right there, and stripping the plus and everything after it takes one line of code. Some sign-up forms refuse the plus sign outright. An invented catch-all address has no visible base to strip.
The spam-magnet problem, and why dictionary attacks target catch-alls
A dictionary attack, sometimes called a directory harvest attack, is a machine working through a list of likely local parts at your domain: info, sales, admin, hello, common first names, an initial plus a surname. Against an ordinary domain that is reconnaissance. Most probes are refused, the few that are accepted tell the attacker which addresses exist, and nothing is delivered. Against a catch-all it stops being reconnaissance and becomes delivery. Every name on the list is accepted, so the attack learns nothing and succeeds anyway.
Microsoft documents the opposite posture for Exchange Online, where Directory-Based Edge Blocking rejects mail for addresses that do not exist at the service perimeter, before spam and malware filtering runs at all. That efficiency is what a catch-all gives up by design. Everything reaches your filters, and everything your filters let through reaches you.
Your domain does not need to leak for this to start. Domains are enumerated from web pages, certificate logs, registration records and lists of previously registered names, so a domain with a past owner may already be on somebody's list. A second stream arrives when a spammer forges your domain as the sender of a campaign: bounces and out of office replies come back to addresses that never existed, and a catch-all accepts all of them. SPF, DKIM and DMARC records reduce the forgery. They do not stop return traffic that is already in flight.
One configuration mistake is worth calling out. If you accept everything and then silently discard what you do not like, somebody who mistypes your address gets no bounce and their message is simply gone. Catching typos is why many people wanted a catch-all in the first place, so that setup manages to lose both the spam fight and the original purpose.
Block rules and forward rules as the tame version
The choice is not between a wildcard that takes everything and creating each address by hand. Most of the value sits in the middle, in a handful of rules that narrow what the wildcard will accept.
- Accept only addresses matching a pattern. If every address you invent carries a prefix, then info@, sales@ and the rest of the dictionary never match and are refused as normal.
- Put the catch-all on a subdomain. Keep the main domain strict and let the wildcard live somewhere contained, away from the addresses you print on invoices.
- Reject burned addresses individually. Once one invented address is drowning, refuse it at connection time rather than filtering it after delivery. Nothing else you own is affected.
- Send catch-all mail somewhere other than your main inbox. A separate mailbox you review on a schedule keeps the noise out of the place you actually work.
- Promote the keepers. When an invented address turns out to matter, create it explicitly so it has its own rules and stops depending on the wildcard.
- Refuse rather than accept and delete. A sender who is told is a sender who can correct the address.
Pattern matching is not universal, and where it exists the syntax varies. Check what your provider supports before you design a naming scheme that depends on it.
Catch-all versus explicit aliases, and when each is right
A catch-all wins on friction. There is nothing to create and nothing to wait for, and it works when you are standing in a shop with no access to an admin tool. It catches typos, which is worth real money if you invoice people, and it makes address enumeration pointless. What it costs you is an unbounded surface: you cannot control an address until after somebody has used it, and attribution only works if you are disciplined about naming.
Explicit aliases win on control. Every address is something you deliberately made, with its own destination, its own notes and its own off switch, and anything you did not create is refused outright, so guesses cost you nothing. The price is friction at exactly the wrong moment, halfway through a sign-up form, plus a dependency on being able to reach the tool that creates them.
As a rough rule, a catch-all suits a young domain that has never been published, with one person behind it and a high rate of sign-ups, or a business where a mistyped address must not vanish. Explicit aliases suit a domain that is old, printed on a website, shared by a team, or previously owned by somebody else. Plenty of people run both: explicit addresses for anything that matters, a wildcard on a subdomain for the disposable end.
What a catch-all will not fix
It does not make you anonymous. Every address you invent still ends in your domain, and a domain you own is a strong identifier. It usually points at one person, its registration is dated, and any two companies comparing notes can see that hardware-shop@ and council-tax@ are the same household. A catch-all separates your relationships from each other. It does not separate them from you.
It does not stop a leak either. It shows you one after it has happened. And it encrypts nothing: the addressing is the whole of it.
The renewal risk deserves more attention than it gets. Every address depends on you keeping the domain registered. If it lapses, whoever registers it next receives mail for every address you ever invented, password resets included. Owning the domain is what gives you control, and it is also what makes you the single point of failure.
There are cases where none of this is the right answer. If all you want is to know who sold your address, plus-addressing on the free mailbox you already have does that at no cost, as long as the site accepts a plus sign. Several providers offer masked address services with free entry points, and the limits on those change often enough that it is worth reading their current pricing page rather than an article. And if you sign up for three services a year, a catch-all is machinery you will maintain for nothing.
What you need to set one up
The requirements are short, and none of them are optional.
- A domain you control, with access to its DNS. There is no catch-all without one, because the setting applies to a whole domain rather than to an address.
- MX records pointing at a provider that supports a default or wildcard route. The names differ, so search their documentation for default address, catch-all, or unrecognised recipients.
- A destination that is not your main inbox: a dedicated mailbox, or a folder with a filter in front of it.
- SPF, DKIM and DMARC records published for the domain even if you never send from it, because they make your domain harder to forge and cut the bounce traffic a catch-all would otherwise absorb.
- A way to refuse a single address once it turns bad, and knowledge of where that setting lives before you need it in a hurry.
- A naming convention decided in advance. One address per relationship, named after the relationship, never reused. The scheme is what turns a wildcard into evidence.
Then test it twice. Send a message to a random string at your domain and confirm it lands where you expect. Then take one address out of the catch-all, refuse it, and confirm the sender gets a bounce rather than silence. If both work, switch it on and watch that mailbox for a month before deciding whether the trade suits you. That is a cheaper way to find out than reading anybody's opinion, including this one.