Why Verified Emails Still Bounce and How “Cleaning” Can Make Your List Worse

You verify a list. Remove the invalid addresses. Upload the remaining contacts into your sending platform.

Then the bounces arrive.

The natural conclusion is that your verification tool missed something. Sometimes it did. But that conclusion can also send you toward the wrong repair: paying to verify the same addresses again, deleting contacts whose mailboxes still exist, or replacing a list while the original sending problem remains.

The more useful question is:

What evidence would distinguish a bad address from a failed attempt to reach it?

That question changes how you investigate a campaign, judge a verification service and maintain your CRM.

Our position at Refresh List is that email cleaning should improve decisions. A smaller file is not sufficient proof that it did.

A bounce belongs to an event before it belongs to a contact

Imagine a customer who has successfully received your invoices for two years.

Today, a new sending service attempts to deliver an invoice. The recipient’s server refuses it because the sender fails an authentication requirement.

Has the customer’s email address become invalid?

The failed delivery alone cannot establish that.

Google’s error documentation explicitly includes authentication-related rejections under 5.7.26. Microsoft explains that 5.7.1 can arise from security restrictions, group permissions, relay permissions or routing problems. These failures require different investigations from a nonexistent mailbox. Google’s SMTP error reference, Microsoft’s delivery-error guidance

The dangerous step happens afterward: a system takes the event “this message could not be delivered” and turns it into the contact attribute “this email address is invalid.”

That is an inference. Sometimes it is justified; sometimes the evidence is insufficient.

Our editorial recommendation is simple: record the failed event first, then decide whether the contact record needs to change.

A campaign outcome should not silently overwrite everything previously known about a customer.

“Valid” is an incomplete sentence

When a verification service returns “valid,” a buyer may read it as:

This person will receive my next email.

That interpretation combines several separate questions:

• Is the address structurally plausible?
• What evidence exists about the destination?
• Will the receiving system accept this particular message from this sender?
• Where will an accepted message be placed?
• Does the intended person still control the address?
• Is contacting that person appropriate?

A useful evaluation asks what the service actually tested, when it tested it, and what its result means.

SMTP itself proceeds through stages. Acceptance of a recipient command is different from acceptance after the complete message has been transmitted. RFC 5321 also describes failures discovered after a server accepts responsibility for a message. Consequently, an observation made during an earlier check cannot establish the outcome of every later delivery stage. SMTP specification, RFC 5321

My interpretation: “valid” should be treated as a dated observation with a defined scope, rather than a permanent property of a contact.

For an operational record, these three fields are much more useful together:

Verification result · Verification time · Meaning of the result

Without the timestamp, you cannot distinguish a fresh disagreement from an old observation. Without the definition, you cannot tell whether two tools claiming different results actually disagree about the same thing.

What a large delivery study found and what it cannot tell you

The 2024 ACM Internet Measurement Conference paper Bounce in the Wild analysed approximately 298 million emails using a 15-month dataset from Coremail, covering June 2022 to September 2023.

The researchers reported that 12.93% failed on the first attempt, with roughly one-third of those subsequently delivered after retries. They also found that 28.79% of the non-delivery report messages they analysed lacked an enhanced status code.

Those findings demonstrate why first-attempt failure and final failure need separate treatment, and why a clean-looking code table cannot explain every real report.

However, this was one provider’s historical dataset, with its own infrastructure and traffic mix. It was not a controlled comparison of commercial email verifiers. Its percentages are not benchmarks for your campaign, and they do not estimate the share of bounces that Refresh List could prevent. Read the original paper (PDF)

That last distinction matters. A large number can make an article persuasive while making the reader’s decision worse if it is applied to the wrong population.

The hidden cost: deleting the evidence you need

Consider a workflow that exports only an email column, verifies it, removes failed contacts and reimports the survivors.

The resulting file may be tidy. But the process may have separated the address from information needed to interpret a problem:

Who supplied the record? Which account owns it? When was it last verified? Did the customer previously receive messages? Which campaign failed? What did the receiving server actually say?

