Catch-all email: what it means, and what to do with those addresses on your list

Your verifier returned the list and a chunk of it came back tagged catch-all, or accept-all, or risky, depending on whose tool you used. The send is scheduled. You have to decide what to do with those records today.

Here is the position you are actually in. Those addresses were not judged and found wanting. They were not judged at all, because the domain they sit on will accept anything.

What a catch-all domain does

A catch-all is a server setting. The domain accepts mail addressed to any recipient, including recipients who do not exist, and delivers it somewhere: a designated mailbox, a group, or a queue somebody reviews.

Administrators turn it on for reasons that make sense from their side. Google Workspace documents it as a way to get misaddressed mail sent to non-existent or incorrect addresses on the domain, so a typo in a customer's message still reaches someone. Zoho presents it as a defence, on the grounds that a server which accepts everything gives a harvester no way to work out which addresses are real.

Not every provider is enthusiastic. cPanel's own documentation warns that a catch-all account may receive a large amount of spam, which is the direct consequence of the same behaviour. Google's own catch-all setup page carries no such warning. Microsoft has no current first-party documentation on catch-all at all; the only Microsoft page that surfaced covers a version of Exchange that has been discontinued.

Same mechanism, opposite framing, both published by the companies that operate the mail. That inconsistency is worth knowing before you read a vendor's opinion about it.

Why your verifier cannot answer the question

Email verification works by starting a conversation with the receiving server and stopping before the message is sent. The verifier names a recipient with the RCPT TO command, and the server says whether it will accept mail for that recipient.

SMTP does have a command designed for asking whether an address exists, and RFC 5321 is strict about it: a server must not return a success code to a VRFY or EXPN request unless it has actually verified the address, and confirming that the syntax looks right is not enough. The standard even provides a separate reply code, 252, for an address that appears valid but cannot reasonably be verified in real time. That command is not what verifiers use, because the same standard lets operators disable VRFY and EXPN entirely for security reasons. So verification services fall back to RCPT TO, where the standard sets no equivalent obligation and itself notes that some servers do not check the recipient until after the message body has been received.

A catch-all domain is the far end of that. It accepts every recipient at RCPT TO. The verifier asks about a real person and gets a yes. It asks about an address nobody has ever used and gets the same yes. There is no signal left to read.

One thing worth being precise about, because it gets stated backwards: the standard does not require servers to behave this way. RFC 5321 does not use the word catch-all and does not instruct anyone to accept everything. Accept-all is a configuration choice sitting on top of what the protocol permits, and it is the administrator's decision rather than a flaw in SMTP.

Bounce rate does not catch this either, for the same reason, and our piece on bounce rate as a quality metric covers why an address that never bounces can still be a wasted send.

How much of a list this affects

One denominator-bearing figure exists. ZeroBounce reports that more than 9% of all the emails it checked in 2025 were catch-all, out of more than 11 billion addresses processed by its verification software that year.

That population is addresses ZeroBounce's own customers submitted for verification, which is self-selected and not restricted to business senders. Our piece on list decay sets out why that matters and what else the same report claims.

Nine percent is a reasonable order of magnitude and a poor benchmark. Your own share depends on the sectors you sell into, which is the argument for measuring it rather than assuming it.

What the label means, vendor by vendor

The word your export uses is not the same word everyone else uses, and in two cases it is not even the same category.

The practical consequence lands on anyone who filters. If you exclude everything marked risky from a Bouncer or MillionVerifier export, you have also excluded full mailboxes and disposable addresses, which are different problems with different fixes. If you exclude everything marked catch-all from a ZeroBounce export, you have excluded exactly one thing. Two teams can run the same rule against two exports and end up with meaningfully different lists.

Hunter's approach avoids the bucketing question by returning a confidence score instead of a category, which pushes the threshold decision back to you.

What the vendors selling a fix are claiming

Search for catch-all verification and the results are almost entirely companies selling it. Their claims do not sit comfortably next to each other.

LeadLoft advertises verifying catch-all emails with 100% accuracy and says the feature means you never get bounces again. MillionVerifier describes an improvement of up to 70 to 80% in catch-all and business-unknown results, which is a claim about reducing the unknowns rather than eliminating them.

Kitt AI is the one that explains the method. Its description of catch-all verification is workflows that attempt to log in to third-party applications with the address and watch for a positive confirmation that an account exists.

That description is useful, because it tells you these tools are not doing SMTP verification. They cannot be, for the reason in the mechanism above. They are inferring existence from other traces of the person, which is a legitimate technique with an accuracy that depends entirely on how much of a footprint your prospects leave. Hold that next to a claim of 100% accuracy and you can judge it yourself.

Nobody publishes a measured rate. Across the documentation of ZeroBounce, NeverBounce, Hunter, Bouncer and MillionVerifier, not one states what share of catch-all addresses actually deliver, with a denominator behind it. The single number-shaped statement found anywhere is Bouncer's remark that catch-alls tend to bounce at half the rate of your original invalid percentage, which carries no sample, no window and no method.

What to actually do with them

The decision depends on two things: how many of these records you have, and what happens if a send goes wrong.

If the catch-all records are a small share of the list, send to them and watch. Your spam rate is the constraint that matters. Google asks all senders to keep spam rates reported in Postmaster Tools below 0.30%, and separately advises staying under 0.10% and never reaching 0.30%. The same ceiling is repeated in Google's requirements for senders of 5,000 or more messages a day, in force since 1 February 2024. A small slice of uncertain addresses will not move that number on its own.

If the catch-all records are a large share, sample them before committing the rest. Send to a subset, count what comes back, and you have a delivery rate for the catch-all segment of your own list. Nobody publishes that figure and no vendor can supply it, because it depends on your data. How large a sample is your call; the point is to measure before the full send rather than after it.

If the send is one you cannot afford to get wrong, a launch announcement or anything going out from a domain you have just warmed, hold the catch-all segment for a second wave and send it after the main list has established a clean pattern.

What not to do is delete them. The label says the domain could not be probed, and it says nothing about whether the people behind those addresses are worth reaching. Deleting the segment throws away an unknown number of real prospects to avoid a risk nobody has measured.

One thing to check before you plan around any of this

Everything above assumes you can see your spam rate, which means Google Postmaster Tools, set up and verified against your sending domain. If you have never done that, do it before the send rather than after, because otherwise the constraint this whole decision turns on is invisible to you.

Google's 0.30% is also the only hard published threshold you get. Mailchimp, SendGrid and Klaviyo each confirm on their own documentation that a threshold exists and decline to publish it, and Microsoft's requirements for high-volume senders to Outlook.com centre on authentication rather than on a complaint rate. Our piece on list decay covers that ground. Every other platform-specific threshold you will see quoted came from somewhere other than the platform.