Who Keeps Your Opt-Out Record, and For How Long?

The five-year record and the ten-day clock#

47 CFR 64.1200(d)(6) requires a record of a consumer's request not to receive further calls, and says the request must be honored for 5 years from the time it is made.

Acting on it runs on a much shorter clock. Paragraph (d)(3) says the request must be honored within a reasonable time, and that period may not exceed ten business days.

Paragraph (e) is the sentence that makes both reach texting. It extends paragraphs (c) and (d) to text messages sent to wireless numbers, to the extent described in FCC 03-153.

• Two different obligations sit in the same rule: five years of evidence under (d)(6), and ten business days of action under (d)(3). Cited from the eCFR versioner API, text current through 1 September 2026.
• The sentence that decides this post is in (d)(3): "If such requests are recorded or maintained by a party other than the person or entity on whose behalf the call is made, the person or entity on whose behalf the call is made will be liable for any failures to honor the do-not-call request."
• Sharing a request outside your own entity or an affiliated entity needs the consumer's prior express permission, per the same paragraph.
• Nowhere does the rule allow the retention period to be whatever your sending tool happens to keep. The duty attaches to the sender and the liability follows it.

A vendor log is a debugging store, not an archive#

LoopMessage publishes exact retention defaults, which is rarer in this category than it should be. Message history is stored for up to 6 months by default.

Webhook history defaults to 30 days and API request history to 14 days. An account can lower any of the three, down to a minimum of 1 day.

The purpose is stated on the same page, and it is not a compliance purpose. Those records exist so the vendor can debug a request and answer a support ticket.

• Published defaults, read 21 September 2026: messages up to 6 months, webhooks up to 30 days, API request logs up to 14 days (loopmessage.com/apidocs/data-retention).
• The minimum configurable period is 1 day, and the same page warns that once historical data is deleted it cannot be restored for a later support request.
• Their words on purpose: "these records are stored solely for debugging purposes and are not shared with anyone other than your account" (loopmessage.com/apidocs/data-retention, read 21 September 2026).
• Six months of message history is well short of a five-year duty. A vendor that publishes the number at least lets you measure the gap before you sign.
• Cutting retention short also breaks product behavior that depends on message IDs, including threads, reactions and group conversations, per the matching helpdesk page.

The window that closes is the one after you cancel#

Tuco AI publishes a post-closure window and a qualifier in the same clause. Data may be kept for a limited period, given as 30 days, for reporting and operational purposes.

After that it is deleted or anonymized unless you request extended retention in writing, which puts the burden on a request most buyers never think to make.

Sendara publishes no number at all. Its privacy policy says data is kept for a reasonable period after cancellation to allow for account reactivation.

• "After the end of an engagement or account closure, we may retain data for a limited period (e.g., 30 days) for reporting and operational purposes" (tuco.ai/privacy-policy section 6.2, read 21 September 2026).
• Export on closure is offered to a portable format such as CSV, or pushed to a connected CRM, "subject to technical feasibility" (tuco.ai/terms-of-service section 6.4, read 21 September 2026).
• Sendara is blunter about access: "Upon termination, your right to access and use the Services ceases immediately" (sendara.io/terms section 10.4, read 21 September 2026).
• Sendara's retention wording is "a reasonable period to allow for account reactivation", with no published day count (sendara.io/privacy section 6, read 21 September 2026).
• Read those clauses together and the export window sits before cancellation, not after it. Access ends the day the subscription does.

Retention settings stop at the edge of the vendor#

LoopMessage adds a scope note that most retention pages leave out, and it is the honest part. The setting governs only the data that vendor stores for you.

Carriers, the destination messaging service and the recipient's own device keep their own copies under their own policies and legal obligations.

Purging your side changes your evidence rather than theirs. A deletion satisfied inside one dashboard does not reach the rest of the delivery path.

