It wasn't the sequences. It wasn't the timing. It wasn't the copy.
She had been running outbound for the company for two years. 400 to 600 targeted contacts a month, sequenced across a three-touch cadence, tracked against pipeline contribution. She knew what good looked like. She had built the reporting herself.
What eventually surfaced — not through deliberate diagnosis, but because a colleague happened to check a setting that usually never changes — was that the company's domain reputation score had fallen below the threshold at which Gmail began routing their mail to spam by default.
The score had been declining for eleven weeks before the open rate drop became visible. Silent, continuous, invisible to everything except a metric she had no reason to be watching.
The cause was not the sequences. It was not the domains. It was a contact list sourced in Q3 that had never been validated. Eight hundred addresses. Sent against. A hard bounce rate of 9.3% on that one cohort. That cohort alone was enough to start the clock on the reputation decline that became visible three months later.
The definition, without the padding
Email validation is the process of checking whether an email address is viable before sending to it — confirming that it's structurally formed correctly, that the domain it belongs to is active and configured to receive mail, and that the address is likely to reach a real inbox rather than bounce or disappear.
Teams that treat validation and verification as interchangeable tend to skip validation because they believe verification covers everything. It doesn't. An address attached to a domain that expired six months ago will never return an SMTP response — there is no handshake to initiate, no server to query. Validation eliminates it before any of that happens.
What sender reputation is — and why it's the actual stakes
Every email you send originates from a domain. That domain carries a sender reputation — a continuously updated score maintained by inbox providers including Google, Microsoft, and Yahoo. You cannot see this score directly. No dashboard shows it. But it determines whether your emails arrive in inboxes, in spam, in promotional tabs, or not at all.
Validation controls the first of these directly. Every address removed at the validation stage is one fewer potential hard bounce. Clean validation compounds upward into consistent deliverability. Skipped validation compounds downward into exactly what happened in January.
The four checks — what they catch, and what they miss
Validation is not a single operation. It is a sequence of four, and understanding what each one catches — and where each one stops — is the difference between treating validation as a checkbox and using it as a genuine quality filter.
The catch-all mistake that looks like a validation problem
The mistake is binary treatment of catch-all addresses. Either include all of them — they weren't flagged invalid, so they're probably fine — or exclude all of them to be safe. Both decisions are wrong.
On a list sourced from an enrichment provider and not refreshed in 60+ days, the undeliverable proportion within catch-all addresses can run to 35–50%.
Binary exclusion solves the bounce problem but creates a different one: if 17% of your list is flagged catch-all and half of those addresses are functional inboxes, you've removed 8.5% of your reachable contacts — not because those addresses are bad, but because your process couldn't distinguish the good ones.
The correct treatment is stratification — a probability assessment on each address, using signals like recent domain web activity, naming convention match, second-source confirmation, and record recency. No single signal gives certainty. A combination gives a probability ranking, and decisions made against a ranking produce materially better outcomes than decisions made against a binary label.
The failure that lives before validation even starts
There is a class of delivery failure that validation cannot catch — not because validation failed, but because the problem was introduced upstream of it.
You have a target list of companies. You have names and job titles. You construct addresses by combining each contact's name with the domain and the most common email format pattern (first.last@, f.last@, first@, last@).
The constructed addresses go through validation. They pass. The domains are live. MX records exist. Syntax is correct.
The campaign sends. Fourteen percent bounce.
Not because validation failed. Because the premise validation was evaluating was wrong before the check ever ran.
Email format is not uniform across companies. A domain on a company's website may not be the domain where executives receive mail — subsidiaries, acquisitions, and rebrandings leave domains that are live but no longer primary.
Reading validation results correctly
A validation run returns four output categories. Most teams read three of them with more confidence than the results warrant, and one of them in entirely the wrong direction.
The calibration mechanism that makes all of this meaningful: track your post-send hard bounce rate segmented by the validation result each address carried into the send. Run this after every significant campaign, consistently, over time. It tells you with precision how accurate your validation process actually is against your specific list composition and sending domains — not a benchmark, not theory. That is the number that matters.
When validation needs to be a practice, not a step
The teams with consistently clean sender reputations do not validate before campaigns. They validate as a property of data — every address carries a validation timestamp with an operational expiry, after which it is not sequenced without being re-run.
2–3% decay per month
The industry consensus on B2B contact decay. Over sixty days, that's 4–6% of addresses in any cohort that moved from deliverable to not-deliverable — through no fault in the original validation, just the natural churn of roles changing, acquisitions, and domain restructuring.
Re-validation at send time, or within thirty days, catches addresses that decayed after the initial check. It is not expensive. It is significantly cheaper than the reputation repair that follows a send against a cohort that was clean when validated and wasn't when sent.
For teams sending above 15,000–20,000 emails per month, a 4% hard bounce rate is not a hygiene issue for the next planning cycle. It is an active event that will produce measurable domain reputation damage within weeks — damage that persists through campaigns that had nothing to do with the list that caused it.
What validation actually protects
The woman in January recovered. It took eleven weeks of careful sending at reduced volume to rebuild the domain reputation score to the point where Gmail stopped default-routing their mail to the promotional tab. During those eleven weeks, three campaigns that should have contributed to pipeline contributed almost nothing. The attribution gap was visible in the quarterly numbers. It came up in reviews.
The underlying list that caused it — 800 contacts sourced in Q3 and never validated — took ninety minutes to source and twenty minutes to load into the sequence tool. The cost of not validating it was eleven weeks of degraded deliverability across an entire sending domain that other campaigns also depended on.
The work required to validate a list before use is small, predictable, and front-loaded. The cost of skipping it is delayed, invisible until it isn't, and then disproportionate to what caused it — because the reputation damage doesn't stay contained. It spreads across the domain. Every send that follows inherits it.
Validation does not write better messages or sharpen targeting. It does something more fundamental: it prevents the infrastructure that outbound runs on from being quietly degraded by data that was never fit to send against. Not one campaign. The ground everything else stands on.
Get the domain right before validation even starts
Proxy25.com resolves company names to the verified, active domains where employees actually receive mail — the decision that has to be made correctly before address construction, before validation, before anything outbound touches a list.