Data Decay: Why a Verified List Stops Being Verified
Data decay treats accuracy as a rate rather than a condition. Fields rot at very different speeds, so a record has no single expiry date, and verification is a reading taken at a moment rather than a property of the row. The first evidence usually arrives as a bounce, which is after the send has been paid for.
Key takeaways
- Decay is per-field. Industry and founding year barely move; job title and work mailbox move constantly. One decay figure for a whole record describes none of its fields.
- Verification is a point-in-time reading. A verified flag with no date beside it asserts a fact without saying when it was established.
- Published decay percentages are properties of a segment, not of B2B data. Enterprise finance leaders and venture-backed founders decay at rates that are not in the same range.
- Nothing in a record changes when it decays, so every quality gate still passes it. Re-verify close to the send rather than close to the purchase.
Data Decay: Why a Verified List Stops Being Verified
Data decay is the rate at which the attributes stored on a contact or company record stop being true. People change jobs, companies rebrand or get acquired, mailboxes are retired, domains are moved, titles are reorganised, and none of those events sends a notification to the system holding the record. The record does not change. The world does, and the record is left describing a state that no longer exists.
The term exists because it forces a shift from thinking of data quality as a condition to thinking of it as a rate. A list is not clean or dirty. A list was accurate at a moment, and it has been losing accuracy at some pace ever since that moment, and both halves of that sentence matter for planning. Teams without the concept buy a list, verify it, and treat the verification as a property of the file, which is roughly like treating a thermometer reading as a property of the room. The reading was correct. It described an instant.
How data decay actually works
Decay is per-field, not per-record, and the fields rot at wildly different speeds. That is the single most useful thing to understand about it, because it changes what you re-check and how often.
A company's industry classification barely moves. Its founding year does not move at all. Its headcount band drifts slowly and predictably in one direction for a growing company. A person's job title changes with every internal reorganisation, and their employer changes whenever they leave, which takes their work mailbox with it. Direct dial numbers sit somewhere in the middle, and company domains are stable until an acquisition makes them disappear overnight, taking every address on them at once.
Averaging those into one decay figure for the record produces a number that describes no field on it. The useful model is a decay rate per field, which means a re-verification schedule per field rather than a single date on which the whole list is declared stale.
The second structural idea is the half-life. Decay is a rate rather than an event, so a list has no expiry date, only a curve. Some share of it is wrong the day it lands, because the sources it was built from were themselves out of date at the time of capture. A larger share is wrong later. There is no moment where the file goes bad, which is exactly why teams keep sending to lists long past the point where doing so is costing them more than it returns.
- At captureEverything on the row is true
The address resolves, the title is current, the company details match the site
- Shortly afterThe company record drifts first
A rebrand, an acquisition, a headcount band that no longer applies
- LaterThe person moves
A new employer, or an internal change that makes the stored title wrong
- At sendThe row still reads as verified
Nothing in the record has changed, so every quality check still passes
- After sendThe bounce arrives
The first hard evidence of decay reaches you after the send has already been paid for
Decay also arrives in two shapes that need different responses. Most of it is gradual and roughly predictable: individual people moving on at whatever pace their industry moves. Some of it is a single event that invalidates a large block of rows at once, and acquisitions are the obvious case, since one announcement can retire an entire domain and every address on it. Gradual decay is handled by a schedule. Event decay is handled by noticing, which usually means watching for domains that stop resolving and treating a cluster of bad addresses sharing one domain as a company-level fact rather than as bad luck spread across individual rows.
The third idea does most of the practical work: verification is a point-in-time reading, not a property of the row. A verified flag with no timestamp beside it is close to useless, because it asserts a fact without saying when the fact was established. Any field carrying a verification status should carry the date that status was set, and any process reading that field should treat an old date as unverified rather than as verified.
How it is measured
You cannot observe decay directly, so it is measured through its symptoms, and the main symptom is bounced mail. That makes the bounce counter the closest thing to a decay meter most teams have, and it is worth knowing how imprecise an instrument it is.
Our own 2026 benchmark report classified all 42,953 bounce-folder messages from 1,413,405 sends by hand. Of those messages, 17,911 were genuine bad-address messages, while 15,744 were blocked or policy rejections and the rest were delay notices, unreachable domains and full mailboxes. Separating them moved the number substantially: the platform bounce counter read 3.04% where genuinely bad addresses were 1.27%, an inflation of 2.4 times. The methodology is set out in the 2026 cold email benchmark report.
The counter as it appears in the sending platform
After every bounce-folder message was classified by hand
The gap between the reported number and the measured one
Out of 42,953 classified bounce-folder messages
The reason this matters for decay specifically is that only the bad-address portion is evidence about your data. A policy rejection tells you something about the recipient's mail filtering rather than about whether the person still works there, and reading a blended counter as a decay signal will have you re-buying a list that was fine. If you want to use bounces as a decay measurement, the classification step is the whole job.
Where the textbook definition breaks
Everyone quotes a decay percentage as though it were a property of B2B data in general. It is a property of the segment, and the averages that circulate describe no real list.
Consider two lists built the same week. One is enterprise finance leaders at large regulated institutions, where tenure is long, titles are formal, mailbox conventions are stable and domains rarely change. The other is founders and early operators at venture-backed startups, where the company may not exist under the same name later, the person may hold a different title before the quarter ends, and a meaningful share of the domains will simply stop resolving. Those two lists decay at rates that are not in the same range, and the average of them describes neither. Applying an industry-wide figure to your own planning is a way of importing somebody else's segment into your budget.
The second break is the one that costs money, and it follows from the timeline above. The record does not announce that it decayed. Nothing in the row changes when the person leaves, no field flips, no quality check fails. Every gate you have will pass it, because every gate is reading the row and the row is intact. The first evidence of decay is a bounce or a reply from a stranger, and both of those arrive after you have already spent the send, consumed sending reputation on an address that was never going to work, and in the aggregate degraded the deliverability of an inbox that is also carrying your good mail. What that costs is set out in email deliverability services.
That asymmetry is the argument for re-verifying immediately before a send rather than at the point of purchase. Verification at purchase measures the file. Verification at send measures the population you are about to pay to reach, and those are different populations separated by however long the list sat in storage.
There is a quieter version of the same problem that never produces a bounce at all, and it is worth naming because no bounce counter will ever find it. A person who left still has a working address at their old employer, because the company keeps it alive for a period. A title that was reorganised still reads plausibly. A headcount band that is now wrong still passes every filter. These rows deliver, get opened, and produce nothing, and they are indistinguishable in every report from rows that were simply not interested. Decay measured only through bounces therefore reports the visible half and misses the half that shows up as a flat response rate on a segment somebody will eventually blame the copy for.
What to do with it
Re-verify close to the send, not close to the purchase, and use a fresh reading rather than a stored flag. The tooling for that step is compared in email verification tools.
Store a per-field verification date and let processes downstream decide what counts as too old for their purposes, rather than declaring a single expiry for the whole record. A campaign targeting by job title needs a recent title reading; a campaign targeting by industry does not care, because that field barely moves.
Treat re-enrichment as a partial job rather than a full rebuild. Re-running an entire table through a provider pays again for the fields that did not change, and the ordering logic for doing it economically is in waterfall enrichment. For the sourcing side, when a segment's decay is high enough that maintaining a list costs more than rebuilding it, best email finder tools is the practical comparison.
The maintenance practice that answers decay systematically is data hygiene, which has its own entry in this glossary. This entry describes why the values go wrong; that one describes the routine that keeps a CRM worth querying anyway.
Related terms and guides
CRM enrichment is the workflow that repairs decayed fields, and match rate governs what that repair costs per usable record. Record matching decides whether a refreshed value reaches the right row, which becomes harder as decay accumulates, because the fields you would join on are themselves the ones that changed.
Upstream of all of it, a segment definition written in slow-moving fields decays more slowly than one written in fast-moving ones, which is a targeting decision rather than a data decision. Ideal customer profile is where that choice gets made, and it is worth making deliberately if list maintenance is becoming a recurring cost.
If you would rather see a campaign run against a list verified immediately before sending rather than at purchase, see what a first campaign looks like.
Frequently asked questions.
Frequently asked questions- How fast does B2B contact data decay?
- Fast enough to matter and too variable for a portable figure. The rate depends on the segment: long-tenure roles at large regulated institutions hold their values far longer than early-stage startup contacts, where the company name, the title and sometimes the domain all move. Measure it on your own segment rather than importing an industry average built on somebody else's.
- Is a bounce rate a good measure of data decay?
- Only the bad-address portion of it. Our 2026 benchmark report classified 42,953 bounce-folder messages by hand and found 17,911 bad-address messages alongside 15,744 blocked or policy rejections; the platform counter read 3.04% where genuine hard bounces were 1.27%. Without that classification step, a blended counter is not a decay signal.
- Should you re-verify at purchase or before sending?
- Before sending. Verification at purchase measures the file as it was when it was built, and any delay between that check and the send is decay you have not accounted for. A fresh reading measures the population you are about to pay to reach, which is the only population the number needs to describe.
- Why do decayed records pass every quality check?
- Because the record itself does not change when the world does. The person leaves, the title is reorganised, the company is acquired, and every field on the row stays exactly as it was written. Gates read the row and the row is intact, so the first hard evidence arrives after a send, as a bounce or a reply from a stranger.