• "It does not control or delete information that may be independently retained by: Telecom carriers; Destination messaging services...; Recipient devices" (loopmessage.com/helpdesk/data-retention, read 21 September 2026).
• A consumer deletion request answered with a vendor-side purge is only as complete as that scope note allows, and the scope note is narrow.
• The asymmetry runs both ways. Your proof expires on a schedule you set while copies you do not control may outlast it.
• That is the argument for keeping the suppression record in your own system of record rather than only in a sending tool.

Losing the number loses the thread#

Sendara publishes a port-out rule that fixes the order of operations on the way out. Port-out requests are processed while the subscription is active.

Once a subscription is cancelled or expired, the number may be returned to the upstream carrier and can no longer be ported out, and a port-out fee may apply.

The number is part of the record. A prospect who replied to a line you no longer hold leaves a conversation nobody can match back to a consent date.

• "Port-out requests will be processed while your subscription is active. Once a subscription is cancelled or expired, the associated number may be returned to the upstream carrier and cannot be ported out" (sendara.io/terms section 3.6, read 21 September 2026).
• Sequence matters on exit: port the number first, export the history second, cancel third. Swap any two of those and something is gone for good.
• A number returned to a carrier can be reassigned to somebody else, which turns an old consent record into a stranger's phone.
• Get the port-out fee quoted in writing at signup rather than during an exit, when the negotiating position has already moved.

Four questions a retention page has to answer#

Retention pages in this category range from exact day counts to a single adjective. Four questions separate one kind of page from the other.

None of the four needs a lawyer to ask, and a vendor that cannot answer all four in published text is telling you something by the omission.

Run them before the contract rather than during an incident, because every one of them is cheap to answer early and expensive to discover late.

• How many days, in a number, is each record type kept while the account is active? Message history, delivery and webhook logs, and API request logs are often three different answers.
• What happens on the day the account closes, and how many days after that is the data still reachable?
• Is export a commitment or a courtesy? Wording such as subject to technical feasibility is a courtesy, and it is fair for a vendor to say so.
• What is out of scope? A page that names carriers and destination services as holding their own copies is more trustworthy than one that implies a purge is total.
• Save the page as a PDF with the date you read it. Published terms move, and the version you bought under is the one that matters in a dispute.

Keep the record where you already keep the customer#

Blue Reacher sends from your CRM, so replies and opt-outs land on the contact record inside a database you already own and already back up.

That places the consent trail, the revocation and the suppression state in the same system your reporting and your pipeline already run on.

Blue Reacher publishes its own deletion and export path rather than leaving it to a support conversation, and the timing is stated in days.

• Published on bluereacher.com/delete-data: a request is verified, the scope is confirmed in writing, and deletion from live systems happens within 30 days.
• "Want a copy first? Put EXPORT in the subject instead and we send that before anything is removed" (bluereacher.com/delete-data, last updated 10 November 2025).
• Pacing is published on the same principle: no total daily message cap, replies are never metered, and new conversations pace at 50 opted-in / 30 cold new contacts a day.
• None of this moves the duty. The five-year record stays yours to keep no matter which system holds the copy.

A ten-minute check before you sign#

Pull up four pages for any vendor you are close to buying: the privacy policy, the terms of service, any data retention documentation, and the port-out clause.

Search each one for retention, delete, export and port. The four words find the clauses that decide what you can produce two years from now.

Write the answers next to the price. A cheaper line that cannot produce a consent record on demand is not the cheaper line.

• Retention: get a number of days per record type, not a phrase. If the only answer is a reasonable period, treat the number as unknown rather than generous.
• Deletion: confirm who can trigger it, how identity is verified, and how long the deletion itself takes once accepted.
• Export: confirm the format, whether it includes replies and opt-out events rather than only contacts, and whether it survives cancellation.
• Port-out: confirm the fee and confirm that the request must be filed while the subscription is live, because that is the common rule rather than the exception.
• Then keep your own copy anyway. Every hour spent building the suppression list inside your CRM is an hour you never spend reconstructing one.

Frequently asked questions