Our argument is that this information belongs beside the result.

If a team repeatedly overwrites one status field (valid, then bounced, then invalid), the latest label conceals the sequence that produced it.

A better record can say:

Verified on Monday. Delivery failed on Wednesday. The receiving system reported an authentication problem. Sending is paused while the configuration is investigated.

That description supports a specific action. “Invalid” supports a much broader conclusion than the evidence warrants.

We call the accumulated cost of losing this context diagnostic debt: future work created by storing conclusions without the observations that produced them.

This is a proposed operational concept, not an established industry metric. Its value is practical: it gives teams a reason to preserve the evidence before simplifying the dashboard.

Four separate decisions hiding inside “clean this list”

We recommend answering four questions independently.

This is our suggested working model. It is deliberately more expressive than a single green or red status.

An address can pass a technical check while remaining suppressed. A contact can require investigation without being deleted. A campaign can fail while the underlying customer record remains useful.

The benefit is that one decision no longer silently makes the other three.

A worked example: the same bounce rate, four different jobs

The following numbers are hypothetical. They demonstrate the method; they are not customer results or a predicted distribution.

Suppose a campaign targets 10,000 unique addresses previously marked valid. After the sending platform has finished its delivery process, 300 messages are recorded as failed.

The campaign’s final failure rate is 3%.

After reviewing the available reports, the team assigns provisional categories:

Calling all 300 addresses “bad data” would collapse four different investigations into one label.

The 90 recipient failures warrant a review of verification timing, source quality and the exact mailbox evidence. The 120 authentication failures point toward a configuration investigation. The 60 unresolved temporary cases need their delivery history reviewed. The remaining 30 should stay unresolved until better evidence exists.

Even the first category does not automatically prove that the verifier was wrong at the time of its check. Establishing that would require additional evidence about timing and conditions.

The useful conclusion is narrower:

This campaign produced 90 failures attributed to recipient nonexistence, not 300 proven invalid addresses.

That distinction changes both the next action and the fairness of any vendor comparison.

Measure how much you understand, alongside how much failed

Bounce rate tells you the size of a problem. It does not, by itself, tell you how much of the problem you have explained.

We propose tracking an additional internal measure:

Attribution coverage = failed messages assigned an evidence-supported cause ÷ all final failed messages

In the hypothetical campaign, 270 of 300 failures have an assigned cause. Attribution coverage is therefore 90%.

This is not a verification-accuracy score. It is not a recognised deliverability benchmark. A high value can still be misleading if the classification is poor.

Its purpose is to expose a question that dashboards often leave implicit: how much of the failure count can the team explain well enough to choose an action?

For this measure to remain useful, retain:

• The evidence used for the assignment.
• Whether the assignment was automatic or reviewed.
• The level of uncertainty.
• Any later correction.

A team should be able to improve its explanation without rewriting the original event.

Read the response, not just the first three digits

Enhanced status codes distinguish address problems from other categories. For example, RFC 3463 defines X.1.1 as a bad destination mailbox address, while X.7.1 concerns unauthorised delivery or a refused message. Those categories do not establish the same fact about a recipient. Enhanced status codes, RFC 3463

Our recommended review order is:

1. Identify whether the outcome is an interim attempt or a final result.
2. Read the complete diagnostic text.
3. Identify the system that produced it.
4. Consult that provider’s documentation.
5. Assign the narrowest explanation the evidence supports.
6. Preserve “unresolved” when the report does not justify more.

Do not build confidence by forcing every record into a category.

For example, an unexplained refusal should not become “mailbox nonexistent” merely because your export format requires either valid or invalid. That is a limitation of the format, not a discovery about the address.

The denominator can disguise the problem

Here is another hypothetical example.

Campaign A targets 10,000 addresses and produces 100 final failures. Campaign B targets 10,000 addresses and produces 200.

Their overall failure rates are 1% and 2%. Campaign A initially looks healthier.

But suppose all 100 failures in Campaign A occur among just 200 recipients in one receiving-provider segment. Within that segment, half the targeted messages failed.

