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.

Verification is still not the final release step. The cold email campaign import gate covers valid-only filtering, catch-all quarantine, field mapping, workspace duplicate suppression, copy-fit checks, and destination reconciliation.

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

See the workflow's decisions in our email list cleaning case study: 8,252 source rows to 5,602 usable leads. It shows why mailbox validity, recipient security infrastructure, review states, and duplicate removal need separate records.

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.

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.

Test the release decision with four example rows

Before running a whole list, write down the expected decision for a small fixture. These are illustrative cases, not additional client results:

• Provider allowed, mailbox valid: advance to ICP, suppression, and copy checks. Do not label it ready to send before those checks finish.
• Provider excluded, mailbox valid: exclude under the campaign's infrastructure policy. Preserve the valid result; do not rewrite it as an invalid mailbox.
• Provider allowed, mailbox unknown: hold for review or a bounded retry. A successful API response is not the same as a conclusive mailbox result.
• Provider lookup failed, mailbox valid: hold the row because gate one is unresolved. Verification does not fill in missing provider evidence.

Each record needs a stable lead ID, the raw observations, a separate final decision, and the policy version. That lets a reviewer explain a removal without rerunning a paid check or guessing what a green spreadsheet cell meant.

When a policy changes, reevaluate the stored evidence and record the new decision. Keep the previous decision available for audit. If the evidence is too old for the campaign's declared freshness window, refresh it rather than treating a historical valid result as permanent.

Sources