How to Handle Catch-All (Accept-All) Emails on a Cold List

You run your cold list through a verifier expecting two piles: valid and invalid. Instead, a chunk of your addresses comes back tagged "catch-all," "accept-all," or "unknown." That's not a yes. It's not a no. It's the verifier telling you it couldn't get a straight answer from the receiving server, and now the decision is yours.

This is the part of catch-all email verification that trips people up. A catch-all verdict means the domain is configured to accept mail for any address, real mailbox or not, so the standard check that proves an address exists just doesn't work there. Delete the whole bucket and you throw away real prospects, often a fifth or more of a B2B list. Send to all of it blindly and you risk a bounce spike that drags your sender reputation down with it.

There's a smarter middle path. This guide explains exactly what an accept-all verdict is at the protocol level, why even good verifiers can't resolve it, how common it really is, and the risk-scoring and partial-send framework that lets you mail the safe part of the bucket without torching your domain. For the broader verification workflow, our guide on verifying email addresses before sending covers the full pipeline; this post drills into the one bucket that pipeline can't resolve.

Key Takeaways

• A catch-all (accept-all) domain returns a "250 OK" for every address, so verification can't separate real mailboxes from fake ones on that domain.
• Hunter's data puts roughly 38% of email domains in the accept-all category, and emails sent to them bounced about 27x more than verified addresses in their test.
• Many Microsoft 365 tenants look like catch-all to a verifier because of how they accept mail, not because every address is real.
• The right move isn't delete-all or send-all. It's risk-score each address, then send a small, isolated, capped batch and watch the bounce rate before scaling.

What a catch-all (accept-all) verdict means in email verification

Start with how normal verification works, because catch-all is the exception that breaks it. When a verifier checks an address without sending a real message, it opens an SMTP conversation with the recipient's mail server and issues an RCPT TO command for the address. The server's reply is the answer. Under RFC 5321, the SMTP standard, a 250 reply means the recipient was accepted and the server stored the forward-path, while a 550 reply means the address is "known not to be a deliverable address," usually with a string like "no such user." Valid returns 250. Invalid returns 550. Clean.

A catch-all domain breaks that clean split. The receiving server is set up to accept mail for every address on the domain, whether the specific mailbox exists or not, so it returns 250 OK for everything. Test [email protected] and you get 250. Test [email protected], an address that can't possibly exist, and you get 250 too. Both look identical at the protocol level. The server has decided to accept first and sort out delivery later, which means the one signal verification depends on has gone flat.

That's also how verifiers detect a catch-all in the first place: they probe the domain with a deliberately impossible local-part (a long random string), and if the server accepts it, the domain is flagged accept-all. Detection is easy. Resolution is the hard part. Knowing a domain is catch-all tells you the protocol won't help you. It doesn't tell you whether the specific person you want to reach is actually there.

So "catch-all" or "accept-all" in your results isn't a quality grade on the address. It's a property of the domain's mail server. The address might be perfectly real and monitored daily. It might be a typo that will hard-bounce on the first send. The verifier genuinely cannot tell you which, and any tool that reports catch-all addresses as confidently "valid" is guessing.

Why catch-all email verification can't give you a clean answer

The core reason is simple: the receiving server refuses to reject. But there are two distinct situations hiding under one "accept-all" label, and confusing them leads to bad decisions.

The first is a true catch-all. An admin configured the domain to funnel all mail to a single inbox or to accept everything and filter later. This is common on small-business domains, where one person reads info@, sales@, and their own name at the same domain. On these, an unknown address might reach a human or might sit unread, but the server won't tell you which.

The second is greylisting, which often gets mislabeled. Here the server temporarily defers the verification attempt because it doesn't recognize the connecting IP, returning a soft "try again later." Many greylisted addresses are perfectly valid and would resolve on a retry, but a lazy verifier lumps them in with catch-all or marks them "unknown." The two carry very different risk, so it's worth knowing your tool distinguishes them.

Then there's the Microsoft 365 wrinkle, which has gotten worse for cold senders. A large share of business mailboxes sit on Microsoft 365, and how a given tenant answers RCPT TO depends on its configuration. Microsoft's own Directory-Based Edge Blocking (DBEB) rejects invalid recipients at the perimeter when a domain is set to Authoritative and all its recipients live in Exchange Online: an unknown address bounces with 550 5.4.1 Recipient address rejected: Access denied. But when the domain is set to Internal relay, common during hybrid migrations, Microsoft accepts the mail and relays it onward instead of rejecting unknown recipients up front. To a verifier, that second configuration looks exactly like a catch-all. The tenant is accepting everything, so the probe can't separate real from fake. The address could still be a live, monitored mailbox; the server just isn't willing to confirm it during the handshake.

The practical takeaway: a catch-all verdict is a "we can't confirm," and the cause ranges from a genuinely sloppy small-business domain to a correctly configured enterprise tenant that simply won't answer recruiter probes. You can't grade the address from the verdict alone. You have to bring in signals the SMTP conversation never gave you.

