Here's the mistake I see high-volume teams make constantly: they treat scrubbing like a vaccination. Run the list through a DNC and litigator scrub once, get the all-clear, and then text against that same file for six months like the result is permanent.
It isn't. A scrub is a snapshot of one moment. The list keeps moving after you take the picture — people disconnect numbers, port them, hand them back to the carrier, and the carrier hands them to somebody new. The person who opted in three months ago may not own that number anymore. And the new owner never consented to a single thing you're about to send them.
Full disclosure: I work for Ready, and we sell a standalone litigator/DNC scrub at $0.005 per contact. So I have a horse in this race. But the number-reassignment problem is real regardless of whose tool you use, and pretending a one-time scrub covers you is how clean lists quietly turn into liability.
Numbers get reassigned all the time, and it's faster than you think
The FCC has documented this for years: roughly 35 million US phone numbers are disconnected or reassigned every year. That's not an edge case. That's the baseline churn of the phone system.
Do the rough math on a per-month basis. Roughly 35 million reassignments spread across a mobile base in the hundreds of millions works out to somewhere around 1–1.5% of numbers changing hands per month — and cold, purchased, or skip-traced lists rot faster than that because they were already stale when you got them.
Two months out from a January scrub, you're looking at something on the order of 3–4% of the file that now points at a different human than the one you cleared. On a 100,000-contact list, that's 3,000–4,000 people who never opted in, aren't on your suppression list, and didn't tell you to stop — because they were never in the conversation to begin with.
I'm rounding here, and real decay depends heavily on where the list came from. But the direction is not in dispute: the file degrades continuously from the day you scrub it.
Why a reassigned number is a TCPA problem specifically
Consent doesn't travel with the number. It's tied to the person.
When someone gives you permission to text them and then gives up that number, your consent evaporates the moment the carrier reassigns it. The new owner is now a cold, non-consented recipient. Text them and you've got the same exposure as texting a purchased number you never had permission for — $500 per text, up to $1,500 for willful violations, and a plaintiff who can point to a list you knew was aging.
That last part matters. "We scrubbed in January" is not a defense in March. If anything, it establishes that you had a hygiene process and chose not to keep it current. The FCC's own reassigned-numbers database exists precisely because regulators expect callers and texters to account for this churn. Ignoring it isn't a gray area — it's the exact scenario the rules were written for.
If you're fuzzy on why a number can clear the DNC and still be a live lawsuit, the DNC-vs-litigator distinction is worth ten minutes. Reassignment stacks on top of both.
List source decides how fast the file rots
Not all lists decay at the same rate. Where the contacts came from tells you how often to re-scrub.
| List source | Consent quality | Rough re-scrub cadence |
|---|---|---|
| Opt-in you grew yourself | Documented, per-contact | Every 60–90 days |
| Aged opt-in (12+ months untouched) | Documented but stale | Every 30–45 days |
| Skip-traced / cold | None | Before every send |
| Purchased / rented list | Effectively none | Before every send, and reconsider sending at all |
An opt-in list you built and message regularly ages slowly — people who hear from you keep the number active and tell you when to stop. A purchased file is the opposite: it was assembled from data of unknown age, contains people who never agreed to anything, and reassignment is just one more thing wrong with it. We went deeper on the source-by-source rot rates in this breakdown of how fast each list source goes dirty.
The re-scrub cadence that actually keeps you covered
Stop thinking "scrub the list." Start thinking "scrub before this send." The right question isn't when did I last scrub — it's how stale is the data behind the batch I'm about to text right now.
A practical rhythm for a high-volume outbound team:
- Scrub every batch before it ships. Not the whole database on a calendar — the specific segment you're about to send. If you're texting 8,000 contacts Tuesday, those 8,000 get scrubbed Tuesday morning.
- Set a hard staleness ceiling. Any contact whose last scrub is more than 30 days old gets re-run before it's eligible for a send. No exceptions for "we just cleaned this."
- Treat re-engagement of dormant contacts as a cold send. A list you haven't touched in six months is a different animal than your active file. Scrub it like it's purchased, because reassignment-wise, it practically is. The scrub-then-reengage order saves you both spend and exposure.
- Keep the receipts. Log the scrub date per contact. If you ever have to show a process, "every send was scrubbed within 30 days" is a real answer.
The re-scrub cadence guide has the fuller version of this, including how to handle DNC's own 31-day expiry, which is a separate clock ticking alongside reassignment.
The cost math, worked out
This is where per-send scrubbing looks obviously worth it.
Say you send to a 50,000-contact segment twice a month. At Ready's $0.005 per contact, scrubbing that segment before each send costs:
- 50,000 × $0.005 = $250 per send
- Two sends a month = $500/month
Now the other side. If just 4% of that unscrubbed batch is reassigned — 2,000 numbers — and even a tiny fraction of those new owners are litigious or file complaints, you're exposed at $500–$1,500 per text. A single willful violation ($1,500) already costs more than three months of scrubbing the entire segment. Ten of them and you're past a year of scrubbing budget on one bad send.
Scrubbing isn't a cost you're trying to minimize. It's insurance priced at a rounding error against the thing it prevents. We ran the full version of this in scrubbing 100,000 contacts costs $500, one complaint costs $500–$1,500 per text.
Where Ready fits (and where it doesn't)
Ready's scrub is standalone and pay-per-use at $0.005/contact — you don't have to send SMS through us to use it. It checks each number against known TCPA-litigator lists and DNC-complainer lists and auto-suppresses matches before send. If you're already sending on Ready, quiet-hours enforcement and automatic STOP handling run alongside it, so the scrub is one layer of three rather than your whole defense.
What the scrub doesn't do: it isn't a reassignment database lookup on its own, and it doesn't manufacture consent you never had. It flags the people most likely to sue and the numbers on complaint lists. Pairing it with a strict per-send cadence — so you're catching numbers that turned litigious or changed hands since last time — is what closes the reassignment gap. One without the other leaves a hole.
And to be honest: if you send to a small, self-grown opt-in list you message weekly, you don't need to obsess over this. Your churn is low and your consent is documented. This post is for the teams sending tens of thousands to lists they didn't build themselves, on a cadence measured in weeks. That's where reassignment quietly stacks up.
The takeaway
A scrub result has a shelf life, and it's shorter than most teams assume. Phone numbers churn at roughly 1–1.5% a month, so a January scrub is meaningfully dirty by March — measurably wrong on thousands of contacts for a six-figure list. The fix isn't a bigger annual cleanse; it's scrubbing the specific batch you're about to send, with a 30-day staleness ceiling and a log to prove it.
If you want to see what a per-send scrub actually catches on your current file, you can run one at $0.005 a contact without moving your sending anywhere — start at Ready or create an account and scrub a batch before your next send goes out. Even if you decide the cadence I'm describing is overkill for your list, running it once tells you how stale your data really is.