Quick answer: A recycled number breaks the link between the subscriber who consented and the handset you are about to send to — so the question is not "did we scrub?" but "which registry answered which question, at which stage of the send path." Devotel Orbit ships two separate checks for this: the FCC Reassigned Numbers Database (RND), which answers the safe-harbor question "was this number permanently disconnected after my consent date?", and the carrier deactivation scrub, which answers the churn question "did the carrier deactivate this number since I last saw it valid?". This post is the framing layer above both explainers: one paragraph on the exposure, a decision table against DNC-only thinking, where each check wires into the send-gate chain, and the tenant-owned checklist you hand to counsel. The endpoint contracts live in the docs; this post is the argument for how to buy the two controls together.
The exposure, in one paragraph
Under the TCPA, prior-express consent attaches to the subscriber, not the phone number (47 U.S.C. § 227). When a carrier permanently disconnects a number and recycles it to a new holder, the destination re-points: your consent stops covering it, and every subsequent send is an unsolicited message to a stranger — each one a putative violation with statutory damages per send. Two upstream registries see that re-pointing from different angles. The RND records permanent disconnects reported by carriers, which is what the FCC's safe harbor was defined against. The carrier deactivation feed records churn events — cancellations, ports, reclamations — which the RND may never see as permanent. Prior DNC-only thinking records neither; it answers whether the person objected to telemarketing, not whether the number still binds to them.
The decision table
Buyers evaluating list hygiene stack these three claims, and the mistake is treating any one of them as a substitute for the others:
| Registry | Question it answers | Evidence class | Safe-harbor basis? |
|---|---|---|---|
| DNC registries (federal, state, TCR, internal suppression) | Did the person opt out of telemarketing? | The person's relationship with your outreach | No — never was |
| Carrier deactivation scrub | Did the carrier deactivate this number since you last saw it valid? | Churn events: cancellations, lapses, ports | No — detects churn the RND has not yet recorded |
| Reassigned Numbers Database (RND) | Was this number permanently disconnected after your consent date? | Permanent disconnects reported to the FCC-mandated registry | Yes — an evaluated-and-logged no verdict is the safe-harbor credit |
The buyer decision falls out of the table directly:
- DNC-only thinking leaves both recycled-number holes open. A
number clear of every DNC registry can still be a stranger's handset. DNC scrubs stack with the recycled-number checks; they do not overlap them.
- The deactivation scrub is the early-warning layer: churn events
surface in the carrier feed before (and sometimes without ever) reaching the RND. It is the right basis for bulk list hygiene — pre-flighting an audience before a campaign and dropping churned rows — and it carries last_seen semantics so a deactivation older than your re-verified consent does not scrub a legitimately refreshed number.
- The RND check is the litigable layer: when a send's legal basis
is prior-express consent, only an evaluated RND verdict buys the FCC safe harbor. A deactivation-scrub active verdict is hygiene evidence; it is not the safe-harbor claim, and a buyer that confuses the two is holding the wrong receipt in discovery.
Neither recycled-number check subsumes the other. The deactivation feed catches a port-to-another-carrier churn the RND may never record; the RND is the only verdict with a statutory credit behind it. Series, not substitutes.
Where each wires into the send-gate chain
Both are tenant-owned gates: opt-in per organization, default off, and each filters your audience before the send pipeline launches rather than hard-refusing traffic you never asked it to screen. In the chain, they fire at different altitudes:
- Pre-campaign (bulk hygiene). The deactivation scrub's
POST /api/v1/compliance/deactivations/scrub pre-flights up to 1,000 numbers per request against the carrier feed and returns per-number should_scrub verdicts — the audience-shaping stage. The RND has no bulk endpoint by design; its batch pattern is a loop over the single check so every refusal carries a one-verdict audit entry.
- Send time (per-recipient gates). With the deactivation scrub
enabled, the messaging pipeline refuses a dispatch when the carrier deactivated the number on or after your most-recent consent date (422, MESSAGING_NUMBER_DEACTIVATED); the dialer evaluates the same verdict before originating NANP calls; and Verify/OTP applies a strict disconnect-presence model (VERIFY_NUMBER_DEACTIVATED) because a login code has no consent ledger. The RND leg is the per-call check your send path consults — GET /api/v1/compliance/rnd/check with phone and consent_date — returning yes / no / no_data with safe-harbor fields, every call written to the audit log with the phone truncated.
- The verdict-semantics stage. Both verdicts carry a
feed_synced
flag, and both treat no_data as unknown rather than passed — a gate that treats unknown as cleared is a gate that no longer gates. Route no_data to the same suppressed bucket as a positive hit unless your risk desk says otherwise.
The full chain ordering lives in Send Gates; the per-endpoint contracts are deactivation scrub and RND scrub.
Tenant-owned controls, and the checklist to hand counsel
Both scrubs return evidence, not verdicts about your legal posture. The go/no-go on contacting any destination is yours, owned by your counsel — Orbit's contribution is that the evidence exists, is dated, and is auditable. Procured together, the two checks cover the two questions a recycled number poses; the checklist a buyer should be able to affirm before relying on either:
- [ ] The organization has opted in to the scrub(s) explicitly — both
ship off, and an unset opt-in yields gate errors on manual checks and skips on pre-send guards.
- [ ]
feed_syncedis read on every verdict consumed by policy; a
stale verdict from audience-build time is not re-scrubbed evidence.
- [ ] Pre-send re-scrub happens at send time for audiences held longer
than a few days, not only at list import.
- [ ]
no_dataroutes to suppress, not to pass, in the risk policy. - [ ] The RND leg is the one cited when the send's legal basis is
prior-express consent — the deactivation verdict is hygiene evidence, not the safe-harbor claim.
- [ ] The DNC, quiet-hours, and consent-ledger layers still run in
parallel; the recycled-number checks stack with them, never replace them.
If any box is unchecked, the answer is a process fix, not a new registry — the two registries already answer every recycled-number question a sender can ask, provided someone asks them at the right stage.
Frequently asked questions
If I run the deactivation scrub, do I still need the RND check?
Yes, when prior-express consent is the send's legal basis. The deactivation verdict is hygiene evidence against churn; only an evaluated RND no carries the FCC safe-harbor credit. The two answer different classes of disconnect event at different altitudes of the send path.
Is DNC scrubbing part of the recycled-number problem?
No. DNC registries record a person's objection to telemarketing. The recycled-number exposure is that the destination changed hands — DNC-only thinking never sees it. The layers stack; they do not overlap.
Which check fires for OTP / Verify traffic?
The deactivation scrub, under a strict disconnect-presence model — there is no consent ledger for a login code, so any deactivation record on file refuses the send. Wrong-recipient OTP is an account-takeover vector, not a marketing-hygiene miss.
Why does neither check treat no_data as a pass?
Because a gate that silently degrades to cleared is worse than no gate. Both verdicts expose feed_synced so a consumer can weigh whether an ingested snapshot backed the answer — and the tenant's risk policy owns the routing either way.