Apollo verified emails and catch-all, explained

We pulled 1,164 contacts from Apollo in October, and every one of them was marked verified. Then we ran the same addresses through our email verifier. It called 725 of them Safe to Send and 398 of them Risky.

Neither tool was wrong. They were answering two different questions, and the gap between those questions has a name: catch-all. If you build lists in Apollo and treat “verified” as “safe to send”, this is the part of your list you’re not looking at.

What “verified” means in Apollo

Apollo’s help centre defines a verified email as a fully confirmed, valid address. Apollo doesn’t get there with a single mail server check. It cross-checks addresses against its own contributor network, public data, and vetted third-party providers.

Two things make the verified filter worth using every time:

• It’s free at search time. Set the email status filter to verified before you save anything, and you stop paying enrichment credits for addresses you would throw away. (More on that in our Apollo.io setup guide.)

• It’s backed by a refund. If an Apollo-verified email bounces within 30 days of purchase, Apollo refunds the credit.

On our list it did its job. Five invalid addresses in 1,164 is 0.4%.

What a catch-all domain is, and why the mail server can’t confirm it

Most email verifiers work by asking the receiving mail server whether a mailbox exists, without sending anything. For most domains the server gives a straight answer: this address exists, or it doesn’t.

A catch-all domain is set up to accept mail for every address at that domain, real or not. Ask its server about any address and the answer is always yes. So a verifier that relies on the server’s answer can’t tell the difference between the founder’s inbox and a person who left last year, whose mail now lands in a shared inbox nobody reads. It marks the address Risky, or Accept All, and leaves the decision to you.

That’s why the two answers differ. Apollo’s verified status draws on evidence from its own data. A verifier tells you what the receiving server will do with your email today. On a catch-all domain the server says yes to everything, so that second answer is “can’t tell”. How well tools cover catch-all addresses also varies between them, so verify independently before you send, whichever data source you use.

One list, two answers

The list was 1,164 founders and sales and marketing leaders at US B2B companies with 11 to 200 employees, built in Apollo and filtered to verified emails at search time. We ran every address through DeBounce on 9 October 2026.

This is what the first rows of the export look like, with the address column removed. Every row carries a result, the reason behind it, and a status code: 5 for deliverable, 4 for accept all, 7 for unreachable. The Role column flags shared inboxes like info@, and the Free column flags personal providers like Gmail.

This isn’t one odd list. Across six lists we’ve built since July, about 5,500 addresses, Safe to Send came in between 57 and 62%, catch-all between 34 and 41%, and invalid under 1%. A list with 30 to 40% catch-all is normal for B2B. It’s a measured list, not a bad one.

The Safe to Send batch went out as its own campaign. By 12 November it had reached 715 people with 2,125 emails across the sequence, and one had bounced.

What to do with each verdict

Every verdict gets its own file before anything goes into a sending tool. Here’s what we do with each:

If your list keeps coming back with more invalid or unknown addresses than this, the problem is upstream of verification. The lead list quality scorecard and our guide to building a B2B lead list cover where to look.

When to send to catch-all addresses, and how

A catch-all address can be a real decision maker who would reply. It can also be an inbox nobody checks, or an address that bounces later. You can’t know which in advance, so the goal is to send to them in a way where you can see the damage if there is any, and contain it.

Wait for a sending history

Don’t send to catch-alls from a new sending setup. Warm up for at least 14 days, launch on Safe to Send only, and add catch-all batches once your domains have a few weeks of clean sending behind them. If you’re unsure your setup is healthy, start with what bad deliverability costs.

Give them their own campaign and their own inboxes

Catch-alls go in a separate campaign, so their bounce rate and reply rate are measured on their own instead of blended into your main numbers. They also go out from a separate set of inboxes that send nothing else. Size that set to the number of catch-all contacts you plan to send to, and keep every inbox inside its daily limit, warmup included.

That way, if catch-all sends start hurting a mailbox’s health, you see it in those inboxes, and your main campaign keeps running from the ones that were never exposed.

Keep the bounce guard on

Turn on automatic pausing for bounces, and set it low. Ours pauses a campaign at 4% and we aim to stay under 2%. A catch-all batch that starts bouncing should stop on its own, not when someone notices.

Mistakes we see with catch-all addresses

The same three come up again and again:

1. Treating them as Safe to Send. The Risky batch gets merged into the main campaign because Apollo said verified. Now one bad batch can drag down the whole campaign, and you can’t tell which part of the list caused it. Catch-alls need extra checking and their own campaign.

2. Sending them from your main inboxes. If the same inboxes carry your main campaign and your catch-all sends, you can’t see what the catch-alls are doing to mailbox health until it’s already affecting everything.

3. Throwing them all away. A third of a B2B list is a lot of real buyers to discard. Holding them for a later, separate batch costs nothing.

Some verifiers now specialise in catch-all addresses and try to give a yes or no where a standard check can’t. We’ve started testing one, and it’s too early to say what it adds.

If an agent runs it for you

Teams running Apollo through Claude, ChatGPT, or a script can build these checks into the pipeline. A few things we learned doing it:

• Filter at search, not after. Apollo’s people search over the API costs no credits, and contact_email_status: ["verified"] keeps unverified contacts out before you pay to enrich anyone.

• Use the verifier’s bulk option for lists. A single-address check tests each address live against the mail server, which takes a second or two each and adds up to minutes on a full list. Send the list as one bulk job, or upload the file in the verifier’s app. Keep single-address checks for one address at a time, like a form signup.

• Read the response, not just the status code. Verifiers limit how many checks can run at once, and some answer a check over that limit with a normal 200 status and the error inside the response. Code that only looks at the status saves that error as the address’s verdict. Treat anything that isn’t a clear verdict as a retry.

• Make runs resumable. Save each address’s result as it comes back and skip the ones already done, so a run that stops halfway doesn’t pay twice for the first half.

• Write each verdict to its own file. Send ready, risky, unknown, and invalid, so the risky file can never be loaded into the main campaign by accident.

Verify before you send, then send in batches

Apollo’s verified status is a good filter, and on our list it held up: five invalid in 1,164. A verifier adds a different answer, what the mail server will do today, and on catch-all domains that answer is “can’t tell”. Send the clear verdicts, hold the catch-alls for their own campaign and inboxes, and you’re working from a measured list rather than a hopeful one.

More on keeping a sending setup healthy is in the deliverability hub. If you want the list built, verified, and split for you, that’s Data & Consulting. If you want to check what your current setup does with catch-alls, start with the audit and 14-day trial.