How to test a catch-all or wildcard email address
A catch-all address is easy to switch on and easy to get wrong. When it works, every address under your domain reaches a mailbox. When it fails, it usually fails silently — the sending server reports success, and the message simply never appears.
The only reliable way to know is to send mail to an address that has never existed and watch what happens. You can do that in a few seconds with a free email receive test.
Catch-all, alias, and plus addressing are not the same thing
These get used interchangeably, which is why people test the wrong thing.
- Catch-all (wildcard): accepts mail for any local part at your domain, including addresses that were never created as mailboxes.
- Alias: a specific extra address that routes to an existing mailbox. Each one has to be created by hand.
- Plus addressing (subaddressing): tags on an existing mailbox, such as
[email protected]. It works only for a mailbox that already exists.
Only a catch-all accepts an address nobody configured. That distinction defines the test.
How to test a catch-all address properly
1. Choose an address that cannot already exist
Use a random string, not a plausible one — something like [email protected]. Avoid test@, info@, or hello@, which are often real mailboxes or existing aliases on domains that have been in use for a while.
2. Send the test message
Go to SendTestMail.com, enter the random address, and complete the CAPTCHA. No account or configuration is needed.
3. Watch the delivery status
Open the delivery status page and note whether the message is reported as sent, delivered, bounced, or pending. This tells you what the receiving server did at the SMTP level, which is the part you cannot see from your inbox.
4. Check the destination mailbox
Look in the mailbox your catch-all is supposed to route to — including Spam, Junk, quarantine, and any folder a rule might have moved it to.
5. Repeat with two or three more random addresses
A single test can pass by coincidence. Consistent results across several unrelated addresses are what confirm the rule is genuinely active.
Do not test with an address that already works. Sending to your real mailbox proves the mailbox receives mail. It proves nothing about whether the catch-all rule exists.
What each result means for a catch-all
Delivered, and the message arrives
The catch-all is working. Mail for unrecognised addresses is being accepted and routed to a real mailbox.
Delivered, but nothing arrives
This is the most common and most confusing outcome. The receiving server accepted the message at SMTP and then discarded it afterwards.
Check Spam and quarantine first. If it is genuinely gone, look at the action on your catch-all rule. Several control panels offer "discard" or "drop" alongside "forward," and discard is sometimes the default. The server accepts the mail to avoid bouncing, then throws it away.
Bounced with "user unknown" or a 550 error
No catch-all is active. Either the rule was never enabled, it was not saved, or it applies to a different domain than the one you tested.
Bounced with "relay access denied" or "not our domain"
The receiving server does not consider itself responsible for your domain. Usually the domain was never fully added to the mail provider, or MX records point somewhere else entirely.
Pending or deferred
Often greylisting or a rate limit rather than a real failure. Wait a few minutes and refresh the status before concluding anything.
No status change at all
Worth checking whether your MX records resolve to the server you think they do.
Check MX records when the test bounces
MX records tell sending servers which machine handles mail for your domain. A catch-all rule cannot help if mail never arrives at the server holding that rule.
Common causes of a bounce here:
- MX records from a previous provider were never removed
- Records were edited at the registrar while a different DNS host is actually authoritative for the domain
- The change was made recently and has not propagated
- Two providers' MX records coexist, so mail splits unpredictably between them
- The domain expired
Do not change DNS records unless you control the domain and understand the current configuration. A wrong MX edit stops all mail, not just catch-all mail.
Where the catch-all setting lives
The wording differs by platform, which is a frequent source of half-finished configurations.
- cPanel and Plesk: listed as the Default Address for the domain. Set it to forward to a real mailbox — the alternative option silently discards.
- Google Workspace: not enabled by default. It is configured in the Admin console under Gmail's routing settings, as a default routing rule that matches unrecognised addresses and redirects them to a chosen mailbox.
- Microsoft 365: has no native catch-all. The documented workaround involves setting the accepted domain to internal relay alongside a mail flow rule, which is easy to configure halfway and leaves mail being accepted then dropped.
- Cloudflare Email Routing: offers an explicit catch-all with a selectable action. One of those actions is drop, which discards mail without any error.
- Zoho, Fastmail, Migadu and similar: usually found under domain or routing settings, sometimes labelled "catch-all mailbox".
After changing any of these, run a fresh test. Many platforms apply routing changes only to messages received after the change.
Why a working catch-all can still lose mail
Even correctly configured, catch-all addresses have failure modes worth knowing about:
- Harsher spam filtering. Addresses with no sending or receiving history attract more aggressive filtering than established mailboxes.
- Directory harvest attacks. Because your domain accepts everything, spammers who guess addresses get no rejection and learn nothing is invalid. Volume tends to climb over time.
- Backscatter. Accepting all mail means you cannot reject bad recipients at SMTP time, so problems surface later as bounces or filtering rather than clean refusals.
- Storage pressure. A catch-all inbox can fill quickly, and a full mailbox rejects new mail.
- Provider limits. Some hosts cap or throttle catch-all volume.
Should you keep a catch-all switched on?
Reasonable arguments both ways.
Keep it if you cannot afford to lose mail sent to a mistyped address, you want a distinct address per service without creating each one, or you are mid-migration and need a safety net.
Turn it off if spam volume is climbing, you need to know which addresses on your domain are real, or your provider limits it.
A common middle ground: create explicit aliases for addresses you actually use, rely on plus addressing for signups, and enable the catch-all only temporarily during a migration.
Re-test after every change
Run a quick check whenever you change mail providers, edit MX records, add or remove a domain, change the catch-all destination, or migrate a mailbox. A catch-all that worked last year is not evidence that it works today.
Frequently asked questions
How do I know whether my domain has a catch-all?
Send a test message to a random address at your domain that was never created. If it is delivered and arrives in a mailbox, a catch-all is active. If it bounces with "user unknown," it is not.
Why does my catch-all show delivered but nothing arrives?
The receiving server accepted the message and then discarded it. Check Spam and quarantine, then check whether your catch-all rule is set to forward to a mailbox rather than to discard.
Does a catch-all cover subdomains?
Generally no. Mail for mail.example.com is routed by that subdomain's own MX records, not the parent domain's. Subdomains need their own configuration.
Will a catch-all hurt the deliverability of mail I send?
Receiving configuration and sending reputation are separate. The indirect risk is volume: a catch-all collects far more spam, and a busy or full mailbox creates problems of its own.
Can I test this without setting up a catch-all first?
Yes — that is the useful case. Testing a random address on a domain without a catch-all should produce a bounce. Confirming that bounce tells you the domain is rejecting unknown recipients correctly.
Does SendTestMail store the addresses I test?
No. Addresses and IP addresses are hashed before processing and inbox content is never read or retained. You can read more in the privacy policy.
Not sure whether your catch-all is actually catching anything? Send a free test email to a random address on your domain and check the delivery status.