A client calls because their "info@" inbox has become unusable, except once you look closer, half of what's in there was never sent to info@ at all. It's addressed to jsmith47@, sales2@, accounts-payable@, local parts nobody at the business ever created, landing in the same place because whoever set the domain up added a catch-all address and never touched the setting again. Whether that domain sits on Atriomail today or on the host you're about to move it away from, an unmonitored catch-all behaves the same way everywhere: it turns every guess a spammer or a bot makes into mail your client has to wade through.

This post covers the fix: confirming what's causing the flood, changing how the mail server answers a request for an address that doesn't exist, rebuilding the short list of addresses the business genuinely uses, and verifying the change took. None of the general steps need Atriomail specifically, but the last section covers how the same problem plays out once a domain is on Atriomail, where a catch-all can only ever point at a mailbox that already exists.

Table of Contents

Key Takeaways

Point Details
An open catch-all is a standing target, not a convenience Automated tools probe domains with dictionary-style and random addresses around the clock. If there's no address list to reject against, every one of those guesses gets accepted somewhere.
Accepting bad mail and bouncing it afterward creates backscatter When the sender's address was forged, the bounce your server generates lands on an innocent third party, not the spammer, and can get the domain flagged as a source of spam it never actually sent.
Rejecting during the SMTP conversation is the fix, not a silent discard A permanent rejection at the point the sender names the recipient tells the sending server immediately and generates no bounce of its own. Silently discarding still risks losing a real, misspelled message with no record anywhere.
Atriomail's catch-all rule removes the open-ended version entirely A domain's catch-all can only point at a mailbox that already exists on that same domain, and mail arriving through it is filtered for spam like any other mailbox.

A catch-all with no wall keeps every guess it's shown. On Atriomail, a domain's catch-all has to point at a mailbox that already exists on that domain, so there's no unrestricted address left for a harvest attempt to land in.

Create your account   See pricing

Before You Start

  • Admin access to the domain's mail server or hosting control panel (cPanel, Plesk, or whatever manages that domain's mail), since you'll be changing how it treats nonexistent recipients, not just reading a setting.
  • A day or two of mail logs from the catch-all mailbox, so you're diagnosing an actual pattern instead of one bad afternoon.
  • The list of every address the business genuinely uses, gathered from whoever runs sales, support and billing, not guessed from memory. This becomes the alias list that replaces the catch-all.
  • A way to test the change safely: a scratch mailbox on the domain, and a made-up address to send from outside once the new setting is live.

Confirm the Catch-All Is Actually the Problem

Before changing anything, open whatever mail log the catch-all mailbox draws from, Exim's mainlog on a typical cPanel server, Postfix's mail log elsewhere, or Plesk's own Mail Log Viewer, and look at who the flood is actually addressed to, not just how much of it there is. A domain being directly harvested shows a specific fingerprint: a long run of short, dictionary-style local parts (admin, sales1, jsmith, info2) arriving from many different sending IPs over a short window, because automated tools are working through common name and role-address guesses looking for anything that answers (spamauditor.org, "Silent Reputation Killer: Email Backscatter on cPanel," checked September 2026).

A second, easily confused pattern looks different: instead of fresh spam, the catch-all fills with bounce and "Mail Delivery Subsystem" notifications addressed to made-up local parts. That's backscatter: somewhere else, a spammer forged this domain as the "From" address on mail sent to a third party, that server couldn't deliver it, and it bounced the failure back to the forged sender, which lands in this domain's catch-all because the local part was never a real mailbox (spamauditor.org, checked September 2026). Both patterns get fixed by the same setting change, covered next, but knowing which one is happening tells the client's team what they're actually dealing with.

For a reseller who owns the support process for a whole book of client domains, this same log check is worth running whenever one domain's ticket volume spikes for no obvious reason, especially across a multi-client email setup where one leaky catch-all can quietly account for most of a week's noise.

The pattern in the logs tells you which problem you actually have. A flood of dictionary-style local parts means the domain is being harvested directly; a flood of bounce messages means someone else is forging it as a sender elsewhere. Both stop at the same setting.

Create your account   Talk to the team

Stop Accepting Mail for Addresses That Don't Exist

The internet's own mail specification already takes a position on this. RFC 5321 says that if a message "cannot be delivered, and cannot be rejected by the SMTP server during the SMTP transaction," it should be bounced with a non-delivery notification (RFC 5321, Section 6.2, rfc-editor.org, checked September 2026). The same section says silently dropping a message instead should be "considered only in those cases where there is very high confidence that the messages are seriously fraudulent or otherwise inappropriate." That's the whole problem with an open catch-all: it can't reject anything during the SMTP transaction, because by definition it accepts every address, so the only options left are to accept-then-bounce, which causes the backscatter above, or silently drop everything, which the specification treats as a risky default rather than a routine one.

