Skip to content
MailCull
Back to blog list-hygiene

Nine Email Data Myths That Cost People Money

A clean list is not an engaged list, unsubscribes are not the enemy, and nobody can detect every spam trap. Nine beliefs about email data that sound reasonable and lead to expensive decisions.

Most bad email decisions come from beliefs that are almost true. Each of these sounds reasonable, gets repeated widely, and leads somewhere expensive.

011. "A clean list is an engaged list"

The most common conflation in email, and the one that produces the most disappointment.

Verification tells you whether a mailbox exists and accepts mail. It has no opinion on whether the person behind it wants to hear from you, and cannot have one. Someone who has ignored every email you have sent for two years, at a perfectly functional Gmail address, verifies as deliverable. Correctly. Their mailbox works.

So a brand can clean a list thoroughly, remove every dead address, and watch open rates keep falling. The cleaning worked. The problem was never validity.

Two different datasets answer two different questions. Verification results tell you who can receive mail. Your ESP's open and click history tells you who wants it. Confusing them means running a verification pass to solve a relevance problem, which does nothing.

022. "Unsubscribes are a loss"

Every unsubscribe is a person who chose the correct exit instead of the destructive one.

The alternative to an unsubscribe is not continued readership. It is the spam button. Under the current bulk sender requirements, Gmail enforces a hard ceiling of 0.30% on spam complaints, which on a 50,000-message send is 150 complaints total. Unsubscribes are not counted against that ceiling at all.

Which means burying the unsubscribe link, a thing people still do, converts a free action into one of your 150 allowed complaints. You made the metric that matters worse in order to protect a number that does not.

Make the unsubscribe obvious. Make it more obvious than feels comfortable.

033. "A verification service can detect spam traps"

No. Not ours, not anyone's, and the claim should make you suspicious of whoever makes it.

A spam trap is an ordinary mailbox that accepts mail. That is the entire design. At the protocol level it is indistinguishable from a real address, because it is a real address. Nothing in a DNS lookup or an SMTP conversation separates a trap from a person.

What verification genuinely does is reduce your exposure. Traps live disproportionately inside a particular population: old, never-confirmed, unengaged addresses acquired through channels you cannot fully account for. Culling that population statistically reduces how many traps you are carrying, without ever identifying one.

That is a real benefit and a much weaker claim than detection. Anyone selling detection is describing a product that does not exist.

044. "Catch-all domains are undeliverable"

They are unverifiable, which is a different thing, and treating them as invalid throws away real customers.

A catch-all domain accepts mail to every address, whether the mailbox exists or not. So a positive response proves nothing about the specific address. It also does not prove the address is bad.

Plenty of legitimate businesses run catch-all configurations, often small companies and agencies. If you delete every catch-all address you are deleting real people alongside the fabrications.

The correct handling is a status of its own: risky or unknown, meaning the evidence did not resolve, and the decision is yours. Sending is reasonable on an outbound campaign with tolerance for a slightly higher bounce rate. It is not reasonable when you are repairing a damaged sender reputation. Our catch-all explainer covers the mechanics.

055. "Higher accuracy percentages mean a better service"

The published figures are self-reported, unaudited, and clustered within a few points of each other. We say 98% and cannot hand you an independent audit of it either.

Worse, the number is gameable in the wrong direction. A service that guesses confidently on every uncertain address reports higher accuracy than one that reports uncertainty honestly, because guessing produces a verdict that is right about half the time by luck while declining produces no verdict at all.

So a high accuracy claim can indicate either a good pipeline or an overconfident one, and the published figure does not distinguish them. If you want to know, build a control set and measure it yourself.

066. "Verified means verified forever"

A verification result is a statement about one moment.

Lists decay continuously, at roughly 2% a month on average with wide variation by list type. People change jobs, domains lapse, mailboxes get abandoned. A result from six months ago describes a list that has since lost something like 12% of its addresses.

This matters most for stored results. If you verified in March and are sending in October off the March file, you are sending to a list you have not actually checked. The decay arithmetic covers how to measure your own rate rather than assuming the average.

077. "Removing a big chunk of my list will hurt my results"

It will improve them, and the confusion comes from watching absolute numbers instead of rates.

Delete 15% of a list as dead and your total opens fall, because you are sending fewer messages. Your open rate rises, because the denominator no longer includes addresses that were never going to open. Your inbox placement on the remaining audience improves, because you stopped signalling to mailbox providers that you do not know who your recipients are.

The uncomfortable version: those addresses were already not generating anything. Deleting them changes what you can see, not what you are earning. You were paying your ESP to store them and paying a reputation cost to mail them.

088. "Bounce rate is the metric to watch"

It is a metric to watch. It is no longer the one that governs whether you reach the inbox.

Bounce rate matters and hard bounces are a real reputation signal. But the threshold that will actually cut you off is the spam complaint rate, because that is where the providers set a published hard ceiling. Gmail's 0.30% with a practical target under 0.10% is a genuinely tight constraint, and it is met or missed on every single send.

The two have different fixes, which is why the distinction matters. Verification fixes bounce rate directly. It barely touches complaint rate, because a live address belonging to someone who does not want your mail is correctly deliverable and will still be reported. Complaint rate is fixed by sunsetting unengaged subscribers and by confirmed opt-in at capture.

Optimising bounce rate while ignoring complaint rate means passing the test nobody is grading.

099. "Role-based addresses should always be removed"

Depends entirely on what you are doing, and blanket removal is a real loss for some senders.

info@, sales@, support@ and admin@ are shared inboxes. For consumer marketing they are usually worth excluding: nobody at a shared inbox signed up for your newsletter, and complaint risk is elevated.

For B2B outbound, sales@ at a company you are trying to reach may be the correct and intended destination. Removing it removes the address most likely to be monitored by someone whose job is to read it.

The address type is information, not a verdict. Our post on role-based addresses works through when to mail them.

10The pattern

Most of these come from the same underlying error: treating email data as one thing when it is at least three.

Can this address receive mail? Verification answers this.

Does this person want my mail? Only engagement history answers this.

Am I allowed to mail them? Only your consent records answer this.

Nearly every expensive email decision I have seen comes from using an answer to one of those questions as if it answered another. A clean list is not a permissioned list. A permissioned list is not an engaged list. And no amount of any one of them substitutes for the other two.

Find out what is actually in your list. 500 free credits a month on the full scan.

Try it

Start with 500 free validation credits. No card.

Both Free and Pro run the same scan engine, full SMTP probe, MX lookup, typo, disposable, domain checks, and the evidence chain on every verdict. The difference is the monthly credit pool (Free=500, Pro=10,000, Max=75,000) plus Pro's API and MCP access.

Found a mistake? Email [email protected]. list-hygiene · list-cleaning · deliverability · email-validation · bounce-rate