# CON-060 — The opt-in language must actually say SMS or text message

> The consent wording must name text messaging explicitly rather than referring generally to being contacted.

- **Rule ID:** CON-060
- **Layer:** Consent flow (`CONSENT_FLOW`)
- **Checks:** `consent disclosure text`
- **Severity:** BLOCKING — Breaking this rule gets the submission rejected outright.
- **When it bites:** Gates approval — get this wrong and registration is refused
- **How it is detected:** AI judgement over the crawled website or policy page
- **Fix type:** Fix the website — no form edit clears it
- **Required by:** Twilio, CTIA
- **Applies:** Applies to every 10DLC registration.
- **Canonical URL:** https://ekas.io/rules/10dlc/consent-flow/con-060/

## Why this rule exists

Consent runs to a channel. Agreeing to be "contacted" or to "receive updates" does not agree to texts, and the carriers reading that wording cannot tell whether the consumer expected a phone call, an email, or nothing at all. Twilio rejects it under a code whose whole description is that the opt-in flow does not explicitly mention SMS — it is a wording defect with a one-word fix that brands miss because they know what they meant.

## How to fix it

Put the words "text messages" or "SMS" into the consent sentence itself. Done when the sentence names the channel without relying on the page around it — a heading saying "SMS signup" above a box that says "keep me updated" does not carry it.

## Example of a compliant value

```text
I agree to receive recurring automated marketing text messages (SMS) from Acme Coffee.
```

## Common mistakes

- An email opt-in reused for SMS is the usual source: the wording was written for a newsletter and the channel word was never added.

## Provider rejection codes

| Provider | Code | Resubmission allowed |
| --- | --- | --- |
| Twilio (gen2) | `30513` | yes |