How common are accept-all domains, really?

Common enough that ignoring the bucket means ignoring real pipeline. Hunter, analyzing its own verification traffic, reports that about 38% of email domains are configured as accept-all, though the ratio swings by industry and region. That's domains, not addresses, and the distinction matters. Catch-all configurations cluster at smaller companies, which are numerous but hold fewer seats each, so the share of addresses on catch-all domains in a typical B2B prospecting list usually lands lower than the domain percentage, often in the 20–30% range depending on who you target.

Why does B2B get hit so much harder than consumer lists? Two reasons. Consumer mailboxes mostly live on Gmail, Yahoo, and similar providers that reject unknown recipients cleanly, so those verify fine. Business domains are a mixed bag of self-hosted servers, security gateways, and the Microsoft 365 relay setups above, all of which lean toward accepting first. If you're building a B2B list, accept-all isn't an edge case you can wave off. It's a standing slice of every list you'll ever touch, which is exactly why our guide to building a high-quality B2B lead list treats verification as a core step rather than an afterthought.

The trap is treating the entire bucket as one thing. Some of those accept-all addresses are your best-fit prospects at well-run companies. Others are scraped guesses that will bounce the instant you send. Lumping them together forces a bad binary: keep all the risk, or delete real opportunities. Risk scoring is how you split the bucket instead.

The real cost of sending blind to catch-all addresses

Before the framework, be honest about the downside, because it's the whole reason this bucket needs handling. In Hunter's own experiment, the accept-all segment bounced at 27%, against 1% for the verified control group, roughly 27 times the bounce rate. Send a campaign to a pile of unscored catch-all addresses and a chunk of them are coming back as hard bounces.

Bounces aren't a cosmetic metric. They're a reputation signal. Mailbox providers read a rising bounce rate as a sign you're working from a stale or scraped list, which is exactly the profile of a spammer. Push your bounce rate up and you push your inbox placement down, even for the valid addresses in the same campaign. For what counts as a healthy bounce rate and where the danger lines sit, see our breakdown of what a good email bounce rate looks like; the short version is that cold senders want to keep it low single digits, and a catch-all blast is one of the fastest ways to blow past that.

There's a second-order hit too. Google calculates your spam rate daily and tells bulk senders to keep it under 0.1%, and to never let it reach 0.3%. High bounce volume and the spam complaints that ride along with poorly targeted sends both feed that number. A bad catch-all batch doesn't just bounce. It can nudge your spam rate toward the line that gets you filtered, which is the start of the slide our guide on recovering a burned domain exists to reverse. The goal here is to never need that guide.

One more distinction worth keeping straight: not every bounce from this bucket is permanent. Some are soft bounces that clear on a retry, others are hard bounces signaling the mailbox truly doesn't exist. The difference changes how you react, and our explainer on hard bounce vs soft bounce covers which is which.

Risk scoring catch-all emails: the signals that matter

Since the SMTP handshake won't grade the address, you grade it with everything else you know. Risk scoring catch-all emails means stacking independent signals that each nudge your confidence up or down, then keeping the addresses that clear a threshold and dropping the rest. No single signal is proof. Together they're a reliable filter.

Here are the signals that move the needle, and which direction:

Read the table as a tally, not a checklist. An address that's a real name, matches the company's first.last@ convention, shows up on the prospect's LinkedIn, and sits on a Microsoft 365 domain is a strong send despite the catch-all flag. An address that's a tool-generated guess on a parked domain with no web footprint is a skip, full stop, even though the server said 250.

Two practical notes. First, role-based addresses on catch-all domains are usually the worst of both worlds: low reply value and high bounce or complaint risk, so default to dropping them. Second, when an address has independent corroboration, a verified profile, a match on the company website, a confirmed format, the catch-all flag stops mattering much. You're no longer relying on the server to confirm the mailbox; you've confirmed the person through other means. That's the whole point of scoring. A clean source pipeline upstream, like the kind a built-in finder produces when it pulls contacts from public business directories, hands you most of these signals for free, which beats buying a list of unscored guesses every time.

Should you email catch-all addresses? A decision framework

So should you email catch-all addresses at all? Yes, but selectively, and never the same way you mail your verified-valid pile. Use a simple three-way decision based on the score above plus how much the account is worth to you.

The logic underneath: your tolerance for catch-all risk should scale with the prospect's value and shrink with the size of the batch. One dream account justifies manual research or a LinkedIn touch to confirm the contact. A thousand mid-tier catch-all guesses justify nothing but a delete or a tiny test. The mistake is treating both the same.

For the in-between cases, the medium scores, the partial send is the operator's tool. Don't commit the whole segment at once. Send to a small slice first, let the bounces report back over a day or two, and only scale into the rest if the bounce rate stays sane. A test batch that bounces at 15% is telling you the segment is mostly junk; pull the plug. One that bounces at 2% is telling you your scoring worked; proceed. You're letting real-world delivery confirm what the protocol wouldn't.

