Pre-Send Email Verification: A Workflow for Apollo, Outreach, and Lemlist

The problem: Apollo's built-in verification can mark catch-all domains as deliverable. Outreach.io has no built-in verification at all. Lemlist's verifier runs a basic SMTP check, and you're trusting it with your sender reputation. Cold outbound operators running any of these tools are sending to lists their cadence platform already told them were "fine", then watching bounce rates drift toward levels that damage sender reputation and inbox placement. The fix isn't switching cadence tools. It's a pre-send verification gate that runs before any address touches the sequence.

This post is the workflow recipe: export from Apollo / Outreach / Lemlist, run the list through the bulk-email-verifier Apify actor, branch on the returned decision enum, re-import only the safe cohort. For the strategic argument behind why a routing-decision verifier matters (and not just a status-string one), see Email Verification Isn't Enough.

What is pre-send email verification? Pre-send email verification is the practice of running every contact through a deliverability check immediately before that contact enters a cadence tool, not after a bounce already hit your sender domain. The verifier returns a routing decision (send, send-monitor, hold, verify-later, replace, suppress) so the cadence tool ingests only the safe cohort.

Why it matters: Google and Yahoo's bulk sender requirements (in force since February 2024) require a spam complaint rate under 0.3% and an authenticated SPF/DKIM/DMARC stack. A dirty list trips both. Hard bounces tank your reputation, complaints push you over the 0.3% threshold, and your inbox-placement rate collapses.

Use it when: You're running cold outbound from Apollo, Outreach, Lemlist, Salesloft, Reply.io, Smartlead, Instantly, or any tool that ingests a list and sends a cadence. Especially when the list came from scraping, purchased data, or a CRM export older than 60 days.

Problems this solves

• How to verify Apollo lists before adding them to a sequence without paying for Apollo's higher-tier verification credits
• How to add email verification to Outreach.io when Outreach has no built-in verifier
• How to clean a Lemlist campaign list beyond Lemlist's basic SMTP check
• How to handle catch-all domains in cold outbound with warmed-sender routing instead of skip-or-send guesses
• How to keep bounce rate below the 2% ESP threshold with a deterministic per-address decision
• How to integrate email verification with Zapier, Make, or n8n using flat boolean triggers your no-code tool can branch on

In this article

Quick answer · Why each cadence tool's built-in falls short · The shared workflow · Apollo workflow · Outreach workflow · Lemlist workflow · Code example · Best practices · Common mistakes · Alternatives · Limitations · FAQ

Key takeaways

• Apollo, Outreach, and Lemlist all ingest unverified addresses into sequences. Apollo's check is lenient on catch-alls, Outreach has no built-in verifier, Lemlist's is basic. Pre-send verification is the gate that closes this.
• The recipe is the same for all three: export the list, run it through a verifier that returns a routing decision (not a status string), keep only decision: "send" and decision: "send-monitor", re-import.
• bulk-email-verifier returns six decision values, flat automationTriggers booleans, and a SUPPRESSION.txt output ready for ESP suppression-list import. Those are the three primitives every cadence tool needs.
• Pricing is $0.005 per email, pay-per-event, with no subscription. A 5,000-contact list cleaning costs $25.
• Google and Yahoo's 0.3% spam-complaint threshold (in force since Feb 2024) makes pre-send verification table stakes, not optional hygiene.

Quick answer

How do you verify emails before adding them to Apollo, Outreach, or Lemlist? Export the list as CSV (or pull via API), run it through bulk-email-verifier in deliverability-audit mode, filter to records where decision is send or send-monitor, and re-upload that cohort. The verifier returns a per-address decision enum, an SLA tier, and flat automation-trigger booleans the cadence tool branches on without custom routing code.

Five-step compact version:

1. Export your contact list from the cadence tool as CSV
2. POST the email column to the verifier (Apify console or API)
3. Filter rows: keep decision: "send" and decision: "send-monitor"
4. Use the actor's SUPPRESSION.txt to populate the cadence tool's suppression list
5. Re-upload the clean cohort with decision and slaTier as custom fields

Compact examples

What is pre-send email verification?

