Catch-all email addresses: why “accepted” is not “verified”

What a catch-all domain actually is

A catch-all, sometimes called accept-all, is a mail-server setting. The domain accepts messages addressed to any local part—jane@, j.doe@, or a typo—instead of rejecting unknown recipients. MillionVerifier describes it as a server set to accept all mail even when the address does not exist, and classifies catch-all results as risky. [1][2]

Organizations have ordinary reasons for the setting. Mail for a departed employee or a renamed mailbox can be routed to a shared inbox rather than lost; MillionVerifier notes that mail for a nonexistent address on such a server may be forwarded to a generic mailbox. None of those reasons means the named prospect you intended to reach will ever see your message. [1]

Why verification cannot see past the server

Address verifiers generally ask the receiving server, without delivering a message, whether it would accept mail for a recipient. A server that rejects unknown recipients gives a useful answer. A catch-all server answers yes for every address, so the check learns the domain’s policy, not whether the person exists.

What happens after acceptance varies. The message may reach the intended inbox, a shared mailbox, or a quarantine; it may be discarded; or the server may generate a bounce later. MillionVerifier notes that some catch-all servers do send a bounce when mail reaches a nonexistent address. A late bounce still lands in your bounce rate, and a silent drop gives you no signal at all. [1]

Keep the verifier’s answers separate

Flattening every result into “verified” or “not verified” is where many lists go wrong. A catch-all result tells you the domain is real and accepting mail; it says nothing about whether the role, the person, or the address pattern is right. MillionVerifier groups catch-all and unknown together as risky and does not charge for either. [2]

Sources [2]

The risk arrives in clusters

Catch-all status belongs to a domain, not a person, so every address at that company gets the same answer. A campaign that targets several people per account can concentrate its uncertainty in a few domains and a few send days. Early in a ramp, when daily volume is small, a handful of late bounces moves the rate quickly.

Guessed addresses make it worse. On a catch-all domain, a pattern guess such as first.last and a real address look identical to a verifier. Sending several guesses to see which one survives transfers the uncertainty to the recipient’s systems and to your sender reputation.

Automatic stops help, but they are a backstop rather than a plan. By default, Actually Agentic pauses sending at three hard bounces, or at a 2% hard-bounce rate once at least 20 messages have been submitted, so a cluster of bad catch-all addresses would halt a campaign instead of quietly eroding it. Its terms are explicit that such gates reduce risk without eliminating it. [3]

A practical rule for catch-all addresses

MillionVerifier’s own guidance is narrower still. It says catch-all addresses can be used only if they belong to real subscribers who signed up recently—not purchased lists or addresses collected from the internet. Cold B2B outreach falls outside that description by definition, which is a strong argument for the conservative default. [1]

• Default: exclude catch-all and unknown results from cold outreach.
• Exception: include a catch-all address only when first-party evidence names that person in the target role. An address printed on the company’s own team, contact, or press page is stronger than any pattern guess.
• Cap it: keep catch-all addresses to a small, fixed share of each day’s sends and never let one domain dominate a day.
• Sequence it: send to valid addresses first so each mailbox has a clean bounce baseline before any catch-all message leaves.
• Watch it: track hard bounces for catch-all sends separately and withdraw the exception at the first sign of trouble.
• Record it: note who approved the exception and why, so the decision can be reviewed later.

How Actually Agentic handles catch-all results

Actually Agentic keeps valid, catch-all, invalid, unknown, disposable, and suppressed outcomes distinct. Catch-all addresses are excluded unless the customer’s reviewed plan expressly allows them, and the discovery prompt tells the customer’s agent to accept only “valid” unless the customer explicitly accepts catch-all risk. [4][5]

There is also a spending guard. A campaign cannot trigger a domain purchase until payment is committed and at least one business address returns valid; catch-all results alone are not enough. The product is prelaunch, and none of this guarantees delivery. It keeps uncertain addresses from being counted as confirmed ones. [4]