That concentration deserves immediate investigation even though the overall number looks comparatively small.

The arithmetic does not prove the cause. It tells you where to look.

Our recommendation is to examine results by useful, sufficiently populated groups: receiving provider, sending account, data source, verification age and campaign.

Keep the denominators visible. Ten failures among twenty recipients and ten among ten thousand are very different observations.

Also distinguish unique messages from delivery attempts. Otherwise, repeated attempts can make a retry-heavy campaign appear to have a different number of recipient failures than it actually does.

Reverification should answer a question

When a campaign disappoints, uploading the entire list to another checker feels productive.

Before doing so, write down the question you expect the new check to answer.

Perhaps it is:

Do addresses that now produce explicit recipient-not-found responses also receive different verification results?

Or:

Are failures concentrated among contacts whose last check was substantially older?

Those questions can support a useful investigation.

“Will another green tick fix the campaign?” cannot.

A recipient assessment is poorly matched to a sender-authentication error. Google’s sender guidelines separately address authentication, DNS, transport security and other sending requirements. That separation is a useful reminder that list quality is one part of the delivery process. Google’s sender guidelines

Our opinion is that verification products earn trust when they help users recognise the limits of the check, including situations where buying another check is unlikely to address the observed failure.

A suppressed contact can still be a valuable record

Pausing delivery, suppressing an address and deleting a CRM record are separate actions.

We recommend recording the reason and scope of suppression. That helps distinguish an unresolved technical problem from an unsubscribe, complaint or established recipient failure.

A later positive verification result should never automatically clear those different restrictions.

Likewise, a suppression does not necessarily require erasing the account relationship, support history or record of the decision. Retention and deletion should follow the organisation’s applicable policies, while sending eligibility remains explicitly controlled.

The practical principle is that cleaning should leave the team able to explain what changed and why.

This is particularly important when one email appears in multiple records with different owners or permission histories. Removing duplicate text strings is easy. Deciding which business context survives requires a stated rule.

What we would demand from a credible verifier comparison

A fair comparison needs more than a screenshot showing three different valid counts.

Our proposed evaluation would disclose the sample source, selection process, check times, result definitions and how catch-all or unknown outcomes were handled.

If delivery outcomes are part of the evaluation, it should also disclose the sending conditions and the attribution method. A policy rejection should not silently count as proof that a mailbox assessment was incorrect.

The denominator must be clear. “Percentage of submitted addresses classified” and “percentage of accepted classifications later supported by evidence” answer different questions.

Finally, publish unresolved cases.

A tool that assigns more decisive labels has not necessarily produced more knowledge. The comparison needs to show what supports those labels.

We would apply that standard to Refresh List as well. A useful research programme must be capable of finding weaknesses in the product publishing it.

Where Refresh List belongs

Refresh List’s role is to help users assess and verify their email lists while keeping results connected to the original rows.

The practical starting point is straightforward: retain account IDs, owners and source fields when you prepare a file. Review the assessment, then decide which eligible addresses to verify.

After a campaign, keep its delivery evidence connected to those records. The investigation framework in this article is a proposed workflow; it should not be mistaken for a claim that Refresh List currently performs every diagnostic step described here.

If your immediate question concerns the addresses themselves, create a Refresh List account and start with 100 free checks. If the evidence points to a sending configuration problem, investigate that cause before purchasing more verification.

That boundary is part of a useful product.

The question to ask before deleting a contact

A bounce tells you something happened. Your job is to establish how much that event allows you to conclude.

Did the receiving system identify a nonexistent mailbox? Did it reject your sender? Did delivery remain temporarily unavailable? Is the report too incomplete to decide?

Those answers lead to different actions.

The standard we propose for email list cleaning is therefore more demanding than “remove everything that failed”:

Every change to a contact’s status should have a reason that survives review.

Before deleting the next bounced record, ask:

What did we observe, what are we inferring, and what evidence would change our decision?

A team that can answer those questions has something more useful than a clean-looking list. It has a list it can manage with confidence.