Why Do Apollo-Sourced Emails Bounce After Verification?

You pull 2,000 contacts out of Apollo, filter for verified emails only, run the file through a second verification tool, upload what survives, and three days into the campaign your bounce rate is 6.8%. Half of those bounces are "user unknown" on domains that looked perfectly healthy.

This is one of the most common complaints in outbound, and the honest answer is not that your verifier is broken. It's that verification measures one narrow thing at one moment in time, and Apollo-style databases contain a large share of addresses that were never confirmed to exist in the first place — they were inferred from a pattern. Here's how each failure mode works and what to do about each one.

{"h2":"What \"verified\" actually means"}

Email verification is mostly an SMTP conversation. The verifier looks up the domain's MX records, opens a connection to the receiving server, and asks whether it will accept mail for that address. If the server answers with a 250, the address is marked valid. If it answers 550, invalid.

That's it. Verification does not know whether the person still works there. It does not know whether the mailbox is a shared alias that nobody reads. And critically, it does not know anything useful when the receiving server is configured to say yes to everything. The full mechanics are in email verification for cold email, but the short version is: a "valid" result is a statement about one server's answer on one day, not a guarantee of a human on the other end.

{"h2":"Reason 1: data decay between scrape, export, and send"}

B2B contact data decays at roughly 2% a month — call it 20–30% a year once you account for job changes, layoffs, rebrands, and domain migrations. A database record created 14 months ago has maybe a one-in-four chance of being stale.

Apollo refreshes records, but not every record, and not on the day you export. Then you add your own lag: people routinely export a list, spend two weeks writing sequences, and launch a month later. If you verified at export time, you verified a 30-day-old snapshot.

Fix: verify as close to send as you can, and re-verify anything older than 30 days before a re-engagement push. If your list sat in a spreadsheet for a quarter, treat it as unverified and start over.

{"h2":"Reason 2: catch-all domains and pattern-guessed addresses"}

This is the big one. Depending on the vertical, somewhere between 10% and 25% of B2B domains are catch-all — the mail server accepts every address at the domain and sorts it out internally. Agencies, law firms, and smaller Microsoft 365 tenants with a mail gateway in front are heavily represented.

On a catch-all domain, a verifier cannot distinguish a real mailbox from nonsense. Ask it about `asdfgh@company.com` and you'll get a 250. Some tools report this honestly as "accept-all" or "unknown." Others quietly roll it into "valid" because that's what the server said.

Now layer on how the address got into the database. A large share of contact records are not observed addresses — they're the company's dominant pattern (first.last@, flast@, first@) applied to a name scraped from LinkedIn. On a non-catch-all domain the verifier catches the bad guesses. On a catch-all domain, nothing catches them. The guess sails through verification and bounces internally, or lands in a black-hole mailbox where nobody will ever read it.

Fix: segment catch-all records into their own campaign. Send them at low volume from a mailbox you're willing to risk, cap the segment at 10–15% of any day's send, and measure its bounce rate separately. If catch-all records bounce at 12% while confirmed records bounce at 1%, you now know exactly where your problem lives and can decide whether that segment is worth sending at all.

{"h2":"Reason 3: the server accepted it, then bounced it later"}

Not every bounce happens at the SMTP handshake. Security gateways like Mimecast, Proofpoint, and Barracuda often accept a message at the edge, scan it, and only then decide the recipient doesn't exist or the content isn't welcome. You get an asynchronous bounce minutes or hours later, which arrives in your inbox as a delivery status notification rather than an immediate rejection.

This matters because a verifier talking to the gateway gets a 250 too. The gateway is not the mailbox. Your verifier is confirming that the front door opens, not that there's a room behind it.

{"h2":"Reason 4: it isn't really a bounce — it's a block"}

A meaningful slice of what platforms count as "hard bounces" are actually reputation rejections dressed in a 5xx code. Microsoft's `550 5.7.606 Access denied, banned sending IP` and various `554 5.7.1` policy rejections have nothing to do with whether the address exists. Suppressing those contacts permanently throws away good leads and hides a deliverability problem behind a data problem.

Read the actual SMTP response before you decide what a bounce means:

{"table":{"headers":["Response","Typical wording","What it really means","Action"],"rows":[["550 5.1.1","User unknown / no such user","Address genuinely doesn't exist","Suppress permanently"],["550 5.1.10","RecipientNotFound (Microsoft)","No mailbox in the tenant","Suppress permanently"],["550 5.4.1","Recipient address rejected: Access denied","Often filtering or a disabled mailbox, not a missing one","Suppress, but investigate if it clusters"],["554 5.7.1 / 550 5.7.606","Blocked by policy / banned sending IP","Your reputation, not their address","Pause sending, fix the sender, retry later"],["451 4.7.x","Greylisted, try again later","Temporary — normal for first contact","Let the platform retry"],["452 4.2.2","Mailbox full / over quota","Real person, full inbox","Retry in a few days, then suppress"]]}}

If you want the longer breakdown of how a sending platform should treat each class, see hard bounce vs. soft bounce. The practical rule: 5.1.x codes are list quality, 5.7.x codes are sender reputation, and conflating them means you'll keep solving the wrong problem.

{"h2":"Reason 5: role accounts, aliases, and departed-employee forwards"}

info@, sales@, and support@ almost always verify clean — they exist. They also drag engagement down, attract spam complaints, and in some filters are themselves a negative signal. Worse are forwarding aliases left behind when someone leaves: the address accepts mail, forwards it to a manager who never asked for it, and you get a complaint instead of a bounce. That's a worse outcome than a bounce.

{"h2":"A workflow that keeps Apollo lists under 2%"}

{"ul":["Export with the strictest confidence filter available, then re-verify with an independent tool. Two sources disagreeing on an address is a useful signal on its own.","Split the result into three buckets: confirmed valid, catch-all/accept-all, and unknown. Treat them as three different campaigns with three different risk budgets.","Drop generic role addresses unless your offer is genuinely for a shared inbox (local services, support tooling).","Verify within 7 days of first send. Anything older gets re-run, no exceptions.","Start any new list at 20–30 emails per mailbox per day so a bad batch surfaces as 3 bounces, not 300.","Watch bounce rate per domain, not just per campaign. Five bounces at one company usually means a domain migration, not five dead people.","Pull the plug at 4%. Pause, sample 50 addresses manually, and find out which bucket is failing before you resume."]}

Manual spot-checking sounds unscalable, and it is — for 10,000 contacts. For 50, it takes fifteen minutes and tells you more than any dashboard. Open the company site, check LinkedIn for the contact, see whether the domain still resolves to the same MX host.

{"h2":"Where Sendvanta fits"}

Sendvanta doesn't sell lead data, so we have no incentive to tell you a list is cleaner than it is. What the platform does is protect you from the damage a decayed list causes: bounces are classified by SMTP code rather than lumped together, 5.1.x hard bounces go straight into suppression, and when the bounce rate on a campaign crosses your threshold the deliverability health scoring slows or pauses sending automatically instead of letting a bad batch burn the domain overnight. Engagement is scored with bot-aware classification, so a scanner hitting your links doesn't mask the fact that a segment is dead. You can test the whole workflow on the free plan — $0, no credit card, 1,000 active leads, 3,000 emails a month, up to 10 of your own SMTP mailboxes. More detail on features.

{"faq":[{"q":"Is a 5% bounce rate on an Apollo list normal?","a":"Common, but not acceptable. Confirmed-valid B2B records should bounce under 2%. If you're at 5%, the excess is almost always catch-all guesses or records older than six months that weren't re-verified before send."},{"q":"Should I just delete every catch-all contact?","a":"Not necessarily — on some domains the catch-all is just a gateway in front of real mailboxes. Isolate them in a separate low-volume campaign and measure. If that segment bounces above about 8%, the guesses outnumber the real addresses and it isn't worth the reputation cost."},{"q":"Does double verification with two tools actually help?","a":"Yes, mainly as a disagreement detector. Two verifiers querying the same SMTP server will agree on clear-cut cases; where they disagree, you've found a catch-all, a greylisting server, or a gateway — all addresses that deserve a slower, separate send."},{"q":"Do bounces hurt my domain even if I stop quickly?","a":"A short spike recovers. Sustained high bounce rates signal to Google and Microsoft that you're sending to a purchased or scraped list, and that signal persists after you clean up. Catching it in the first 200 sends is the whole game."}]}