The actual fix rejects during the SMTP transaction itself, before the message is ever accepted. On a typical cPanel or Exim setup this is the difference between the default-address options: a "fail" response issues a permanent rejection at the point the sending server names the recipient, so the server "refuses to take 'ownership' of the email" and never generates a bounce of its own (spamauditor.org, checked September 2026); a silent "blackhole" accepts the message and discards it without telling the sender anything, exactly what RFC 5321 warns against defaulting to; and the catch-all option forwards everything to one mailbox regardless of whether the address is real. On Plesk, the equivalent setting sits under a domain's mail settings as "What to do with mail for non-existent users," where "Reject" is the documented default and a properly behaving sender gets an immediate "Recipient address rejected: User unknown in virtual mailbox table" notice back (Plesk Obsidian documentation, docs.plesk.com, checked September 2026). Whichever panel is in front of you, the setting to reach for has the same shape: a rejection during the SMTP conversation, not a mailbox that accepts everything, and not a silent discard either.

This sits alongside the wider set of essential security protocols worth checking on any client domain, not just the ones already generating tickets.

Rebuild the Address List the Business Actually Uses

Rejecting unknown addresses only works cleanly once the domain has every address the business uses set up as something real: a mailbox, or an alias or forwarder pointed at one. Work through the list gathered in the prerequisites above and cover the obvious categories: role addresses (info@, sales@, support@, billing@), every current staff member's name in whatever format clients use for it, and anything printed on a business card, an invoice template or a signature block someone still uses. A forwarder hands mail on to an outside address like Gmail if that's genuinely where someone reads it; an alias just gives one mailbox a second name. Neither carries its own charge, and both can be added as soon as the domain already has at least one mailbox on it, the same rule an alias, forwarder or catch-all follows everywhere it's implemented, not only on Atriomail. Getting this list right before flipping the reject setting matters more than the setting itself: domain management done properly means nobody discovers a missing address by way of a client complaint after the fact.

Watching for the Pattern Coming Back

A cleanup like this isn't a one-time fix and forget. Domains get harvested again after any period of public exposure, a new signup form, a conference sponsor list, a breach involving a client the business dealt with, and the address list needs periodic review as staff change. Build a quarterly check into whatever review already covers a client domain's security essentials: sample recent rejected-recipient log lines, confirm the reject reason is still an address that genuinely doesn't exist rather than a typo in a real one, and add anything new to the alias list before it turns into a ticket.

How to Verify It Worked

Two checks confirm the change took. First, send a test message from an address outside the domain to something made up, a random string at the domain, and confirm it bounces back immediately with a permanent failure, not a delay and not silence. The bounce should reference the domain's own mail server rejecting the recipient, not a generic failure from an unrelated outbound service. Second, watch the mail log for the following 24 to 48 hours: rejected-recipient lines should show up immediately, instead of messages being accepted into what used to be the catch-all mailbox. A harvest attempt that's genuinely blocked shows up as a burst of quick rejections, not silence, since the sending servers are still trying, they're just failing immediately now.

Atriomail's free DNS checker at /dns-checker/ is worth running on the same domain, though it's a complementary check, not a substitute for the two above: it reads a domain's public MX, SPF, DKIM and DMARC records and flags anything malformed, which matters for the backscatter half of this problem since a domain with clean records is a less convincing sender for someone to forge, but it doesn't check how the domain's own server answers a request for a nonexistent recipient, since that's a mail server setting, not a DNS record. Pair it with a broader look at automated DNS validation for the domain while the mail flow is already under review.

Common Mistakes and How to Avoid Them

  • Switching straight to a silent discard instead of a rejection. Symptom: a client's own customer swears they emailed and got no bounce, because the message really did vanish with no notice, exactly what RFC 5321 warns against as a default.
  • Flipping the reject setting on before the real address list is rebuilt. Symptom: info@ or a staff member's address starts bouncing the moment the change goes live, because nobody had added it as an actual mailbox or alias first.
  • Forgetting a third-party tool that was quietly relying on the catch-all. Symptom: a CRM or invoicing tool's confirmation messages start bouncing, because it was sending to an address slightly different from the one someone meant to configure.
  • Rejecting with a temporary error instead of a permanent one. Symptom: the same message keeps reappearing in the log for days, because a temporary response tells the sender to retry later instead of stopping.
  • Expecting the flood to stop the moment the setting changes. Symptom: rejected-recipient traffic keeps arriving for days, because queued retries already mid-attempt haven't yet noticed the domain stopped answering.
  • Not confirming who's behind an address before cutting it off. Symptom: a former employee's replies to a still-active client thread bounce, because nobody checked whether that address needed a forwarder first.