A safe playbook for sending to the catch-all bucket

When you decide a catch-all segment is worth mailing, the how matters as much as the who. The goal is to contain the blast radius so a bad batch can't reach your core reputation. Work it in this order.

1. Quarantine the bucket. Never blend catch-all addresses into the same send as your verified-valid contacts. Keep them in a separate segment so their bounces don't contaminate the metrics, or the reputation, of a clean campaign.
2. Score and prune first. Apply the signal table above and drop everything below your threshold, all role boxes, all parked domains, all uncorroborated guesses. Most of the risk leaves the building right here.
3. Cap the share. Keep accept-all addresses to a small slice of any given day's volume. Hunter suggests limiting them to roughly 2–5% of a campaign. The idea is that even if a batch bounces hard, it's too small to move your overall rate.
4. Test before you commit. Send a small batch from the segment, wait for bounces to settle, and read the result before scaling. This is the single most protective step, because it surfaces a bad segment before it can do real damage.
5. Isolate the mailboxes. Route catch-all sends through dedicated or rotation mailboxes, not your highest-value inbox. If something goes wrong, the damage is contained to a sending account you can pause. Our inbox rotation strategy covers how to spread volume so no single mailbox carries dangerous load.
6. Watch the dashboards. Track bounce rate and your Gmail Postmaster spam rate while the segment is live. If bounces climb or the spam rate drifts toward 0.1%, stop and re-score. Catch it on the dashboard, not in a placement crash three weeks later.

This is the same discipline that drives a real list-hygiene routine. If you want the full pre-send scrub that this fits into, work through our email list cleaning checklist, and run the whole sending stack against our deliverability audit before a big campaign.

Common questions about catch-all email verification

What does "accept-all" mean in email verification?

It means the recipient's mail server is configured to accept messages for any address on the domain, so it returns a 250 OK even for addresses that don't exist. Because the server won't reject unknown recipients, a verifier can't separate real mailboxes from fake ones using the normal SMTP check, and reports the result as accept-all, catch-all, or unknown rather than valid or invalid.

Are catch-all emails safe to send to?

Some are, some aren't, and the verdict alone won't tell you which. In Hunter's test, accept-all addresses bounced about 27 times more often than verified ones. The safe ones are those you can corroborate through other signals, a real name, a pattern match, a confirmed web presence. Score them first, send the high-confidence ones in a small isolated batch, and skip the uncorroborated guesses.

Why does my verifier mark Outlook and Microsoft 365 addresses as catch-all?

Often because of how the tenant is configured, not because every address is real. When a Microsoft 365 domain is set to Internal relay (common in hybrid migrations) it accepts mail for unknown recipients and relays it, which looks identical to a catch-all to a verifier. When it's set to Authoritative with Directory-Based Edge Blocking, it rejects invalid recipients with 550 5.4.1 instead. The address may well be a live mailbox; the server just won't confirm it during the handshake.

Should I delete catch-all emails from my list?

Not wholesale. Deleting the entire bucket throws away real prospects, since accept-all clusters on legitimate business domains. Delete the low-confidence ones (role boxes, parked domains, uncorroborated tool guesses) and keep the high-confidence ones for a careful, segmented send. The point is to split the bucket by risk, not to nuke it.

Can you verify a catch-all email at all?

Not with certainty through SMTP alone, because the server accepts everything by design. What you can do is raise your confidence with outside signals (source corroboration, pattern matching, domain quality) and confirm in the real world with a small, monitored test send. Some verifiers claim deeper checks against specific providers, but treat any "verified valid" claim on a catch-all domain as a probability, not a guarantee.

The bottom line

A catch-all verdict isn't a dead end, and it isn't a green light. It's an incomplete answer that puts the judgment back on you. The server has decided to accept everything, so the protocol that normally proves a mailbox exists has gone silent, and roughly a fifth to a third of your B2B list can land in this bucket.

Handle it like an operator, not a gambler. Don't delete the bucket and lose real prospects. Don't blast it and invite a 27x bounce spike. Risk-score every address with the signals the SMTP handshake never gave you, send the high-confidence slice in a small, isolated, capped batch, and let real-world bounces confirm what verification couldn't. Do that and the catch-all bucket becomes a source of pipeline instead of a reputation liability.

MailBeast builds this into the flow: contacts sourced from public business directories arrive with the corroboration signals that make scoring possible, verification flags the accept-all bucket clearly, and per-mailbox throttling keeps a test batch contained. The bucket you used to delete on sight is the one your competitors are still ignoring.

Sources

• IETF, RFC 5321: Simple Mail Transfer Protocol
• Microsoft, Use Directory-Based Edge Blocking to reject messages sent to invalid recipients in Exchange Online
• Google, Email sender guidelines
• Hunter, What Are Accept-all Email Addresses, and How to Use Them