ZapBounce

ZapBounce and Apollo

ZapBounce gives an Apollo export a live check on the day you plan to send. You upload the CSV on the bulk page, call the ZapBounce API from the script that pulls your leads, or add a Zapier step for each new contact. Every row comes back valid, invalid, catch_all or unknown, beside your original Apollo columns.

Apollo shows an email status next to each contact, such as verified. That status describes Apollo's records as of its own last check. A live handshake with the mail server describes the mailbox this morning, and the gap between the two dates is where bounces come from.

A database label ages while the mailbox changes

People change jobs, and companies close mailboxes when they leave. A status set months ago doesn't change on the day that happens, so an export can carry dead addresses under a clean label.

Addresses built from a company's naming pattern are the other risk. They're often right, but a pattern applied to a name is still a guess until a server confirms it.

Those guesses cluster on corporate domains, where catch-all servers are common. ZapBounce labels those rows catch_all, so you can see how much of a list no server will confirm before you commit a mailbox to it.

How the data moves

  1. Export from Apollo with the email status column

    Keep Apollo's status in the export. It comes back untouched beside the ZapBounce result, so you can compare the two on every row.

  2. Verify the whole file in one job

    Upload the CSV, or send the addresses to POST /v1/jobs. An address that appears twice costs one credit, and rows that come back unknown cost nothing.

  3. Compare Apollo's status with the live result

    Count invalid results per Apollo status. That number tells you how far to trust each status in future exports.

  4. Route each result to the right play

    Valid rows go to your email sequence. Catch_all and unknown rows go to a calling or LinkedIn step, where a bounce can't touch your domain.

Setting it up

  1. Export the Apollo list as CSV, including the email status column.
  2. Upload it to ZapBounce and poll the job status endpoint until it completes.
  3. Download the results: the status, reason code and SMTP code for every address, matched back to your columns on email.
  4. Compare invalid rates by Apollo status and note them for your next export.
  5. Sequence only addresses that came back valid, whatever the status said.
  6. Route catch_all and unknown rows to a phone or social step, and re-check the unknowns in two weeks.

Apollo: common questions

What is the best email verifier for a list from Apollo or ZoomInfo?

Use one that runs a live SMTP check and bills only answers it got from a server. ZapBounce does both, returns catch_all apart from unknown, and charges $25 for 10,000 checks with credits that never expire.

Is Apollo's verified status enough before a sequence?

Treat it as a starting point. The status reflects Apollo's last check, and a live ZapBounce check on the day you send tells you about the mailbox now.

Should I verify pattern-guessed addresses or drop them?

Verify them. Many pattern guesses are correct, and dropping them throws away real prospects along with the dead ones.

Why do Apollo addresses come back catch-all so often?

They cluster on corporate domains, and many corporate mail servers accept every address to stop harvesting. ZapBounce labels those rows catch_all and bills them once.

Reference

Check a Apollo export today

100 free checks a month, no card. Unknown results are refunded.

Get an API keySee pricing