Definition (short version): Pre-send email verification is a verification pass run on every contact immediately before that contact enters a cadence sequence, returning a routing decision per address rather than just a deliverability status.

The "pre-send" framing matters because most cadence tools assume the list is clean on ingest. Apollo, Outreach, Lemlist, Salesloft, Reply.io, Smartlead, Instantly. Each one will happily send to an address its own verifier flagged as risky. The cadence tool's job is sending, not gatekeeping. Pre-send verification puts a gate between your list and the sender domain, so the sender domain never touches an address graded suppress or replace.

There are six decision values the bulk-email-verifier Apify actor returns per address. This is the table you want to copy into your cadence-tool routing logic.

Also known as: outbound list gate, deliverability gate, pre-cadence verification, list cleaning before sequence, sender-reputation hygiene, decision-grade verification.

Why each cadence tool's built-in verification falls short

Apollo ships verification as part of its paid subscription. The verifier marks verified / guessed / unavailable, and on catch-all domains the verifier can return verified even where the actual mailbox is unconfirmable. That's not Apollo doing anything wrong. It's the limit of a one-shot SMTP check at any catch-all configuration. The catch-all domain accepts every address, so the verifier sees RCPT TO 250 and marks it deliverable. On a list of 5,000 contacts at companies running catch-all-configured mail servers, you can end up sending to addresses that never existed.

Outreach.io has no built-in verification. The platform assumes you're feeding it a clean list. If you're pulling prospects directly from Outreach without a pre-send pass, you're trusting whichever upstream tool sourced them. (Outreach documentation confirms there's no native verifier.)

Lemlist's verifier runs a basic SMTP check at the campaign-creation step. It catches the obvious hard bounces but doesn't differentiate catch-all from confirmed-mailbox or score domain authentication (SPF / DKIM / DMARC). On a list with many small-business domains, you'll still see catch-all bleed through.

The fix in all three cases is the same: don't rely on the cadence tool's built-in. Run a verification pass before the list enters the tool at all.

The shared workflow: export → verify → branch → re-import

Every cadence-tool integration with bulk-email-verifier is a variation of the same four-step recipe:

