Let me set the scene. You're running an agent-native prospecting workflow—an AI agent (like Apollo's automation, or a custom lead gen bot) finds leads, enriches them, and sends first-touch emails without a human checking every row. This checklist is for you. It's also for the ops lead who gets pulled into a meeting after the agent burns the domain on a list of dead addresses. That was me, so listen up.
I've handled sales engagement tooling for about four years. In that time, I've personally made (and documented) 14 significant data quality mistakes that cost us roughly $30,000 in wasted credits, lost follow-ups, and one very painful domain warm-up session. Now I maintain the checklist that keeps our agent threads from repeating those errors. There are five steps. Do them in order.
Who This Checklist Is For
Use this if you're using an AI agent to automate parts of outreach—lead gen, enrichment, first-touch messaging—and your data comes from multiple sources: Apollo-io's database, old CRM lists, enrichment APIs. You care about deliverability because you've seen what a 15% hard bounce rate does to a sender domain.
Don't use this if you're a solo founder sending 20 emails a week. Just log into Apollo-io, use the built-in verification, and move on. And don't use it if you have a human reviewing every lead before it goes out—you already have the best filter.
The Five-Step Verification Checklist
Step 1: Verify at the point of acquisition, not right before send
Most teams add email verification as a last-minute "clean-up" step right before hitting send. That's backwards. In an agent-native environment, the agent pulls leads from multiple places—Apollo's lead generation database, enriched CSVs, CRM records, even scraped event lists. The verification API should be called exactly once: when the agent decides the email is worth pursuing.
Why? Because verification is a routing decision, not a gate. If you verify at the start, the agent can drop obviously invalid emails immediately, flag risky ones for a different sequence, and write the result back to the CRM before any time is wasted crafting personalized context for a dead address.
Step 2: Use verification for routing, not just filtering
This is the part most people get wrong. I know I did. They set up verification as a yes/no decision: send or don't send.
A good verification API—whether it's Apollo's native email finder verification or a third-party endpoint—returns a lot more than valid/invalid. It gives you syntax checks, domain health, catch-all detection, role-based address flags (like info@ or sales@), and a confidence score.
We configure the agent to route based on that score:
- 0–50: drop automatically
- 50–75: send one single email, no follow-ups
- 75–90: include in the normal sequence
- 90–100: add to the priority lane with same-day send
Basically, verification influences the lane, not just the launch decision. That's how you protect your domain while still getting some upside from risky leads.
Step 3: Re-verify old data on a set schedule
This is the step almost every team skips. B2B data decays roughly 22.5% per year (Gartner). If your agent pulls from a CRM list that was cleaned eight months ago, a good chunk of those emails are already dead.
We build re-verification into the agent's weekly loop: pull leads older than 90 days, run them through the API, and move anything below a confidence threshold out of active sequences. If I remember correctly, Apollo's default confidence threshold is around 80% (don't quote me on that—the settings page may have changed). We set ours to 85% for cold outreach because we're aggressive.
In the past 18 months, these scheduled re-checks caught 47 email addresses that had gone bad. That's not a huge number, but those 47 addresses would have gone into multi-touch sequences, each sending maybe 3–5 emails to a dead box. That's roughly $450 in wasted sends plus the hit to our sender reputation.
Step 4: Warehouse the verification result back into the lead record
This sounds obvious, but I've seen teams (including mine, once) run verification, use the response for the immediate send, and then throw it away. The next week, the same lead gets re-verified because nothing was stored.
In an agent-native workflow, the verification response should be written back to the lead record with three things:
- The confidence score (0–100)
- The verdict (valid, invalid, risky, catch-all)
- A timestamp
The timestamp matters more than you'd think. A lead with 95% confidence three months ago and 60% today tells you something important: the data source that fed that lead is going stale. That pattern can point to a specific list or integration that needs attention.
Step 5: Decide who owns the fallback
The one thing I underestimated when we started: no email verification API is 100% accurate. No honest vendor will claim that. So you need a rule for what the agent does with an ambiguous result.
Our fallback policy:
- "Risky but deliverable" (roughly 60–75): send a shorter, single-touch email instead of a full sequence.
- Verified but bounces anyway: the agent sends a notification to the ops team so we can review the API's behavior.
- Ambiguous result: route the lead to a human reviewer instead of guessing.
And this is where I should mention the practical part: you don't need a separate tool for most of this. When you log into Apollo (the apollo io login gets you into the whole platform), the email finder and verification are part of the same enrichment flow. For a custom agent pipeline, you'd call the verification API directly and program these fallback rules yourself.
Common Mistakes I've Made So You Don't Have To
Mistake #1: Verifying too early in the lead's lifecycle
A raw website visit, an old conference badge, a form fill from six months ago—these aren't ready for verification yet. If you verify too early, you pay for a check that will be stale by the time the lead actually enters an active sequence. Wait until the agent initiates contact, not the first moment the lead appears in your database.
Mistake #2: Treating catch-all as verified
If the API says an address is on a catch-all server, that's a warning, not a green light. Our first big list had maybe 15% catch-all domains. We treated them as "verifiable" and sent a 5-step sequence. Hard bounce rate was around 9%. That's how you destroy a domain's reputation in about two weeks.
Now, if more than a fifth of any list comes back catch-all, we prune the list heavily before the agent sends a single email.
Mistake #3: Ignoring the unit economics
Email verification APIs are paid per check. It sounds like a rounding error until your agent is running 10,000 leads a month. We trimmed about 30% of our verification spend by using Apollo's enrichment scoring to pre-filter the obvious junk before sending only the survivors to a separate verification API.
The upside was lower cost. The risk was adding another moving part to the pipeline. I kept asking myself: is saving a few hundred per month worth the extra complexity? In our case, yes. But I'd never set that up for a smaller team without seeing their actual send volume first.
Honest Limitations
This checklist assumes you're running true agent-native prospecting—where the agent handles everything from lead enrichment through first send. If your outreach is mostly manual, you're better off just using Apollo's built-in verification. You don't need another API call between your thumb and the send button.
And if your sending volume is under 500 emails a week, a separate verification API is probably overkill. Better to invest in a cleaner source list and skip the extra integration. There is no "best" setup here; it depends on your volume, your data sources, and how much automation you're actually comfortable with.
It took me three years and about 40 outreach cycles to understand that verification isn't a one-time event. It's a stage in a workflow—entry, routing, re-check, and fallback. Wire it in at all four points, and you'll save yourself a lot of bounces, a lot of money, and the exact 2 a.m. "why is our domain on a blocklist" panic that I went through so you don't have to.
