Your Reactivation List Has Strangers In It

Numbers move and your CRM does not notice#

Picture the list a reactivation campaign actually runs on. Closed-lost from two quarters ago, a webinar registration list, a trade show scan file, every record with a mobile number and a reason to follow up.

Those numbers were accurate on the day they were collected. Since then people changed jobs, changed carriers, cancelled a line, or let a company plan lapse when they left.

Nothing about that reaches your database. The row still reads as a valid ten-digit mobile with a first name attached, so every tool downstream treats it as the same person.

• Federal rules put a floor and a ceiling on the wait. A number last assigned to a residential customer may be aged no less than 45 days and no more than 90 before reassignment (47 CFR 52.15(f)(1)(ii), eCFR current through 1 September 2026, read 18 September 2026).
• Business numbers get a longer window: no less than 45 days and no more than 365. B2B lists go stale slower than consumer lists, which is why the problem hides longer in outbound sales than in retail marketing.
• The ceiling is a maximum, not a promise. A carrier that needs numbers in a busy area code can release a business number at the 45-day floor.
• None of this is an error in your data. The record was right when it was written, and it decayed quietly afterward.

A capability check answers a different question#

Before a blue-bubble campaign sends, something checks whether each number can receive an iMessage at all. That check is useful and it is not the check people think it is.

What comes back is whether an Apple account is currently registered to that number. A stranger who activated the line last month and signed in on their own iPhone returns exactly the same answer your prospect did.

So the two questions come apart. Can this number receive the message, and is this still the person who agreed to hear from me, get different answers on the same row.

• Deliverability tooling across this category is built around the first question, because that is the one that changes whether a send succeeds.
• The second question has a separate federal answer, and almost nobody in the iMessage lane mentions it. Attentive publishes reassigned-number workflows as an enterprise feature on the SMS side (attentive.com, read 18 September 2026).
• The failure is invisible in your dashboard. A message to a reassigned number delivers, shows as sent, and counts as a successful send in every report you look at.
• Reply rate is where it surfaces, quietly. See how list quality moves outbound numbers for the rest of that picture.

What the federal database actually returns#

The FCC runs a Reassigned Numbers Database at reassigned.us, built for exactly this problem. You give it a number and the date you last had contact, and it says whether the line was permanently disconnected in between.

Three answers come back, and the wording matters because only one of them helps you. The database publishes what each means in plain language.

Note that it reports permanent disconnection, not reassignment. Disconnection is the event carriers report, and reassignment is what follows it after the aging window.

• Yes means the number was permanently disconnected on or after your consent date. The safe harbor does not apply and the row should not be messaged (reassigned.us/querying-data, read 18 September 2026).
• No means it was not disconnected since consent, or the consent date is on or after 27 January 2021 and no disconnect exists. Safe harbor may apply.
• No data means the number was not disconnected and your consent date is earlier than 27 January 2021. Safe harbor does not apply, because carriers only began keeping these records on that date.
• That third answer is the one that bites a long-lived CRM. Any consent older than January 2021 gets no protection from this database at all, however diligently you query.

The safe harbor is narrower than the headline#

Reading the rule itself is worth four minutes, because the protection is conditional in two places and the burden sits on the sender both times.

The rule says a person is not liable for a call to a number whose subscriber changed after consent, if that person proves two things. The wording is exact and the word prove is doing real work.

Read it as an evidence standard rather than a shield. You are being asked to produce a query record with a date on it, months or years after the send.

• First condition: based on the most recent numbering information, querying the database returned a response of no, verifying the number has not been permanently disconnected since consent was obtained (47 CFR 64.1200(m)(1), read 18 September 2026).
• Second condition: the call happened because the database erroneously returned no. The protection covers a database mistake, not your decision to skip the check.
• The person bears the burden of proof and persuasion, in the rule's own words. No query record means no argument to make.
• The TCPA has treated a text message as a call for over a decade, which is why this reads as call and applies to your sends. Our TCPA guide for texting covers the rest of that framework.