These same mistakes multiply across a reseller's book: easy to get right on one domain, easy to rush across forty, especially when bringing on a client book of domains at once. Treat the rebuild as part of the same checklist as the rest of a domain's managed email security practices, not a one-off fix for the client who complained.

Doing This on Atriomail

Atriomail avoids the open-ended version of this problem structurally, not as an afterthought. Aliases, forwarders and catch-all addresses can be added to a domain once that domain already has at least one mailbox on it, and a catch-all always points at one specific mailbox rather than an unrestricted "accept anything" address. There's no equivalent of a bare silent discard or a wide-open default address to lock down later, because the option to create one doesn't exist in the first place: the mailbox a catch-all points to has to be real, and mail arriving through it is filtered for spam the same way any other mailbox's incoming mail is.

Once the destination mailbox exists, adding info@, sales@ or a staff member's name as an alias, or a forwarder to wherever someone actually reads mail, is a small step for each address, and none of it is billed: domains, aliases, forwarders and catch-alls carry no charge on top of the mailboxes already on the domain, covered on the pricing page. The control panel's own walkthrough of setting up catch-alls, aliases and forwarders covers the exact screens for each.

If the domain is moving off an old host's wide-open catch-all onto Atriomail at the same time, the built-in IMAP migration tool copies mail out of whichever real mailboxes exist today, folders and dates intact, using that mailbox's own IMAP password; it doesn't touch calendars or contacts, and dozens of accounts from one old server are worth planning with the team first. What it can't do is inherit the old catch-all's bad habit: whatever gets migrated is exactly what was sitting in a real mailbox. Create your account, add the domain, and set up the mailbox each real address needs before turning anything else off.

A catch-all here can only point at a real, spam-filtered mailbox. There's no wide-open default address to misconfigure in the first place, and aliases, forwarders and catch-alls cost nothing beyond the mailboxes already on the domain.

Create your account   See pricing

Frequently Asked Questions

What's the difference between a catch-all address and a regular mailbox?

A catch-all isn't its own mailbox: it's an instruction that says anything addressed to the domain that doesn't match an existing mailbox, alias or forwarder should be delivered anyway. A regular mailbox only receives mail addressed to it specifically. That's exactly why an open catch-all becomes a magnet: it's the one address on the domain willing to accept literally anything.

Won't rejecting unknown addresses mean the business misses real misdirected mail, like a typo in a client's name?

Only if the real address list isn't rebuilt first. Once every address the business uses, including obvious variations like a staff member's first name and first-initial-last-name, is set up as a mailbox or alias, a genuine typo still gets delivered. It's only mail to addresses nobody ever created that starts bouncing, which is exactly the mail nobody wanted anyway.

How do I know if the flood is a direct harvest attack or backscatter from a forged sender?

Look at what the messages actually are, not just the volume. Fresh spam-looking mail addressed to lots of different made-up local parts is a direct harvest attempt. A flood of bounce or "Mail Delivery Subsystem" notices addressed to made-up local parts means someone else is forging the domain as a sender elsewhere, and those bounces are boomeranging back. Both stop once unknown addresses are rejected instead of accepted.

Can I set up a catch-all address on Atriomail?

Yes. A catch-all can be added to a domain once that domain already has at least one mailbox, and it has to point at a real mailbox on that same domain rather than an open-ended address. Catch-alls, aliases, forwarders and domains themselves aren't billed.

Does Atriomail filter spam that comes through a catch-all mailbox?

Yes, incoming mail is filtered for spam the same way it is for any other mailbox on the domain. That's on top of the structural fix: because a catch-all has to resolve to a real mailbox rather than accepting every address unconditionally, there's no open door for a harvest attempt to walk through in the first place.

If I'm moving a domain off an old host's wide-open catch-all, will Atriomail's migration bring over the mail that's already piled up in it?

The built-in IMAP migration tool copies mail out of whatever real mailboxes exist on the old server, using that mailbox's own IMAP password, folders and dates intact. It doesn't reach into an old catch-all's junk pile, since that was never a real mailbox with its own credentials to sign in to. Moving dozens of accounts from one old server is worth planning with the team first rather than queuing them all at once.

Latest from the blog