What Is SMS Compliance? A Practical Guide for Businesses

Here’s the compliance conversation most teams have too late: a lawyer raises a TCPA concern after the campaign has run, and the first question — “can you show me how you collected consent?” — lands on a CRM admin who never set up a consent field. The program isn’t illegal because someone wanted to break the rules. It’s exposed because nobody mapped the compliance requirements to the actual workflow before the sends started.

SMS compliance isn’t complicated once you understand the mechanism — what TCPA actually requires, where carriers add their own rules on top, and how opt-in and opt-out need to function inside your CRM. With 360 SMS App handling consent tracking, opt-out enforcement, and message logging natively inside Salesforce, the compliance infrastructure sits where your team already works. This guide covers how it all fits together — and what breaks when any piece is missing. For teams already running SMS messaging in Salesforce, this is the setup you need to get right.

What TCPA Actually Requires for SMS

The Telephone Consumer Protection Act was written in 1991 — long before text messaging existed. The FCC has since extended it to cover SMS, and the courts have been aggressive about applying it. The result is a law with real teeth: $500 per violation for unintentional breaches, $1,500 per violation if a violation is found to be willful. Those numbers multiply fast across a bulk send.

TCPA compliance for SMS rests on three requirements. Prior express written consent — obtained before any marketing message is sent, with the consumer clearly agreeing to receive texts from your specific business. A clear disclosure at the point of opt-in explaining the message frequency, that message and data rates may apply, and how to opt out. And a working opt-out mechanism — STOP must actually stop messages, immediately, every time.

The “prior express written consent” bar is higher than most teams realize. A pre-checked box doesn’t satisfy it. A general privacy policy agreement doesn’t satisfy it. The FCC is explicit: it requires a clear and conspicuous disclosure, the consumer’s agreement to receive autodialed or prerecorded calls or texts, and a signature — electronic signatures are fine. That’s the standard your opt-in capture needs to meet before any marketing text goes out.

One nuance worth knowing: TCPA distinguishes between marketing texts and informational or transactional texts. Appointment confirmations, order updates, and account alerts have a lower consent bar — prior express consent (not written) is sufficient. The higher “written” standard only kicks in for promotional content. Most enterprise SMS programmes mix both types, which is where the consent tiers get blurry if nobody mapped them out explicitly.

The Carrier Layer: Rules TCPA Doesn’t Cover

TCPA is the legal floor. Carriers — AT&T, Verizon, T-Mobile — add their own rules on top, and their enforcement mechanism isn’t a lawsuit. It’s filtering. Carriers actively monitor SMS traffic and will block or throttle traffic that triggers their spam detection, often without notifying the sender. You can be fully TCPA-compliant and still have a deliverability problem if you’re running into carrier rules.

TCPA compliance gets you legal. Carrier compliance gets your messages delivered. You need both.

The main carrier-level requirement is 10DLC registration — 10-digit long code registration through The Campaign Registry. Any US business sending application-to-person SMS at volume needs to register their brand and their message campaigns through this system. Unregistered 10DLC traffic gets filtered aggressively. Registration also enforces a message-per-day cap per campaign, so teams running high-volume sends need to plan their campaign structure accordingly.

Beyond registration, carriers look at content patterns — URLs in messages, promotional language density, message frequency per number, and opt-out handling. A message that includes a URL-shortened link with no business identification, sends at high frequency to cold numbers, and has no STOP instruction is going to flag carrier filters regardless of TCPA status. The practical implication: always identify your business in the message, always include a STOP instruction, avoid URL shorteners that obscure the destination, and don’t send the same content at high frequency from a single number.

How the Opt-In and Opt-Out Mechanism Actually Works

Opt-in and opt-out aren’t administrative formalities. They’re the core of the compliance mechanism — and the part most Salesforce-based SMS programmes handle badly, usually because opt-out processing isn’t wired into the CRM correctly.

Opt-in has three valid collection methods for SMS. Web form with explicit SMS consent language — not a general contact form, but a form with clear disclosure that the user is agreeing to texts. Keyword opt-in — a contact texts a keyword to your number and receives a confirmation message that confirms enrolment and explains opt-out. Double opt-in — a contact provides their number and then confirms via a reply — this is the strongest consent record and the hardest to dispute. 360 SMS App stores all three consent types as fields on the Salesforce contact record, which means your consent audit trail lives where your team already works.

Opt-out is where teams get into trouble. TCPA and carrier rules both require that STOP — and variants like STOPALL, UNSUBSCRIBE, CANCEL, END, QUIT — immediately suppresses all future messages. Immediately means immediately. A system that processes opt-outs in a nightly batch run is non-compliant. With 360 SMS App, inbound STOP replies trigger an automatic opt-out update on the contact record in real time, and the contact is excluded from all subsequent sends without any manual intervention. The opt-out status is visible on the record so reps don’t accidentally send manual messages to opted-out contacts.

