Utilizziamo i cookie per migliorare la tua esperienza. Continuando a visitare questo sito accetti il nostro utilizzo dei cookie.Informativa sulla Privacy
Set Up a Catch-All Email on Your Domain — EvilMail Blog
Setting Up a Catch-All Email on Your Own Domain (Step by Step)
A catch-all address turns your whole domain into an inbox: shop@, netflix@, and a thousand addresses you never created all land in one place. Here's how to set one up, and when you'll regret it.
EvilMail Team13 giugno 202611 min di lettura
# Setting Up a Catch-All Email on Your Own Domain (Step by Step)
The first time I set up a catch-all, it was because I got tired of inventing usernames. I owned a domain, I had a mail server, and I wanted [email protected] to just work without me creating a mailbox for each one. Ten minutes of DNS edits later, I was signing up for a hardware store loyalty card as [email protected] and a car forum as [email protected]. No accounts to provision, no aliases to pre-register. Every address I could dream up already existed.
That convenience is the whole pitch, and it's also the whole problem. A catch-all is a domain-wide wildcard: mail sent to *any* local part that doesn't match a real mailbox gets scooped into one designated inbox instead of bouncing. It's genuinely useful for tracking who leaked your address, and it's a magnet for the exact spam you were trying to trace. This guide walks through what it actually is, how to wire it up on real providers, and the specific moments where you'll wish you'd used plain aliases instead.
What a Catch-All Actually Does
Normally, a mail server knows a fixed list of valid recipients. Send to [email protected] when no sales mailbox exists and the receiving server answers with a 550 5.1.1 User unknown — a bounce. The sender's server gives up and generates a non-delivery report.
A catch-all rewrites that rule. Instead of "reject unknown recipients," the server's policy becomes "deliver unknown recipients to this fallback mailbox." So sales@, marketing@, jklfdsjfkl@, and admin@ all resolve to, say, [email protected]. The domain stops being a set of addresses and becomes a single open funnel.
Mechanically, three things are happening:
1.DNS points mail for your domain at a mail server via MX records. This part is identical whether or not you use a catch-all.
2.The receiving mail server decides, per-recipient, whether to accept or reject. The catch-all lives here — it's a routing rule, not a DNS setting.
3.A fallback mailbox actually stores the caught mail.
That distinction trips people up constantly. You cannot "set up a catch-all in DNS." DNS only says *which server* handles the mail. Whether that server accepts [email protected] is a decision made in the mail platform's admin panel. Keep those two layers separate in your head and the rest of this is straightforward.
The Trade-Off, Up Front
Before any setup, the honest cost-benefit, because half the tutorials skip it.
What you gain:
Infinite disposable-style addresses on a domain you control. Give every service a unique address without pre-creating anything.
Leak forensics. When [email protected] starts receiving casino spam, you know precisely who sold or lost your data.
Zero-friction signups. Never again stare at a signup form deciding what username to invent.
What you pay:
Spam amplification. Spammers run dictionary attacks: they blast info@, contact@, hello@, support@, sales@ at every domain they find. With a catch-all, *all* of those land in your inbox instead of bouncing. A quiet domain can start pulling dozens of junk messages a day.
Backscatter and reputation risk. If your server accepts everything and *then* forwards or filters, misconfiguration can turn you into a source of bounce spam, hurting your domain's sending reputation.
No natural boundary. With explicit aliases, an address that leaks can be deleted and the door closes. With a catch-all, the door is always open — deleting one address does nothing because the wildcard still accepts it.
The practical resolution most people land on: run a catch-all, but pair it with per-service addresses and be ready to blackhole individual local parts once they turn toxic. More on that below.
Step 1: Point Your Domain's Mail at a Server (MX Records)
MX (Mail Exchanger) records tell the world which server accepts mail for your domain. Even a flawless catch-all rule is invisible if your MX records point nowhere useful. In your DNS provider's zone editor, you're creating records like this:
dns
; Zone file excerpt for example.com
; Name TTL Class Type Priority Target
example.com. 3600 IN MX 10 mail.example.com.
example.com. 3600 IN MX 20 mail2.example.com.
; The MX targets need A records pointing at real IPs
mail.example.com. 3600 IN A 203.0.113.10
mail2.example.com. 3600 IN A 203.0.113.11
The priority number matters: lower is preferred. Sending servers try priority 10 first, and only fall back to 20 if the first is unreachable. Two rules that bite newcomers:
The MX target must be a hostname, not an IP address. MX 10 203.0.113.10 is invalid. Point the MX at a name, then give that name an A record. This is a hard requirement in the mail RFCs, not a preference.
The target hostname must resolve and must not be a CNAME. MX-to-CNAME is forbidden and many senders will reject it outright.
If you're using a hosted provider, they'll hand you exact MX values. Google Workspace, for example, uses a single smtp.google.com MX target these days; older setups list aspmx.l.google.com and friends. Use whatever the provider's current documentation says — do not copy MX records from a random blog, mine included, because they change.
Verify the records propagated before touching anything else:
Give DNS changes time. TTL of 3600 means up to an hour of caching; some resolvers ignore low TTLs and cache longer. Don't debug a catch-all in the first five minutes after editing DNS — you'll be chasing a propagation delay, not a config error.
Step 2: Enable the Catch-All on Your Provider
With mail flowing to your server, the catch-all rule itself gets configured in the mail platform. The concept is universal; the clicks vary. Here's how it looks across common setups.
Hosted email (cPanel / typical shared hosting):
Under *Email → Default Address* (sometimes labeled "Catch-All"), you'll find a per-domain setting with options like *Discard*, *Forward to*, or *Send to a specific mailbox*. Choose "send to" and enter your real mailbox. This is the single most common place people run a catch-all, and it's a two-click change.
Cloudflare Email Routing (free, forwarding only):
Cloudflare will provision the MX records for you when you enable Email Routing. Then under *Email → Email Routing → Routing rules*, toggle the Catch-all address on and set the action to *Send to* a verified destination mailbox. Note the limitation: Cloudflare *forwards*, it doesn't host mailboxes, and it can't send replies from those addresses without extra tooling. Great for read-only signup addresses, not for two-way correspondence.
Google Workspace:
Admin console → *Apps → Google Workspace → Gmail → Default routing*. Add a rule matching *All recipients* (or a pattern) that delivers to a chosen mailbox. Workspace is fussier here and deliberately steers you toward explicit users, so this is more of a routing rule than a friendly toggle.
Self-hosted Postfix:
The classic approach uses virtual_alias_maps. In a hash or PCRE map:
The bare @example.com with no local part is the wildcard: anything not matched above falls through to it. Run postmap /etc/postfix/virtual and reload. Order matters — put real aliases above the catch-all so they win.
Whatever the platform, the pattern is the same: a fallback rule that says "unmatched recipient → this mailbox."
Step 3: Use Per-Service Addresses to Catch Leaks
Here's where a catch-all earns its keep. Because every address already works, you can hand each service its own. The convention I use is simply the service name as the local part:
Now the address itself is a tracking pixel. If mail addressed to [email protected] shows up trying to sell you crypto, exactly one company had that address. You've caught the leak red-handed. No company can plausibly deny it — you never used that string anywhere else.
A few habits that make this reliable:
Set up server-side filters that file mail by the To:/delivered-to address into folders. Most clients and servers expose the original recipient; Gmail's Delivered-To header and Sieve's envelope test both work. This keeps the funnel organized instead of one giant pile.
Pick a naming scheme and stick to it.service@ is enough. Avoid guessable patterns *only* if you're worried about targeted abuse; for leak-tracking, obvious names are fine and easier to remember.
When one leaks, blackhole just that local part. This is the crucial move. You don't nuke the catch-all — you add one explicit rule above it that discards mail for the burned address:
With devnull routed to /dev/null (a discard transport), the leaked address goes dark while every other address keeps working. That's the discipline that keeps a catch-all sustainable: prune the poisoned addresses, keep the funnel.
When to Prefer Explicit Aliases Instead
A catch-all is not always the right tool. Reach for pre-registered aliases when:
The domain is your professional identity. If [email protected] is on your business cards, dictionary-attack spam hitting contact@, hello@, info@ will bury the mail that matters. A short list of real aliases plus a *rejecting* default (bounce unknown recipients) keeps the noise out.
You need to send, not just receive. Replying convincingly from netflix@ requires your outbound server to be authorized to send as that address, with SPF, DKIM, and DMARC aligned. Doable, but it's real work per address. Forwarding-only catch-alls (Cloudflare) can't do it at all.
Compliance or shared access. Team mailboxes like support@ want defined ownership and audit trails, not a wildcard that silently absorbs typos.
You're a spam target already. Some domains just attract dictionary attacks. If your catch-all inbox is 90% junk within a week, flip the default back to *reject* and maintain an allowlist of real addresses.
The hybrid most experienced users settle on: explicit aliases for anything important and outbound, and a *separate* throwaway domain running a catch-all purely for signups. That way the spam magnet and your real identity never share an inbox. If you'd rather not run infrastructure at all, a disposable-email service like EvilMail gives you the per-service, burn-on-leak behavior without owning a domain or babysitting DNS — the same isolation principle, hosted for you.
Testing and Common Failure Modes
Before you trust it, prove it. Send to a made-up address and confirm delivery:
bash
# Quick SMTP conversation to check a bogus recipient is accepted
swaks --to [email protected] --server mail.example.com
# Watch for '250' on RCPT TO — accepted (catch-all working)
# A '550 User unknown' means the catch-all is NOT active
The failures you'll actually hit:
"It bounces even though I set a catch-all." Almost always DNS: your MX records point at the wrong server, or you configured the catch-all on a platform that isn't the one your MX names. The rule and the MX target must be the same system.
"Everything works but I get no mail." Check the fallback mailbox exists and isn't itself full or filtered. Also check that a spam filter isn't quarantining the flood.
"Suddenly drowning in spam." Expected. That's the trade-off arriving on schedule. Start blackholing burned addresses, and consider whether the domain should reject unknowns instead.
"Replies from my alias get marked as spoofing." Your SPF/DKIM/DMARC don't authorize sending as that address. Fix alignment or accept that the catch-all is receive-only.
Set it up, hand out a unique address to the next five services you sign up for, and check back in a month to see which one sold you out. That single experiment teaches more about how your data actually moves than any privacy policy ever will.
