Checking one address at a time is fine when you have a handful of contacts to review. It is not how you handle a list of 5,000 or 50,000.
That is where a bulk email verifier makes the difference — and where what the tool actually checks matters more than the fact that it processes things in bulk.
What bulk verification actually means
Bulk verification is a workflow:
- Upload a file containing email addresses
- Run validation across every extracted address
- Review the grouped results by status
- Export the cleaner subset you want to keep
The word "bulk" is the easy part. What separates good tools from mediocre ones is the quality of the verification that runs across each address in that list.
The check layers that matter
Email verification tools differ significantly in how deep they go. Here is what the layers look like, from surface to deep:
Syntax and format
The fastest check. Does the address parse as a structurally valid email? This catches obvious garbage like missing @ signs, double dots, or invalid characters. Every tool does this. It eliminates the clearly broken addresses but tells you nothing about whether the mailbox actually exists.
Domain and MX records
Does the domain exist? Does it have MX records configured to receive mail? If a domain has no MX records, no mail can be delivered there, regardless of what the mailbox name is. This is a reliable negative signal — MX failure means undeliverable — but passing MX records only confirms the domain is set up, not that any specific mailbox is real.
Typo and disposable detection
This catches addresses that look plausible but probably are not. gmial.com instead of gmail.com. A Mailinator or Guerrilla Mail domain. A role address like info@ or noreply@ that exists but serves no individual. These checks have high precision when the pattern lists are well-maintained.
SMTP mailbox verification
This is where the real signal lives. The verifier opens a connection to the mail server, identifies itself with EHLO, presents a MAIL FROM, and then issues RCPT TO for the specific address being checked. The server's response — a 250 accept, a 550 user-unknown, a 450 try-later — tells you directly whether that mailbox exists at the protocol level.
This is not guessing. It is the same handshake a real sending mail server would perform. The difference is the verifier stops before DATA, so no email actually gets sent.
MailCull's deep-scan engine does this for every address. The SMTP client is custom-built: it negotiates EHLO, performs an opportunistic STARTTLS upgrade when the server supports it, and handles the full response parse — including ambiguous replies like greylisting (temporary 4xx) and policy blocks (permanent 5xx that are not the same as user-unknown).
Microsoft 365 HTTP enumeration
M365 tenants are a special case. Microsoft's EOP layer is notorious for accepting RCPT TO for any address on a tenant — even addresses that do not exist — and routing the bounce internally. This makes raw SMTP probing unreliable for M365 mailboxes.
MailCull handles this with an HTTP cascade that runs before SMTP:
- GetUserRealm — confirms whether the domain routes to M365
- GetCredentialType — checks whether that specific username has a live account
- Autodiscover v1 — cross-references account existence
When the cascade returns deliverable and SMTP confirms it, confidence is high. When the cascade returns deliverable but SMTP disagrees (as happens with some EOP rate-limiting situations), MailCull flags the result as risky with a m365_smtp_disagreed reason rather than committing to either verdict — which is the honest answer.
What MailCull returns for each address
Every address in a bulk job comes back with a status from the frozen four-value vocabulary:
- Deliverable — the mailbox accepted the probe and no contrary signals overrode it
- Risky — technically present but with signals that suggest caution (role address, catch-all tenant, M365 cross-check disagreement, greylisting)
- Undeliverable — SMTP confirmed the mailbox does not exist (hard 5xx), or the domain has no valid MX records
- Unknown — the server did not give a conclusive answer (timed out, refused the probe, policy-blocked without specifics)
Along with the status, each address carries an evidence chain: the specific signals that drove the verdict. For a bulk job, you see the breakdown by status bucket. For Pro and Scale users, you can drill into each address and read the individual evidence.
The Verify List workflow in MailCull
MailCull's Verify List feature is built for CSV-based bulk processing:
- Upload your CSV — any column layout, any delimiter. You do not need a clean single-column file.
- MailCull extracts every email address it finds across all columns.
- The validation engine runs syntax, domain/MX, typo, disposable, SMTP, and (for M365 domains) the HTTP cascade.
- Results group into the four statuses. You see a summary breakdown immediately.
- Export the cleaner subset: deliverable-only, or deliverable plus a conservative risky cut, depending on how much risk your use case tolerates.
The export step is straightforward: choose your status filters, click export, get a clean CSV back. No manual spreadsheet work required.
What to look for in any bulk verifier
If you are evaluating tools, these are the questions worth asking:
Does it actually do SMTP verification, or just domain/MX checks? Domain/MX checks alone will miss a large share of bad addresses on domains that have valid MX records but no real mailboxes (or tens of thousands of abandoned ones).
How does it handle Microsoft 365 domains? M365 is a large fraction of business email. If the tool cannot distinguish real M365 mailboxes from non-existent ones, its results for B2B lists will be unreliable.
What does the status vocabulary mean, exactly? A tool that returns a "score" without explaining what drove it is harder to act on than one that tells you the specific signal.
Can it handle messy files? Real export files from CRMs, prospecting tools, and spreadsheets are not clean. A tool that requires a pristine single-column CSV creates extra prep work before every verification run.
What happens to your data? Worth understanding whether the service stores your contact list, for how long, and under what policy.
How the free plan works
MailCull's Free plan includes 1,000 list-verification rows per month at the quick-scan tier (syntax, MX, typo, disposable) and 100 deep-scan single checks. There are no credits to buy, no credit card required to get started, and the plan does not expire.
The Pro plan ($19/month) raises the limits to 100,000 list-verification rows per month and 5,000 deep-scan single checks. The Scale plan ($49/month) extends those to 500,000 rows and 25,000 deep-scan single checks.
For teams running regular bulk verification on prospect lists or marketing databases, the free row limit is enough to develop a workflow before deciding whether a paid plan fits the volume.
When bulk verification actually helps
The teams that benefit most from a regular bulk-verification habit are:
Cold outreach teams working from prospect data sourced across multiple tools. Purchased lists, Clay enrichments, LinkedIn exports — all of these mix stale addresses in with good ones. Running verification before loading into a sender removes the low-quality rows before they damage domain reputation.
Newsletter and marketing operators cleaning older segments. Even opt-in lists decay at roughly 2% per month from churn, domain changes, and abandoned accounts. A quarterly verification run is much cheaper than recovering from a deliverability penalty.
Agencies and RevOps teams managing multiple clients or data sources. A consistent verification step before any list import reduces the risk that a bad client file degrades shared sending infrastructure.
Migration scenarios — importing from a legacy CRM, merging two databases, or switching ESPs. These are exactly the moments when stale and duplicate data surface.
The consistent theme: list verification is not a one-time event. It is maintenance. The tools and workflows that make it cheap and repeatable are the ones that actually get used.
---
Upload your next CSV to MailCull and run a bulk verification →