GDPR, CCPA, and State-Level Rules: What Changes Outside the US

TCPA is the dominant framework for US-based SMS compliance, but it’s not the only one. If you’re texting contacts in the EU or California — or if your product collects data from those regions regardless of where you operate — GDPR and CCPA add requirements on top of what TCPA already mandates.

GDPR requires a lawful basis for processing personal data — and for marketing communications, “legitimate interests” rarely holds up. You need explicit consent, and the standard is even stricter than TCPA: granular, specific, freely given, and revocable at any time. GDPR also gives individuals the right to erasure — if a contact asks to be forgotten, you need to be able to action that across your CRM data, not just suppress future sends. For Salesforce-based SMS programmes, that means the consent record and all associated message history needs to be deletable from the contact record without breaking other CRM data.

CCPA — and its successor, CPRA — applies to California residents and gives them the right to opt out of the sale or sharing of their personal data, plus enhanced disclosure rights. It’s less prescriptive than GDPR about consent for marketing but more aggressive about data rights. The practical requirement for SMS programmes is clear disclosure in your privacy policy and a functioning mechanism to honour data deletion requests. 360 SMS App’s native Salesforce architecture means consent and message data is stored on the standard Salesforce data model — making GDPR erasure requests and CCPA deletion requests manageable through the same CRM tools your team already uses for data management.

The Five Compliance Gaps Most Salesforce SMS Programmes Have

I’d argue the compliance piece gets over-explained in terms of the law and under-explained in terms of the operational gaps. Here’s what actually breaks in real Salesforce SMS setups, in order of how often it comes up.

No consent field on the Contact record. The most common gap — teams have collected consent somewhere, but it’s not a structured field in Salesforce. When the auditor asks to see consent records, the admin can’t run a report. 360 SMS App adds dedicated consent fields to the Contact record, so consent status is queryable, reportable, and auditable without any custom development.

Opt-out processing depends on a human. Someone sees the STOP reply in the inbox and manually updates the record. That works until a busy day — then the rep marks it as handled and forgets to update the field, and the contact gets another message. Automated opt-out processing via 360 SMS App removes the human dependency entirely. The inbound STOP triggers a real-time field update; no manual step exists to be forgotten.

Campaigns send to contacts with no consent record. A list is built from a Salesforce report, the report doesn’t filter on SMS opt-in status, and opted-out contacts get included. 360 SMS App’s consent management layer prevents sends to contacts who are opted out or who have no recorded consent — the suppression is built into the send logic, not a manual pre-send review step. You can see how this connects to broader SMS compliance in Salesforce across different campaign types.

10DLC registration is missing or miscategorised. The brand is registered but the campaign type doesn’t match the actual message content — a “transactional” campaign registration being used for promotional sends, for example. Carriers will catch this eventually; the fix is to register specific campaigns for specific message types and keep registration documentation with the Salesforce admin who manages the SMS programme.

No message log available for audit. A contact disputes receiving a text. The team can’t produce a record of what was sent, when, and from which campaign. Every message sent through 360 SMS App is logged on the Salesforce record — contact, timestamp, message content, and direction. The audit trail is automatic. For teams running TCPA and GDPR compliance simultaneously, that log is the single most important compliance asset you have.

Building the Compliance Infrastructure in Salesforce

The right infrastructure makes compliance a background condition rather than a pre-send checklist. Here’s what a properly built Salesforce SMS compliance setup looks like when it’s working.

Consent fields on every relevant object — Contact, Lead, and any custom objects your programme touches. These fields store consent status (opted in, opted out, no record), the consent collection method, the consent collection date, and the source (web form, keyword opt-in, verbal with rep logging). 360 SMS App provisions these fields natively; they appear on the standard record layout and are reportable immediately without any custom field creation on your side.

Automated opt-out handling — inbound STOP replies trigger a real-time field update and suppress the contact from all future automated sends. The same suppression applies to manual sends; a rep attempting to text an opted-out contact sees a warning before the message goes out. No batch processing, no overnight runs, no dependency on a rep remembering to update a field.

Consent-filtered send logic — any campaign or automation run through 360 SMS App checks consent status at send time, not at list-build time. A contact can opt out between when a list is pulled and when the campaign fires; the real-time check catches that case and excludes the contact. This matters particularly for drip sequences — a contact who opts out mid-sequence stops receiving messages immediately, regardless of where they are in the sequence. For teams managing SMS opt-in and opt-out across multiple campaigns, this is the difference between a manageable compliance programme and a fire drill.

Full message logging — every outbound and inbound message recorded on the record with timestamp, direction, content, and campaign association. The log is queryable through standard Salesforce reports; you can pull every text sent to a specific contact over any date range in under two minutes. That’s your audit trail. It doesn’t require a separate compliance tool or a data export request to your vendor — it’s in the CRM.