Should You Re-Verify an Apollo Export Before Sending It?

Re-verify an Apollo export when it contains anything other than fresh Verified addresses. Apollo's own help centre says its verified emails are 91% accurate, that verified emails older than 6 months lose its bounce guarantee, and that an acceptable bounce rate is under 2%. Those figures do not line up, and the gap is what re-verification is for.

This post is about deciding which rows to re-check, using Apollo's own definitions as read on 1 October 2026.

What Apollo itself claims

Apollo publishes specific numbers, and they are worth reading side by side. All of the following are from Apollo's knowledge base:

Apollo statement	Source
Verified emails "maintain an email match rate of 84% and an accuracy rate of more than 90%"	Email Status Overview
"Apollo verified emails have an accuracy rate of 91%" and "many factors contribute to Apollo's 9% bounce rate"	How Apollo Verifies Emails
If a verified email "bounces within 30 days of you purchasing it, Apollo automatically refunds the credit"	Email Status Overview
"If Apollo provided you with a verified email address more than 6 months ago, we do not provide the same level of bounce rate guarantee"	Troubleshoot Bounced Emails
"An acceptable bounce rate is typically under 2%. ... If your bounce rate consistently exceeds 5%, you should investigate immediately."	Troubleshoot Bounced Emails
"You don't need a third-party verification tool"	How Apollo Verifies Emails

To be fair to Apollo: it says invalid addresses make up "a very small portion" of the 9%, with the rest down to recipients blocking mail, full mailboxes, unresponsive servers and the sender's own reputation. These are vendor claims and none of them is independently audited, which is true of every verifier's accuracy figure, ours included. We do not publish one.

The point is narrower. Even taking Apollo at its word, a figure framed as a 9% bounce rate sits well above the 2% Apollo itself calls acceptable. You do not have to believe Apollo's data is poor to want a second check before a large send.

What each Apollo email status means

Apollo's statuses describe where an address came from as much as whether it works. From the Email Status Overview:

Status	Apollo's definition (abridged)	Re-verify?
Verified	"A fully confirmed, valid email address"	Only if older than a few months, or for a new domain
Unverified	Emails Apollo "was unable to verify", including your own imports, plus emails "where Apollo has low confidence in their validity"	Yes, always
Update required	Apollo has detected a job change for a saved contact	Yes, or enrich first; the person may have left
Unavailable	"An email that Apollo is unable to find or verify"	Nothing to verify
User managed	Uploaded from your CRM or CSV, or edited by your team	Yes; Apollo makes no claim about these
Catch-all	The domain accepts "every email sent to that domain, even if the email address doesn't exist"	See the catch-all section below

Apollo's own advice on unverified addresses is blunt: "Only use unverified emails as an infrequent last resort."

The columns to export

Apollo's CSV export can include the fields you need to decide, but they are not always selected by default. Its export guide lists these among the available contact fields:

• Email status
• Primary email catch-all status
• Primary email last verified at
• Primary email source
• Primary email verification source

Apollo notes that "emails and phone numbers aren't always included by default" and that a field not selected in the export settings "appears blank in the exported CSV, even if data exists in Apollo". Use Edit export CSV settings to add them. The guide also warns that spreadsheet apps may reformat long IDs and dates, so import those columns as text.

A decision table for each row

Sort the export by status and by how long ago it was verified, then treat each group differently. This is our working method, not Apollo's:

Row looks like	What to do
Verified, last verified recently, not catch-all	Send. Re-verify only if the list is going to a new domain or a send larger than you have tried before
Verified, last verified more than about 3 to 6 months ago	Re-verify. Apollo's own guarantee steps back at 6 months; people change jobs in the meantime
Verified, catch-all	Send in a separate, smaller campaign and watch bounces (see below)
Unverified, user managed, or update required	Re-verify, or enrich in Apollo first
Any status, on a role address (info@, sales@)	Decide deliberately; see role-based addresses

The 3 to 6 month line is a judgement, not a published standard. Apollo draws its own line at 6 months for its guarantee; how much to tighten that depends on how fast your target market changes jobs.

Catch-all rows: where Apollo and a third-party verifier disagree

On a catch-all domain, an SMTP verifier cannot confirm a mailbox, and an honest one will say so. That includes ours. A catch-all server answers "yes" to every address, real or invented, so the conversation that verification relies on proves nothing. Our explainer on catch-all domains shows why.

Apollo's position is that it can tell real from fake on these domains, because "Apollo knows whether an email sent out any traffic in the past thanks to millions of linked mailboxes in our network." It says this is why third-party tools "flag valid, Apollo-verified emails as unverifiable because they belong to a catch-all domain."

Both statements can be true at once. A third-party verifier is answering "can the mail server confirm this mailbox?", and on a catch-all the answer is genuinely no. Apollo is answering "does our network data suggest this address is in use?", which is a different kind of evidence that no outside party can check. If a verifier returns risky for an Apollo catch-all row, it is not contradicting Apollo. It is telling you that the only evidence for that address is Apollo's.

What to do with those rows:

1. Put them in their own campaign, not mixed with confirmed addresses.
2. Send a small first batch and look at the bounce rate before sending the rest.
3. If that batch bounces badly, stop. A bounce lands on your domain whoever supplied the address.

Our decision framework for catch-all addresses goes into batch sizes and thresholds.

Why a credit refund is not the same as protection

Apollo refunds the credit for a verified email that bounces within 30 days. It cannot refund the reputation cost. Mailbox providers track bounces against the sending domain and IP, not against the data vendor. Apollo says the same thing in its own words: "When an email hard bounces, it can damage your email domain reputation."

Two other details from Apollo's bounce guide matter if you send from Apollo itself:

• After a hard bounce, Apollo "automatically removes the email address from contacts to prevent further outreach", but if you import the same address again from a CSV or CRM, "you can still email them".
• A sequence can be auto-paused for bounces, and resuming it requires at least one cleanup action such as enriching contacts or removing bounced ones.

If you export to another sending tool, none of Apollo's suppression travels with the CSV. Instantly, Smartlead and lemlist each have their own bounce handling, with very different thresholds; see keeping your Instantly bounce rate under control and preparing a lead list for Smartlead.

How to run the re-check

1. Export with the five fields above, plus name and company so you can join results back.
2. Split the file into "send as is" and "re-check" using the decision table.
3. Deduplicate the re-check file on a lower-cased copy of the email column.
4. Verify it. Keep valid, drop invalid, and move risky into the catch-all campaign.
5. Note the date you verified on each row. The result describes the list on that day, not a month later.

If you want to see what an independent check says about a handful of rows before committing, the free verifier does single addresses with no signup.

The takeaway

Apollo's own help centre gives you the reasons to re-verify: a 91% accuracy figure that it frames as a 9% bounce rate, a 2% bounce rate it calls acceptable, and a guarantee that weakens after 6 months. Send fresh Verified, non-catch-all rows as they are. Re-check anything unverified, user managed, flagged for update, or old. Treat catch-all rows as unconfirmed by anyone but Apollo, and test them in small batches, because whoever supplied the address, the bounce counts against your domain.