Myth: A Wildcard Catches Mail for Every Hosted Domain

Every few months someone posts the same frustrated question on a mail admin forum: “I set up a wildcard on my main domain, so why are messages to info@example.net bouncing?” The answer is almost always the same, and it surprises people who think of a wildcard as a blanket permission slip. A catch-all email address accepts every message sent to a domain, but only to that one domain. It does not turn your mail server into a sponge for every hostname in your DNS zone. If you run several domains on one box, each one needs its own fallback rule, or the server keeps doing exactly what it was told: rejecting mail for recipients that do not exist.

What a catch-all actually accepts, and what it does not

The confusion starts with the word “wildcard.” In DNS, a wildcard record like *.example.com covers every subdomain under example.com. People reasonably assume the same logic applies to mail, so they expect one setting to cover the whole hosting account. It does not work that way, because mail delivery is not resolved by DNS wildcards at the recipient level. MX records route inbound mail to a mail server, and that is where the decision about whether a recipient exists gets made. The MX record for example.net points at your server, and then your server decides what to do with the address it was handed.

Here is the part that trips people up. A standard mail server replies with 550 no such user when no mailbox matches the recipient address. That reply is generated per domain, by the software that holds the domain’s user list. On Postfix, recipient acceptance is scoped per virtual domain. Each domain in the virtual mailbox or virtual alias maps has its own set of valid addresses, and the catch-all setting is a property of that domain, not of the server as a whole. A catch-all on example.com will not catch typos on example.net even when both domains live on the same Postfix instance, unless example.net has its own fallback entry.

This is also why a catch-all email is configured on the mail server, not in DNS. You can add all the wildcard records you like to your zone file. Those records only help route traffic. They never tell Postfix, Exim, or Dovecot to accept an unknown local part. The acceptance decision happens after the SMTP connection is established and the recipient is presented, and it is evaluated against the domain that recipient belongs to.

Where the wildcard idea comes from

Two things feed the myth. First, hosting control panels sometimes use the phrase “catch-all” next to a domain selector, which makes it look like a global toggle. Second, people conflate SPF, DKIM, and DMARC with the whole mail flow. Those three govern outbound mail only. They tell receiving servers whether a message claiming to be from your domain is authorized. They have nothing to say about whether your own server should accept a message addressed to a made-up local part on a secondary domain. A clean DMARC record will not rescue a misconfigured fallback.

There is a real wildcard concept in mail, and it is worth naming so it stops causing trouble. Some systems call a catch-all a wildcard mailbox, meaning one mailbox that receives everything for a domain. That is a wildcard over local parts, not over domains. It is the difference between “any name at example.com” and “any name at any domain I happen to host.” Only the first one is something you can configure with a single rule.

How to set a fallback per domain on real servers

Once you accept that recipient acceptance is scoped per virtual domain, the fix is mechanical. You add a fallback for each domain that needs one. In Postfix, that means a catch-all entry in the virtual alias table, typically a line that maps @example.net to a real local mailbox. The leading @ is the syntax that says “anything at this domain that is not otherwise matched.” Repeat the line for every domain in your virtual domain list. If you skip a domain, that domain keeps returning 550 no such user for unknown recipients, which is the correct and safe default.

A working catch-all setup requires DNS pointing at the right host and a server accepting unknown recipients. Both halves must be true for the same domain. You can have the DNS side perfect and still get bounces because the server was never told to accept unknowns for that name. Exim handles this with a router that matches the domain and then a redirect or aliasfile lookup for the catch-all. Dovecot itself is mostly concerned with storing and serving mail over IMAP or POP3, so the acceptance logic usually lives in the MTA in front of it. Check where your stack makes that decision before you start editing config files.

