SMS Privacy Policy Requirements: What Carriers Check Before Approval

Twilio's guide to the information needed for registration lists the conditions directly. The privacy policy must be publicly accessible without a login. It must state that mobile numbers will not be shared with third parties. It must disclose message frequency. It must include the statement that message and data rates may apply.

Bandwidth's vetting guide, dated 20 April 2026, adds a description of the content. The policy should describe how consumer data is used and shared and how people can contact the sender. It should state that mobile information will not be shared with third parties or affiliates for marketing, and that opt-in data is excluded from any sharing the policy does allow.

For toll-free numbers, Telnyx states the same rule in its own words: the privacy policy link must lead to a policy stating that text opt-in data will not be sold or shared with third parties. It also checks that the website footer links to the policy.

CTIA's Messaging Principles and Best Practices, dated May 2023, is the base document. Section 5.2.1 says message senders should maintain and conspicuously display a privacy policy that people can reach easily, for example through clearly labeled links, and that clearly describes how the sender may collect, use and share their information. It says all applicable privacy policies should be referenced in and accessible from the initial call to action.

The same document says in section 5.1.4 that senders should not use opt-in lists that have been rented, sold or shared, and in section 5.1.2.2 that an opt-in should not be transferable. The registration checks on sharing follow from those two lines: if consent cannot be passed on, a policy that reserves the right to pass on the number contradicts the program.

CTIA also says a sender's privacy policy should be consistent with applicable privacy law, and that its treatment of information should match the policy. The guidelines do not say what those laws require. They are industry principles, and CTIA states that its examples are not legal advice.

Many website policies contain a standard paragraph saying personal information may be shared with partners, affiliates or advertisers. To a registration reviewer, a phone number collected for texting is personal information, so that paragraph reads as permission to share it.

HighLevel's guide to rejection reasons lists code 30932 for a privacy policy that allows opt-in data to be shared with third parties for marketing. Its fix is to update the policy to state that mobile information is not shared with third parties for marketing. Twilio's support article on rejected campaigns gives similar guidance under the terms and conditions code 30882: people should give consent directly to the brand, and mobile opt-in data should not be shared with third parties or affiliates for marketing or promotional purposes.

A rejection-code list published through VoIP Docs goes further. It has one code for a policy that does not state opt-in data is not shared, another for a policy that allows sharing with third parties even with consent, and a third for a policy containing a disallowed sharing exception. For the second, its stated fix is to remove the exception, on the basis that opt-in data may never be shared, sold or rented.

The usual repair is a carve-out. The general sharing clause stays for other data, and a separate paragraph says that mobile numbers, text messaging consent and opt-in data are excluded from it. That sentence has to be true of how the business actually handles the data.

Bandwidth's vetting guide lists what the terms must include: the brand name, the message types, the frequency, the notice that message and data rates may apply, a customer care contact, and opt-out instructions. The link is supplied during registration.

Twilio's guide sets conditions on where the terms live. They must be publicly accessible with no login or download required, and hosted on the same domain as the business website. It says the registry rejects PDF files behind an authentication wall and pages that redirect to another domain.

The VoIP Docs list has a code for a submission missing the terms link, the privacy link or support instructions. Its fix is to add both links and explain how people get help, for example by replying HELP.

• The brand name as registered
• The kinds of messages the program sends
• How often messages are sent
• The notice that message and data rates may apply
• A customer care contact, such as a phone number or email address
• How to opt out, using STOP

CTIA's standard is that the policy is referenced in and reachable from the initial call to action. In practice that means a link beside the consent sentence on the form where the phone number is entered.

The rejection lists check this from several directions. HighLevel lists code 30908 for a privacy policy that was not provided or could not be found, and its fix is to make the policy accessible and link it directly in the message flow. The VoIP Docs list has a code for an opt-in form that does not explain how to find the privacy policy and another for a verbal opt-in script with no privacy disclaimer or pointer.

The link also goes into the registration itself. Twilio's guide says to put the privacy policy and terms addresses in the opt-in description when using its console, and into dedicated fields when using its API.

The address has to work when the reviewer opens it. The VoIP Docs list has codes for a link that does not lead to a live site, a link that does not show an actual privacy policy, and a link that fails a security certificate check.

Bandwidth's guide says that if the privacy policy and terms cannot be found publicly, they should be attached to the registration, and that the terms can be supplied as a PDF when there is no website. It also asks for some online presence, which can be a social media profile.

The VoIP Docs list has a code for opt-ins collected in person or by phone with no web policy. Its fix is to attach a compliant policy example in the registry record or send it to the provider.

Providers differ here. Twilio's guide says the terms should be on the business's own domain and warns that documents behind a login are rejected. HighLevel's rejection list has a code for a website that is only a form with no business context. A client with no real website is a harder registration on every platform we read about.

The VoIP Docs list includes a code for a privacy policy that mentions marketing when marketing is not one of the registered use cases. The stated fix is to add marketing as a use case or remove the wording.

The same logic applies across the three documents a reviewer reads together: the form, the policy and the terms. If the form says numbers are kept private and the policy allows sharing, the two conflict. HighLevel's legacy code list includes one for disallowed content or third-party data sharing found in either the privacy policy or the terms.

This is a common trap for agencies that reuse one template across clients. A template written for a retailer that sends promotions will carry marketing language into the policy of a clinic that only sends reminders.

The checks in this post are conditions for using a messaging channel. They are applied by providers and vetting partners on behalf of carriers, and the penalty for failing them is a rejected registration or blocked messages.

State privacy laws, sector rules and the federal rules on calls and texts are separate. A privacy policy has other jobs under those laws, and the sources we read for this post do not address them. CTIA's own guidelines point outward on this, saying a policy should be consistent with applicable privacy law.

The reverse is also true. A policy written carefully by a lawyer for a state privacy statute can still fail registration if it contains a general sharing clause and no carve-out for text opt-in data.