The Two-Gate Email Verification Workflow

An email verifier can say a mailbox exists while your campaign still should not send to it.

The recipient may sit behind a security gateway that your team has decided to exclude. The verifier may return catch-all, unknown, mailbox blocked, or a temporary error. Or the address may be valid but belong to a generic role account that the campaign forbids.

One green column is not a complete release decision.

Gate one: classify the recipient mail infrastructure

Extract the domain from the recipient email, query its MX records, and compare the hostnames with a maintained provider signature set. Provider columns from your source can be supporting evidence, but the recipient domain is the object being checked.

Our in-house detector now identifies maintained signatures for Mimecast, Barracuda, Proofpoint, Cisco Secure Email, Forcepoint, Hornetsecurity, Trend Micro, Sophos, FortiMail, and Check Point Avanan. It also recognizes ordinary mailbox providers such as Google Workspace and Microsoft 365 without excluding them.

This is a house risk policy, not a claim that every address behind those gateways is invalid. The important engineering property is that the policy is explicit, versioned, testable, and reversible.

recipient_domain
security_provider
provider_category
policy_version
action: keep | exclude | review
evidence
mx_hosts
dns_error
checked_at

Gate two: verify the mailbox

Run only gate-one keep rows through a mailbox verifier. Do not spend verification credits on rows your security-provider policy already excludes.

MailTester Ninja's API returns ok for valid, ko for invalid, and mb for unverifiable. Its message field can add context such as catch-all, timeout, spam block, or MX error.

Other tools use different labels:

• ZeroBounce: valid, invalid, catch-all, unknown, spamtrap, abuse, and do-not-mail, with detailed sub-statuses.
• MillionVerifier: Ok, Invalid, Disposable, Catch-All, and Unknown. Its own guidance labels catch-all and unknown as risky for purchased or scraped outreach lists.
• OmniVerifier: standard and catch-all verification, with unknown credits described as refundable in its current terms.

The workflow is tool-agnostic. Map every provider's raw result into your own release categories.

Do not call risky results valid

A first-party dual-gate run

We applied this structure to an anonymized Australia and New Zealand cybersecurity list with 8,465 source rows.

The provider stage removed 429 rows and left 8,036 survivors. It also held 216 rows for review and found 165 missing or malformed domains while checking 4,831 unique domains.

At a later mailbox-verification checkpoint, the verifier had returned 1,166 valid, 656 mailbox-unverifiable, and 73 invalid results. Temporary rate-limit outcomes were quarantined and retried rather than counted as failed emails.

The first delivery contained only 1,000 rows that passed both gates. This is first-party operating evidence, not a universal benchmark for list yield.

Why two verifiers may disagree

Email verification is a point-in-time observation of DNS and receiving-server behavior. Catch-all configuration, greylisting, temporary disconnects, anti-spam systems, and provider-specific models can produce different labels.

Do not resolve a disagreement by choosing the more optimistic result automatically. Use a declared arbitration rule:

1. Keep the raw response from each verifier.
2. Normalize the statuses without erasing detail.
3. Require the approved safe result for the primary verifier.
4. Route disagreement, catch-all, unknown, and temporary outcomes to review or retry.
5. Record the final policy decision separately from vendor output.

Use one release equation

send_ready =
  security_provider_action == "keep"
  AND mailbox_verification_status == "safe"
  AND generic_inbox == false
  AND icp_status == "approved"
  AND suppression_status == "clear"

The ICP and suppression checks matter because deliverability is not the same as relevance or permission. A technically valid email can still be the wrong person, a competitor, an existing customer, or someone who previously opted out.

Make the workflow resumable

At scale, interruptions are normal. DNS lookups fail. Verifier APIs rate-limit. A worker stops midway through a file.

Use one checkpoint record per email and never call the same paid verifier again when a final result already exists. Cache domain-level provider decisions so 500 leads at one company do not trigger 500 DNS lookups. Keep temporary outcomes eligible for retry, with a cooldown and attempt count.

For broader file governance, pair this with the lead-list reconciliation test so every excluded, reviewed, and released row closes against the source total.

Frequently asked questions

Is one email verifier enough for cold outreach?

One strong mailbox verifier can be enough for gate two, but mailbox verification does not replace recipient-security-provider classification, ICP QA, or suppression checks.

Should I send to catch-all emails?

For cold outreach, treat catch-all as risky rather than safe by default. If you test it at all, isolate it from the confirmed-valid cohort and use a separate policy.

What does MailTester Ninja mb mean?

Its API documentation defines mb as unverifiable. Keep it out of the send-ready file and place it in review or a later retry queue.

Was "Medium Verifier" the product name?

I could not verify a current email-verification vendor by that exact name. MillionVerifier may be the intended product, but confirm the vendor before buying credits. The workflow does not depend on one provider; keep the provider's raw status and normalize it into your own policy.

Does detecting Proofpoint or Mimecast mean the mailbox is invalid?

No. It means the domain uses a recognized mail-security gateway. Exclusion is an explicit campaign risk policy, not a mailbox-existence verdict.

AnswerThePublic research note

The August 12, 2026 English, United States report for cold email lead list also supported this article. It returned no usable volume or CPC and one Google related result. Its AI prompts included how to verify list quality and where to find verified leads. Those questions informed the two-gate framework; no unavailable keyword data was invented.

Sources