Cloudflare and cPanel both expose catch-all settings, and both scope them to a single domain. In cPanel, you pick the domain from a dropdown and set the destination address. That dropdown is the tell: the setting belongs to one domain at a time. what a catch-all email address means provides further background on the subject. Cloudflare Email Routing lets you enable a catch-all for a zone, and a zone is one domain. If you have five domains on Cloudflare, you enable five catch-alls, or four of them keep rejecting unknown recipients. Neither tool is broken. They are reflecting how mail actually works.

A quick comparison of the options

When you need “any address at this domain” behavior, you have several mechanisms available, and they are not interchangeable. The table below lines up the common ones against what they actually do at the recipient level.

The distinction between a catch-all and the alternatives matters when you are debugging. Catch-all differs from alias, forwarding, and disposable addresses in that it accepts names that were never defined in advance. An alias only works for the exact address you wrote down. A forwarding rule needs a real address to forward from. A disposable address is created on demand, not by a server-side rule. If someone tells you to “just add an alias” when what you need is unknown-recipient acceptance, they are solving a different problem.

The trade-offs, and how catch-alls show up in verification

Catch-all domains are used for unlimited unpredictable addresses in automation and sign-ups, and that convenience has a cost. A catch-all carries the risk of accepting spam to invented addresses. Spammers guess local parts constantly, and a domain that accepts everything confirms to them that the domain is live and monitored. You will see dictionary attacks fill the fallback mailbox within days of turning it on. Many admins route the catch-all to a dedicated mailbox and filter it hard, rather than pointing it at a person’s primary inbox.

There is a second cost that surprises people in a different way: verification. Services that check whether an email address is real often test the domain for catch-all behavior. They send a message to a random, almost certainly nonexistent local part. If the server accepts it, the domain gets flagged as a catch-all domain, and the verification result comes back as “risky” or “unknown” instead of “valid.” This is not the verifier being difficult. It is the verifier correctly observing that your server accepts unknown recipient acceptance, which means it cannot confirm any single address is real. In email verification, a catch-all domain tells the checker that address-level certainty is impossible.

So the decision is not free in either direction. Turn the fallback on and you gain the ability to hand out any address you like, at the cost of spam volume and weaker verification signals. Leave it off and every typo and every guessed address gets a clean 550 no such user, which is honest but means a customer who mistypes your address simply disappears. Most teams end up with catch-alls on domains used for sign-ups and testing, and strict rejection on domains used for real correspondence.

Common setups that go wrong

The failure pattern is remarkably consistent. Someone configures a catch-all on their primary domain, tests it, and it works. They then add a second domain to the same server for a product launch, assume the wildcard covers it, and spend an afternoon wondering why test messages bounce. The server is behaving correctly. The second domain was never given a fallback, so it rejects unknowns.

• One catch-all set on the primary domain, with secondary domains left on strict rejection.
• A DNS wildcard record added under the assumption it controls mailbox acceptance.
• A catch-all configured in cPanel for one domain, with other domains on the same account untouched.
• SPF, DKIM, and DMARC records tightened up in the belief they affect inbound acceptance.
• A catch-all that points at a personal inbox and quietly fills with dictionary-attack spam.

Each of these looks like a bug and is actually a scoping issue. The fix is to audit every domain the server hosts, decide per domain whether unknown recipients should be accepted, and write the fallback rule for each one that should. On Postfix that is a line per domain in the virtual alias table. On Exim it is a router condition. In a control panel it is a dropdown selection repeated for each domain. AllMail.one publishes a guide to catch-all email that walks through the per-domain model, which is a useful reference when you are reconciling what a panel shows with what the MTA is actually doing.

Before you touch anything, list the domains, check the MX records for each, and confirm which host receives mail for each name. Then verify the fallback by sending to a random local part on every domain in the list, not just the one you remember configuring. If a domain bounces with 550 no such user, it has no catch-all, and no amount of DNS editing will change that. Add the per-domain rule, retest, and route the fallback mailbox somewhere you can filter it. The wildcard you were looking for was never a single switch. It is one rule per domain, and once you set them that way, the mystery bounces stop.

Categorised in: Post

This post was written by justyoga_f60tk1