What checking a list costs#

Price is the reason to do this, and most teams have never looked it up. Access is a prepaid subscription with a query allowance, published as a table on the database's own pricing page.

Run the arithmetic against a real reactivation list. A five thousand row file is one query per row, once, before the campaign loads.

Compare that to the cost of the alternative. One spam report on a line is worth more than a decade of these subscriptions.

• Tier 1 is 1,000 queries for $8 on a one-month subscription, which is $0.008 per number. Tier 2 is 10,000 for $60, and an annual option gives 120,000 for $648 (reassigned.us/pricing, table dated 2 July 2025, read 18 September 2026).
• Volume drops the unit price hard. Tier 5 is 500,000 queries for $2,000 a month, and the top tier is 50,000,000 for $28,000.
• Running out mid-campaign is handled: paying ten percent of the subscription price adds ten percent more queries on the same term, and you can repeat it.
• Queries go in through the interface up to 50 at a time, a file upload up to 1,000,000 numbers, SFTP, or an API at 1,000 numbers per call. Each query carries the number, your last known contact date, and your company ID.

Four things the database will not tell you#

Knowing the boundary keeps you from over-trusting a clean file. A no response is a narrow statement about one reported event, and reading it as proof of identity puts you back where you started.

Carriers report on a monthly cycle, so recency is limited by design. A disconnect that happened after the last reporting cutoff is not in there yet.

Use it as one filter among several rather than as the verdict on a row.

• It does not tell you the number changed hands inside one account, such as a company phone passed to a new employee. No disconnect happens, so nothing is reported.
• It does not tell you the person moved their number to a new carrier and kept it. A port is not a permanent disconnect.
• It does not tell you whether consent was ever valid in the first place. That is a record-keeping question on your side, not a numbering question.
• It does not tell you the human still wants to hear from you. Consent decays in ways no federal database tracks, which is the argument for a re-permission message rather than a cold pitch to an old row.

On a threaded channel a stranger costs more#

Legal exposure is the reason this rule exists. Channel damage is the reason a sales team should care about it this week.

Consider what a reassigned number receives. A first-name greeting, a reference to a conversation they never had, and a follow-up question about a quote that was never sent to them.

The reader has one obvious explanation available. Somebody bought their number, and the button for that is right there in the thread.

• Apple treats a spam report as a switch rather than a score, so a small number of reports on one line does real damage to every conversation that line is holding.
• Capacity is the second cost. Blue Reacher publishes no total daily message cap and never meters replies, and new conversations pace at 50 opted-in and 30 cold per line per day, so a message to a stranger is a slot a real prospect did not get.
• Tuco AI publishes roughly 50 new contacts and 150 total outbound messages per line per day, and states that three recipient reports can end a line regardless of rate (tuco.ai/limitations, read 18 September 2026).
• Reactivation campaigns concentrate the risk, because the whole point of the play is that the records are old. Read the pipeline revival sequence with this filter in front of it.

An afternoon on your own list#

Everything below runs on a spreadsheet and a card, with no engineering and no vendor call. Do it on the next list you were about to load rather than on the whole database.

Start by finding the dates, because the query needs one per row and most CRMs bury it. Last known contact date is the field the database asks for.

Finish with a written rule for your team about how old a record has to be before it gets checked. A rule you wrote down survives the quarter you get busy.

• Pull the next campaign list and add a column for the date consent was given or last verified. Count how many rows predate 27 January 2021.
• Register at reassigned.us, buy the smallest tier that covers the file, and query it once.
• Quarantine every yes rather than deleting it, so you keep the evidence that you checked.
• Save the query results file. Downloads stay available for 45 days, so archive it somewhere that outlives that window.
• Write the age threshold into your list-build checklist, and put the same check in front of any purchased or scraped file before it is ever loaded.

Frequently asked questions