Apollo Email Verifier: Pre-Send Cleaning for Outbound Lists

Apollo.io is one of the most widely used prospecting platforms in outbound sales — a combination of contact database, sequencing tool, and intent data. For cold outreach teams, it is often the first stop: find contacts, build a list, export to a sequence tool or run the campaign directly inside Apollo.

Apollo does include email verification features. But they are widely considered one of the weaker parts of the platform — a common complaint in sales communities is that Apollo exports have higher bounce rates than expected, and that the platform's "verified" label does not always match real-world deliverability.

The gap matters at scale. If you are exporting 500 contacts per week from Apollo, a 6% bounce rate means 30 bounces per week. Across a sending domain, that accumulates quickly into a reputation problem.

External verification before the list enters a sender is the fix — and it does not require changing your Apollo workflow.

Why Apollo's verification has limits

Apollo's database is large and regularly refreshed, but it faces the same challenges any large contact database does:

Data staleness — email addresses are verified at the time of data ingestion, not at the time of your export. An address that was valid 8 months ago when Apollo last touched it may belong to someone who has since changed companies, been laid off, or had their mailbox deleted.

M365 false positives — Apollo's verification includes SMTP-level checking, but many users report that M365 addresses pass Apollo's checks and still bounce on send. This is the EOP accept-everything problem described below. It is difficult to solve without the specific M365 HTTP cascade that uses Microsoft's own APIs.

Catch-all coverage — Apollo marks catch-all domains in a way that informs you the domain accepts all RCPT TO. But the individual address confidence on catch-all domains is limited, and the treatment varies across Apollo's UI.

Limited evidence — Apollo gives you a verified/unverified flag or a confidence rating. It does not give you the SMTP response code, the MX records consulted, or the M365 cascade result. When an address bounces after being marked verified, you have no visibility into why.

None of this means Apollo's data is bad. It means that for cold outreach — where bounce rates have direct consequences for sending infrastructure — adding a pre-send verification step is worthwhile insurance.

What a proper pre-send verification covers

Syntax and domain checks

Catches obvious problems: malformed addresses, domains with no MX records, known typos. Table stakes.

SMTP mailbox probing

MailCull opens a direct connection to the receiving mail server and issues RCPT TO for each specific address. The server's response is the ground truth:

• 250 OK — the mailbox accepts mail today. Deliverable.
• 550 5.1.1 User unknown — does not exist. Hard bounce waiting to happen.
• 4xx temporary deferral — inconclusive. Greylisting or rate-limiting.

The SMTP probe uses a properly configured sending identity — EHLO hostname with matching PTR and A records. This matters because servers increasingly filter verification probes from unconfigured senders, which is why some cheap tools get blocked before they can probe anything.

Microsoft 365 HTTP enumeration — the Apollo-specific critical layer

Apollo's contact database skews heavily toward B2B — and B2B contacts skew heavily toward M365 tenants. This is where the most significant verification gap exists.

Microsoft's Exchange Online Protection accepts RCPT TO for any address on an M365 tenant, regardless of whether the mailbox is real. Apollo's SMTP verification — and most standard verifiers — sees a 250 OK and marks the address as verified. The address hard-bounces when actually sent.

This is not an Apollo bug. It is an M365 infrastructure behaviour that requires a separate verification method to work around.

MailCull's HTTP cascade uses Microsoft's authentication APIs directly:

1. GetUserRealm — confirms the domain routes to M365
2. GetCredentialType — checks whether that specific username has an active M365 account
3. Autodiscover v1 — cross-references account presence

When the cascade confirms an active account, the address is marked deliverable with high confidence. When the cascade says no active account but SMTP returned 250 OK, the address is marked risky with m365_smtp_disagreed — an Apollo "verified" address that will actually hard-bounce.

For typical Apollo B2B exports, 10-20% of addresses may be on M365 tenants where the cascade catches false positives that SMTP alone misses. That range varies significantly by industry — SaaS companies and enterprises are more heavily M365; agencies and startups vary.

Catch-all detection

Apollo identifies catch-all domains in its own platform, but MailCull's catch-all detection provides a second signal and gives you a clear risky classification with a specific reason code rather than a passive flag.

Role address detection

Apollo sometimes surfaces role addresses ([email protected], [email protected]) when a direct contact could not be found. These addresses may be technically deliverable but are bad choices for personalised cold outreach — they reach shared inboxes and generate higher spam complaint rates.

The workflow: Apollo + MailCull

Step 1: build and export from Apollo

Build your prospect list in Apollo as normal. Use filters, intent data, saved searches — whatever your workflow is.

Export as CSV. Include all the fields you need for personalisation: first name, last name, company, title, LinkedIn URL, any custom fields.

Step 2: verify in MailCull

Upload the CSV to Verify List. Full check stack: syntax, MX, typo, disposable/role, SMTP probe, M365 HTTP cascade, catch-all detection.

Free: 1,000 rows/month (no credit card) Pro: 100,000 rows/month at $9/month Scale: 500,000 rows/month at $49/month

Step 3: interpret the results

Deliverable — these passed all checks including the M365 cascade where applicable. Load into your sender.

Undeliverable — SMTP confirmed the mailbox does not exist, or the domain has no MX records. Remove.

Risky — the specific reason tells you what to do:

Unknown — the server gave no conclusive answer. Include conservatively or remove for high-stakes sends.

Step 4: export and import to your sender

Export the clean segment from MailCull (preserving all Apollo columns), then load into Smartlead, Instantly, lemlist, Apollo's own sequences, or wherever the campaign runs.

What bounce rates to expect

Industry context:

The gap between verified and unverified is widest for lists with high M365 concentrations — where Apollo's own verification systematically overcounts deliverability.

These ranges are indicative. Your actual numbers depend on the industries, company sizes, and geographies you are targeting.

Apollo API users

If you are pulling contacts from Apollo's API rather than using the UI export, the same verification workflow applies. The API returns contacts with Apollo's own verification status. Run those contacts through MailCull's API before loading them into any sending sequence.

MailCull's API returns structured JSON for each address including status, reason, confidence, and the full evidence chain. For API-driven workflows, you can build verification into the pipeline directly rather than as a manual export-verify-reimport step.

---

You came here because Apollo exports have a real bounce-rate problem and you want to fix it before it damages your sending infrastructure. MailCull catches the M365 false positives that Apollo's verification misses and gives you the SMTP evidence to prove why each address got its verdict.

Verify your Apollo export in MailCull — free up to 1,000 rows →