Repair, Exclude, or Re-Source: The Lead List QA Triage Decision Tree

A dirty lead list is not one problem. It is a collection of different problems wearing the same CSV.

One address has a typo. Another belongs to the wrong person. A third is a catch-all. A fourth is valid but suppressed because the contact already replied. A fifth produced an API timeout. If all five go into a column called bad, you lose recoverable leads, hide source-quality problems, and make the next campaign harder to audit.

Start with identity before email

The first question is not whether the email is valid. It is whether the row represents the right person at the right company for the approved ICP.

Check the person name, current role, company, company domain, geography, seniority, and any negative-ICP rule. If the person left the company, the work email may still verify for a period. If the company is wrong, a perfectly valid mailbox is still a bad lead.

1. identity_match
2. icp_match
3. suppression_clear
4. email_classification
5. source_freshness
6. copy_fit
7. destination_state

This order prevents expensive repair work on a row that should have been excluded for relevance at the beginning.

Repair when the lead is right and the correction is provable

Repair is appropriate when a narrow field is wrong and an authoritative source supports the replacement. Common examples include:

• a misspelled company domain corrected from the company's current website
• a malformed email caused by whitespace or an obvious export artifact
• a stale title corrected from a current company team page or profile
• a first and last name split incorrectly during CSV parsing
• a valid source email placed in the wrong column during mapping

A repair creates a new candidate. It does not inherit the old row's verification result. Re-run domain, mailbox, suppression, dedupe, and copy checks because changing one identity field can change every downstream decision.

Retry when the evidence is temporary, not absent

Unknown and API-error results are not synonyms for invalid. ZeroBounce documents unknown outcomes such as timeouts, temporary mail-server errors, greylisting, and failed SMTP connections. MillionVerifier classifies Unknown as Risky because it cannot determine whether the mailbox exists.

Use a bounded retry policy:

1. Preserve the provider, raw status, reason, timestamp, and attempt count.
2. Wait for a defined cooldown instead of retrying immediately.
3. Retry with the same verifier or an approved second source.
4. Stop after the maximum attempts or age limit.
5. Route the unresolved row to re-source or exclude.

Do not keep an infinite retry queue. The point of retry is to resolve a temporary condition, not to avoid making a decision.

Re-source when the person is valuable but the email is not

Re-sourcing makes sense when the ICP evidence is strong and the current contact path is blank, invalid, stale, or too uncertain.

Use the company domain, current role, person identity, and source date to find a replacement through a different approved source. The replacement can be another verified address for the same person or, when the person has left, another relevant contact at the account. Preserve the relationship between the original row and its replacement so the system does not count both as independent leads.

Do not guess an address pattern and label it verified. A guessed mailbox is a candidate that still needs verification and suppression checks.

Exclude when the risk or mismatch is real

Exclusion should be decisive and explainable. Typical reasons include:

Catch-all needs a policy, not a coin flip

Catch-all domains accept mail for addresses that may or may not belong to real people. Regular verification cannot always resolve the mailbox itself. That is why reputable tools keep catch-all separate from confirmed valid.

Reddit operator discussions show two recurring approaches: exclude catch-all entirely or place it in an isolated, lower-volume test with close bounce monitoring. Those discussions are community anecdotes, and several contain vendor promotion or unverified thresholds. They are useful for identifying the decision practitioners face, not for proving a universal sending rule.

Ink Persuasion's default is simpler: catch-all does not enter the main valid-only campaign. A client can approve a separate experiment, but the cohort, sender pool, volume, and stop conditions remain isolated.

Duplicate is a state, not a deletion command

Quora's own CSV contact importer says it skips invalid and duplicate email addresses. Instantly offers a workspace-level duplicate check during lead import. Those behaviors show why the receiving platform matters, but neither one replaces your reconciliation ledger.

A duplicate can mean several things:

• the same email appears twice in the current file
• the same contact exists in another campaign
• two contacts share a role mailbox
• the same person appears with two addresses
• two people at one account conflict with an account-level rule
• a previous reply or customer record should suppress the new row

Record the duplicate type, kept row, excluded row, and governing policy. Deleting the second row without that information can hide an account-routing conflict.

Use reason codes that survive vendor changes

Keep the vendor's raw response, then map it into your own stable reason codes. This lets you switch providers without rewriting historical decisions.

lead_id
raw_source
raw_email
verifier
verifier_status
verifier_reason
qa_reason_code
disposition
replacement_lead_id
attempt_count
evidence_reference
reviewed_at
reviewed_by

Useful internal reason codes include EMAIL_INVALID, EMAIL_UNVERIFIABLE, CATCH_ALL_QUARANTINE, API_RETRY, BLANK_EMAIL, DUPLICATE_WORKSPACE, SUPPRESSED_REPLY, WRONG_ICP, SOURCE_CONFLICT, and RE_SOURCE_REQUIRED.

Set a repair budget before the file arrives

Not every recoverable lead is worth recovering. Define the maximum research time, paid lookup cost, verifier attempts, and number of alternate sources per row.

Use more effort for high-value, high-confidence accounts. Use less for marginal fits. Once the budget is exhausted, choose re-source or exclude. A list-cleaning project should not become an open-ended research project because the system refuses to close a row.

A first-party list shows the cost of a vague review bucket

In one anonymized Ink Persuasion run, 8,036 rows reached mailbox classification. The result was 4,745 valid, 2,744 unverifiable, 369 invalid, 13 API errors, and 165 blank-email rows.

If every non-valid row had gone into one review bucket, 3,291 rows would have lacked a defined next action. Splitting them by reason created a usable operating plan: invalid rows were excluded, API errors were retained for retry, blank rows required repair or re-sourcing, and unverifiable rows stayed outside verified delivery.

The article on the two-gate email verification workflow explains the upstream security-provider and mailbox gates. The campaign import gate explains how the valid-only candidate file becomes a verified destination list.

Frequently asked questions

Should I delete invalid emails from the source file?

No. Keep the original source immutable and write the invalid result to a disposition ledger or classified output. Deleting the row destroys your ability to reconcile counts, measure source quality, and avoid buying the same bad lead again.

Can an unverifiable email be repaired?

Sometimes. Retry temporary outcomes after a cooldown or use an approved second verifier. If the result remains unresolved, re-source the contact path or exclude it according to policy. Do not convert uncertainty into valid.

When should I re-source a lead instead of repairing it?

Re-source when the person or account fits but the current contact path is blank, stale, invalid, or irreconcilable. Repair is better for a narrow, provable correction to an otherwise trustworthy row.

What should I do with duplicate leads?

Classify the duplicate first. Keep one canonical row, preserve the relationship, and apply workspace, reply, customer, and account-level suppression rules. Then verify the destination skip count.

How long should a lead stay in review?

Use a defined attempt limit and maximum age for each reason code. A review queue without deadlines is not a triage system. It is deferred ambiguity.

Research note

The related AnswerThePublic English and United States report for cold email lead list returned no usable volume or CPC and one Google related result. It informed the buyer questions around list quality and verification; no unavailable demand data was inferred.

Quora research was attempted for catch-all handling, invalid-email cleanup, and duplicate lead imports. Quora's public discussion pages were blocked by robots.txt, so no inaccessible user answer is quoted or presented as reviewed. The accessible official Quora Help article on CSV imports is used only for its documented behavior: invalid and duplicate contacts are skipped. Reddit sources are explicitly treated as community discussion, not authoritative verification guidance.

Sources