A technically valid mailbox can still belong to the wrong person, sit behind a catch-all domain, appear on a suppression list, or generate a complaint. Verification is one technical gate; consent, policy compliance, suppression, and relevance require separate checks.
A file can come back almost entirely valid and still be unfit for a campaign. The verifier reports technical classifications; it does not check whether each person still holds the role, previously opted out, or has a credible reason to receive the offer.
The failure happens when the valid rate becomes launch approval. The whole file is imported into campaign software before anyone checks source age, current ownership, suppression history, or fit. When bounces, negative replies, or complaints follow, the verifier gets blamed for decisions it was never designed to make.
Verification is useful. Depending on the receiving server and method, it can identify malformed addresses, missing mail systems, mailboxes that return a clear nonexistent-user response, and several known risk categories. It does not establish that the data is fresh, that the person still holds the role, that the account belongs to the intended person, or that the message is relevant.
An email verification service runs automated checks to estimate whether an address can receive mail. It checks the format, whether the domain has a working mail system, what the receiving server reports about the mailbox, and whether the address matches known risk patterns.
Vendors use different labels and methods. As one current example, ZeroBounce separates results into Valid, Invalid, Catch-All, Spamtrap, Abuse, Do Not Mail, and Unknown. Its own validation documentation warns that catch-all domains accept mail for addresses that may not exist and that some results should be segmented or withheld rather than treated as ordinary valid contacts.
A valid result is therefore narrow: the service found enough signals to place the address in its valid category at the time of the check. That vendor-specific classification is not proof of inbox acceptance, future delivery, human ownership, relevance, consent, or a positive response.
Mail systems also change. People leave companies. Aliases are removed. Mailboxes fill up. Domains move between providers. Security systems defer or block verification probes. Any status is a dated observation, not a permanent property of the address.
A catch-all domain can accept mail sent to any local part, including a name that does not correspond to a real employee. That behavior prevents a verifier from confirming the individual mailbox in the same way it can at a domain that rejects nonexistent users.
Some catch-all messages reach the intended person. Others go to a general mailbox, disappear into an unmonitored account, or bounce after the accepting server applies later checks. ZeroBounce's catch-all guidance describes multiple possible outcomes and recommends separating catch-all records from the ordinary valid segment.
Keep catch-all records in a separate group. Require stronger evidence that the person and role are current, and decide before sending how much evidence will be observed and what result will stop the test. Use the sender's existing baseline and risk policy rather than inventing a universal number.
Identity and relevance errors can be more costly than SMTP errors because they can create complaints without creating a bounce.
An address can pass verification after its former owner has left because the company reassigned it or kept it as an alias. A generated address can resolve to a catch-all even though the assumed naming pattern is wrong. A role mailbox such as sales@ or operations@ can accept mail while being a poor destination for a message written to a specific executive.
Even a correctly owned mailbox may be wrong for the campaign. The company may be outside the target market, the recipient may not control the problem, or the source data may describe a role from two years ago. None of those failures necessarily produces a bounce. They produce silence, negative replies, or complaints.
This is why enrichment and verification cannot replace a business-relevance review. The send/no-send decision needs evidence about the person, company, role, source, collection date, and reason the offer fits now.
A suppression list is the sender's internal do-not-contact history. A newly verified list can still contain people who opted out, complained, bounced permanently, or asked not to be contacted in another campaign or workspace within the applicable organizational or client scope.
Verification services do not know every relationship a sender has with an address. The suppression list is the internal record that supplies that history. Apply suppressions across every campaign, workspace, domain, and tool operated by the same sender or legal entity. Keep unrelated client data isolated unless a documented platform-wide safety policy and lawful data-handling basis require a broader block.
Run suppression before launch and again after the final merge. Normalize casing and whitespace, deduplicate exact normalized addresses, and merge known aliases only when your own systems or a verified source establishes the relationship. Apply organization-wide suppression where policy and lawful data handling permit, and keep client-specific records segregated where required. Preserve the authoritative source, reason, and date for every suppression. A tool migration is not permission to forget an earlier opt-out.
Recipient reactions are not merely tuning metrics. Complaints, opt-outs, and negative replies are evidence that the targeting, message, or contact decision may need to change. Receivers also evaluate what happens after messages reach their users. Google's current sender guidelines tell senders to monitor spam rates, bounces, deferrals, authentication, domain reputation, and recipient feedback. Google says senders should keep Postmaster Tools spam rates below 0.10% and avoid reaching 0.30% or higher. Yahoo's sender best practices likewise require low complaint rates and tell bulk senders to stay below 0.3%.
Google and Yahoo complaint thresholds are enforcement boundaries, not campaign-quality targets. Review complaints, opt-outs, negative replies, useful replies, and conversion by source alongside bounce rate. A campaign can remain below the thresholds and still be irrelevant, unwanted, or inconsistent with the sender's obligations. A low bounce rate only shows that one failure class remained low.
The first stage is technical. Normalize and deduplicate the file, apply the applicable suppression list, verify the remaining addresses, and preserve the verifier's original status and substatus fields. For ZeroBounce, for example, statuses such as Valid, Invalid, Catch-All, Spamtrap, Abuse, Do Not Mail, and Unknown remain distinct from substatus flags such as role-based, disposable, and possible-trap. Do not flatten those fields into one “verified” column.
The second stage is business QA. Confirm the source and collection date, sample the records against current company and role information, test whether the targeting logic matches the offer, and document why each segment belongs in the campaign. Quarantine records whose ownership or relevance cannot be supported.
Then launch by cohort rather than mixing every source together. Start with the segments that have the strongest evidence. Before sending, record the minimum observation window and the bounce, complaint, negative-reply, or relevance signals that will trigger a pause. Those rules should be based on the sender's baseline and receiver requirements, not invented after results arrive. Watch each source and verification class separately so a weak cohort can be paused without losing the signal from a stronger one.
Before any list goes live, the operator must also confirm that the campaign fits applicable legal, contractual, and platform rules, honors prior opt-outs, identifies the sender accurately, and provides the required way to stop future contact. This article is operational guidance, not legal advice.
An operator should be able to answer seven questions:
Treat the verification result as a dated technical classification. Do not launch the record until its ownership, relevance, suppression history, source, and applicable sending rules have also been checked.
Size domains and density to your sending target and see the capacity that holds.
Build My Sending Plan