1. Export the contact list as CSV from the cadence tool (or pull via the tool's API if you prefer programmatic). The email column is all the verifier needs; everything else passes through unchanged.
2. Verify by POSTing the email array to the actor with mode: "deliverability-audit". The actor returns one structured record per address with a decision enum, an slaTier, an automationTriggers flat-boolean block, and a failureAnalysis block with the root-cause explanation.
3. Branch on the decision. Three cohorts: send and send-monitor go back to the cadence tool, replace routes to email pattern regeneration, suppress populates the cadence tool's suppression list.
4. Re-import the clean cohort. CSV upload for Apollo and Lemlist. API push for Outreach. Optional: chain into HubSpot Lead Pusher or Salesforce Lead Pusher if the contact also lives in your CRM.

The reason this recipe works regardless of cadence tool: the verifier returns flat boolean triggers (sendToCadence, sendToSuppression, requiresEnrichment) instead of nested objects. A Zapier filter, an n8n IF node, or a one-line pandas filter can branch on those booleans without parsing.

Apollo workflow: export CSV, verify, re-upload as saved list

1. In Apollo, run your saved search (or open an existing saved list). Click Export → Export to CSV. Apollo applies a credit cost per export depending on plan tier; verify your current usage against the Apollo pricing page.
2. Open the CSV. The email column is Email by default. That's the input.
3. Open the bulk-email-verifier actor. In the Apify console, paste the email column into the emails field and set mode to deliverability-audit. Click Start.
4. When the run finishes, download the dataset as CSV. You now have one row per email with decision, confidence, slaTier, automationTriggers, and failureAnalysis columns appended.
5. Filter to decision IN ('send', 'send-monitor'). That's your re-upload cohort.
6. In Apollo, create a new saved list and import the filtered CSV. Map the decision and slaTier columns to custom fields so your sequences can branch by tier later.
7. Take the rows where decision == 'suppress' and add their domains to Apollo's Do Not Contact list to prevent re-ingestion on the next search.

The send-monitor cohort is the one most operators forget about. These are catch-all and free-provider addresses. They aren't suppress, but they need a warmed sender. Route them to a separate sequence sent from a warmed inbox, not your main sender domain.

Outreach workflow: export or API, verify, Zapier routes to cadence

Outreach doesn't have a one-click CSV import for prospects into sequences, so the workflow has one extra step compared to Apollo.

1. Export prospects from Outreach, either via Prospects → Export or programmatically via the Outreach REST API (GET /api/v2/prospects).
2. Verify with bulk-email-verifier the same way: post the email array, mode: "deliverability-audit", retrieve the dataset.
3. Branch with Zapier, Make, or n8n. The trigger is a new row in the verified dataset; the filter is automationTriggers.sendToCadence == true; the action is Outreach → Add Prospect to Sequence.
4. For decision == 'suppress' rows, the action is Outreach → Add Tag: do-not-contact so the prospect never gets pulled into another sequence.

Outreach charges per prospect on most plan tiers. Confirm your team's current Outreach pricing before bulk-importing a large verified cohort. The verified cohort is smaller than the source list, which is the point: you stop paying Outreach to store contacts you're never going to send to.

Lemlist workflow: export campaign, verify, re-import cohort

Lemlist's workflow is the simplest of the three because Lemlist's CSV import is permissive on column names.

1. In Lemlist, open your campaign → Leads → Export to CSV.
2. Run the email column through bulk-email-verifier (deliverability-audit mode).
3. Take the verifier's SUPPRESSION.txt output (the Key-Value Store key, written automatically when the actor finds suppress-graded records) and import it into Lemlist's Settings → Suppression List. This stops the suppressed addresses from being ingested into any future campaign.
4. Filter the verifier's dataset to decision == 'send' and start a new clean Lemlist campaign with that cohort. Keep decision == 'send-monitor' in a separate campaign tied to a warmed sender domain. Lemlist lets you assign different sending mailboxes per campaign, which makes this clean.
5. Optional: set the new campaign's bounce-rate alert threshold to 1.5% so Lemlist pauses sending before you hit the 2% ESP-safe line.

Code example: Python client for the Apollo workflow

The pattern below shows how to call the verifier from a Python script after exporting the Apollo CSV. It does not re-implement verification. It submits the email list to the actor and reads back the decisions.

import csv
from apify_client import ApifyClient

client = ApifyClient("YOUR_APIFY_API_TOKEN")

# 1. Load emails from the Apollo CSV export
with open("apollo_export.csv") as f:
    emails = [row["Email"] for row in csv.DictReader(f) if row["Email"]]

# 2. Submit to bulk-email-verifier in deliverability-audit mode
run = client.actor("ryanclinton/bulk-email-verifier").call(run_input={
    "emails": emails,
    "mode": "deliverability-audit",
    "verificationLevel": "deep",
    "outputProfile": "minimal",
})

# 3. Branch on the returned decision per record
safe_to_send = []
warmed_only = []
suppress = []
replace_needed = []

for item in client.dataset(run["defaultDatasetId"]).iterate_items():
    decision = item.get("decision")
    if decision == "send":
        safe_to_send.append(item["email"])
    elif decision == "send-monitor":
        warmed_only.append(item["email"])
    elif decision == "suppress":
        suppress.append(item["email"])
    elif decision == "replace":
        replace_needed.append(item["email"])

# safe_to_send → re-upload to Apollo as new saved list
# warmed_only → separate sequence on warmed sender domain
# suppress → add to Apollo Do Not Contact
# replace_needed → re-enrich (email-pattern-finder or waterfall-contact-enrichment)

The outputProfile: "minimal" flag keeps the response narrow: just the decision primitives the workflow needs, not the full diagnostic stack. For richer fields (failure analysis, deliverability simulation, SLA tier), switch to standard.

Try it on a small list. Run a 100-email batch from your next Apollo / Outreach / Lemlist export through bulk-email-verifier and compare its decision output against your current campaign's bounce rate. New Apify accounts include $5 in free credit, enough for 1,000 verifications. Open the actor and start with a single export.

Best practices for pre-send verification

1. Verify on export, not on import. Treat the cadence tool as a sending engine, not a list gatekeeper. The gate is upstream.
2. Use deliverability-audit mode for pre-campaign lists. It enables deep SMTP + catch-all detection + domain authentication checks (SPF/DKIM/DMARC) with no opinionated routing changes, so you keep editorial control over the cohort.
3. Treat send-monitor as a separate sender domain queue. Don't mix catch-all addresses into your primary cadence. Route them to a warmed-sender sequence with a stricter bounce-rate alarm.
4. Re-verify monthly on weekly-active cohorts, quarterly on long-tail. Email lists decay; a 90-day-old verified address has a non-trivial probability of being invalid by the time you send.
5. Populate the cadence tool's suppression list, not just your own filter. Filtering catches today's send; populating Lemlist / Apollo / Outreach's native suppression catches every future send.
6. Map the decision enum into a custom field in your cadence tool so sequences can branch on it. This is how an Apollo sequence sends a different opening line to send-monitor (warmed-sender) cohorts vs send cohorts.
7. Set a per-run spending limit in Apify. The verifier is $0.005 per email but a runaway script can still rack a bill. Cap it.

Common mistakes when wiring verification into cadence tools

1. Trusting the cadence tool's "verified" flag. Apollo's verifier is lenient on catch-alls. Outreach has no verifier. Lemlist's is basic. The cadence tool's verification is not equivalent to a pre-send gate.
2. Treating catch-all addresses as send-safe. Catch-all domains accept every address at the SMTP layer, so a naive verifier returns valid even when the actual mailbox doesn't exist. Route catch-alls to send-monitor, never to send.
3. Sending the verified cohort from the same sender domain as the un-verified cohort. If you previously sent to a dirty list, your sender domain's reputation is already partially degraded. Move the clean cohort to a fresh sender domain (or at least a warmed sub-domain) so you're not bottlenecked by old damage.
4. Skipping the suppression-list import. The verifier returns a list of addresses that should never be sent to again. If you only filter the current export and don't populate the cadence tool's suppression list, the same bad address will come back next month from the next CRM sync.
5. Forgetting to re-verify after a long pause. A list verified in March and used in June is no longer a verified list. Re-run the cohort before reactivating an old campaign.
6. Using verification as a one-time event instead of a recurring schedule. Schedule the verifier weekly (or monthly for long-tail) on a stable watchlist. The actor's delta block flags recovered and degraded addresses between runs.

What are the alternatives to pre-send verification?

Pricing and features based on publicly available information as of May 2026 and may change.

The subscription-verifier row is the one most operators land on first. It's a sensible default: the SMTP-depth check is solid across NeverBounce, ZeroBounce, Kickbox, and BriteVerify. The constraint they share is that you get back a status, not a decision. Your ops team still writes the routing logic that turns valid / risky / unknown into a cadence-tool action.

Treating the verification problem as "I need a routing decision per address" instead of "I need a status string" is what makes the workflow recipe in this post work. bulk-email-verifier is one of the few verifiers that returns the decision directly. That said, if your existing stack is fully wired to a subscription verifier's status-string output and the routing logic already exists, the marginal value of switching is smaller.

Implementation checklist

1. Identify the source cadence tool (Apollo / Outreach / Lemlist / other) and the export method (CSV / API)
2. Get an Apify API token from console.apify.com/account/integrations and set it in your environment as APIFY_API_TOKEN
3. Run a 100-email pilot through bulk-email-verifier in deliverability-audit mode to confirm output shape matches your re-import target
4. Decide your routing rules: which decisions re-enter cadence, which go to suppression, which go to re-enrichment
5. Build the filter step in your tool of choice (Zapier filter, n8n IF node, pandas DataFrame, or a one-line shell pipeline)
6. Populate the cadence tool's native suppression list from the actor's SUPPRESSION.txt output
7. Re-import the send + send-monitor cohort with decision and slaTier mapped to custom fields
8. Set a per-run spending limit on the Apify actor so a bad script can't overrun budget
9. Schedule the verifier weekly with a stable watchlistName so cross-run delta tracking flags recovered and degraded addresses

Limitations

• Pre-send verification doesn't fix sender-reputation damage that already happened. If your domain is already in a deliverability hole, you need a warmed-sender migration plan in addition to verification.
• Catch-all domains remain the hard case. No SMTP verifier (this actor or any other) can deterministically confirm a mailbox at a catch-all domain. The send-monitor decision is a routing hedge, not a guarantee of deliverability.
• Verification quality depends on SMTP availability and mail-server behavior. When destination mail servers rate-limit probes, defer rejection, or block probe traffic, deep-mode verification falls back to MX-plus-pattern confidence and decision quality drops for unknowable mailboxes.
• Re-import is manual unless you wire it. Apollo and Lemlist's CSV import is manual. Outreach's API push is one Zapier/Make zap. If you want the whole loop automated, you're writing the integration.
• Verification is not a substitute for a sender warm-up. A clean list sent from a cold domain still has poor inbox placement. Warm the domain first; verify the list second.

Key facts about pre-send email verification

• Cost: $0.005 per email verified with the bulk-email-verifier Apify actor, no subscription, no monthly minimum. A 5,000-contact list costs $25.
• Batch size: 1 to 100,000 emails per run, with domain-level MX caching so 10,000 contacts at the same company resolve from a single DNS lookup.
• Verification layers: Seven independent checks. Syntax (RFC 5322), DNS MX records, disposable detection (55,000+ domain list via MailChecker), role-based prefix matching (64 patterns), free-provider identification (60+ providers), live SMTP mailbox probe, and dual-random-address catch-all detection.
• Decision enum: Six values. send, send-monitor, hold, verify-later, replace, suppress. Cadence tools branch on this directly.
• Throughput: Standard mode processes roughly 1,000 emails in 30 seconds. Deep mode (SMTP + catch-all) takes 5-15 minutes per 1,000 depending on mail-server response times.
• Output shape: One JSON record per email with decision, confidence, slaTier, automationTriggers, failureAnalysis, deliverabilitySimulation, and a nextActions[] array of sibling-actor calls.
• Suppression integration: Actor writes a SUPPRESSION.txt key to the Key-Value Store, formatted for direct ESP suppression-list import.

Short glossary

• Catch-all domain: A domain configured to accept email at any address, so an SMTP probe always returns 250 regardless of mailbox existence. Cannot be deterministically verified by SMTP.
• Bounce rate: Percentage of sent emails returned undelivered. Mailbox providers apply soft thresholds; staying below 2% is the operator rule of thumb.
• Spam complaint rate: Percentage of recipients who mark the email as spam. Google's 2024 sender requirements put the hard threshold at 0.3%.
• Cadence tool: Outreach.io, Salesloft, Apollo, Lemlist, Smartlead, Instantly, Reply.io. Sends multi-step sequences from a sender mailbox.
• Sender reputation: Mailbox providers' internal score for your sending domain. Driven by bounce rate, complaint rate, authentication (SPF/DKIM/DMARC), and engagement signals.
• Pre-send verification: Verification run before any address enters the cadence tool, returning a routing decision per address.

Broader applicability

Pre-send verification is a specific instance of a broader pattern: putting a deterministic decision gate between data sourcing and data action. The same architecture applies whenever the sourcing layer can produce noisy output and the action layer (cadence tool, CRM, ESP, ad platform) lacks the context to filter it.

Four universal principles from the pattern:

• The gate runs before the action layer, not inside it. Tools that send / publish / push are bad at gatekeeping because their job is throughput.
• The gate returns a decision, not a signal. Routing logic embedded in the gate beats routing logic embedded in twenty downstream consumers.
• The gate populates the action layer's suppression / block list, not just filters the current batch. Repeat-offender suppression is what makes the gate compounding.
• The gate is scheduled, not one-shot. Data decays. The gate runs against a stable watchlist with cross-run delta tracking.

These principles apply to phone-number routing, lead scoring, CRM hygiene, fraud screening, and signup gating, not just email verification.

When you need this

You need pre-send email verification if:

• You run Apollo, Outreach, Lemlist, Salesloft, Reply.io, Smartlead, or Instantly with a list sourced from scraping, purchased data, or a CRM older than 60 days
• Your last campaign's bounce rate was above 1.5%
• Your sender domain has been in deliverability decline and you can't pinpoint why
• You ingest contacts from a third-party enrichment pipeline (Clay, Apollo enrichment, ZoomInfo) and want a final gate before send
• You're sending from a new domain and need clean lists for the warm-up window

You probably don't need this if:

• Your list is fewer than 50 contacts that were hand-curated from referrals (the manual triage is faster than the workflow)
• You're sending purely transactional email (password resets, receipts) to subscribed users, where bounce is a different problem
• Your existing verifier-plus-routing pipeline is already returning a routing decision (not just a status) and you've tuned it on real bounce outcomes

Frequently asked questions

Does Apollo's built-in verification replace the need for a pre-send verifier?

No. Apollo's verifier marks catch-all domains as verified because the SMTP probe at a catch-all returns 250 regardless of whether the mailbox exists. On a list of 5,000 contacts at companies running Google Workspace catch-alls, you'll send to addresses that never existed. Pre-send verification with deep catch-all detection is the gap-filler. Apollo's check is fine for non-catch-all corporate domains, less so for SMB lists.

How do I verify a list for Outreach.io when Outreach has no built-in verifier?

Export your Outreach prospects as CSV (or pull via the GET /api/v2/prospects endpoint), submit the email column to bulk-email-verifier in deliverability-audit mode, filter to decision IN ('send', 'send-monitor'), then push the clean cohort back into a sequence via Zapier, Make, or n8n. Outreach's API accepts the re-import directly. Add decision == 'suppress' addresses as a do-not-contact tag in Outreach.

Why does pre-send verification matter more in 2026 than it did in 2022?

Google and Yahoo's bulk sender requirements, in force since February 2024, made the deliverability bar measurably stricter. A spam complaint rate above 0.3% triggers downgrading, and authentication (SPF / DKIM / DMARC) is mandatory rather than recommended. The penalty for a dirty list is now real and quantifiable, not a soft signal.

How much does it cost to verify 10,000 emails before a campaign?

At $0.005 per email, verifying 10,000 emails through bulk-email-verifier costs $50, pay-per-event, no subscription. For comparison, most subscription-tier verifiers charge per-email plus a monthly platform fee. Confirm against current published vendor pricing. The savings compound at higher volume because there's no minimum and no platform fee on the Apify actor.

Can I run the verifier directly from Zapier or Make without writing code?

Yes. Apify has native Zapier and Make integrations. The Zapier "Run an Apify actor" action accepts the emails array as input and returns the dataset as output, which you then filter on decision in a Zapier filter step. This is the simplest implementation for a small team without engineering bandwidth. For higher volume, the Python or JavaScript client in the actor's README is cleaner.

What's the difference between this workflow and just using a status-string verifier?

A status-string verifier returns valid / risky / unknown. Your ops team writes the routing logic that turns those statuses into a cadence action (send / send-monitor / suppress). A decision-grade verifier returns the action directly (decision: "send", decision: "send-monitor", decision: "suppress"), so the cadence tool branches without custom code. Same SMTP depth, less wiring. For the strategic argument behind this, see Email Verification Isn't Enough.

How often should I re-verify a list?

Weekly for active outbound cohorts, monthly for long-tail. Use the actor's watchlistName parameter to enable cross-run state. Subsequent runs add a delta block per address with values new, changed, recovered, degraded, or unchanged. The recovered flag tells your cadence tool to re-engage previously suppressed contacts whose mailboxes came back online. The degraded flag tells you to re-enrich contacts who dropped from send to replace.

Ryan Clinton publishes Apify actors and MCP servers as ryanclinton and builds developer tools at ApifyForge.

Last updated: May 2026

This guide focuses on Apollo, Outreach, and Lemlist, but the same export → verify → branch → re-import pattern applies to any cadence tool that ingests a list and sends a sequence. Salesloft, Reply.io, Smartlead, Instantly, and custom in-house tools included.