# MSG-DESC-QUALITY — Campaign description must explain who, what, and how they opted in

> The description must state who receives the messages, what those messages contain, and how recipients consented.

- **Rule ID:** MSG-DESC-QUALITY
- **Layer:** Message content (`MESSAGE_CONTENT`)
- **Checks:** `campaign.description`
- **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 submitted form
- **Fix type:** Fix the field — a better value in the form clears it
- **Required by:** TCR, Twilio, Bandwidth, AWS
- **Applies:** Applies to every 10DLC registration.
- **Canonical URL:** https://ekas.io/rules/10dlc/message-content/msg-desc-quality/

## Why this rule exists

The description is the first thing a reviewer reads and the basis on which everything else is judged. A description that restates the use-case name gives them nothing to verify against, and is the most frequently cited reason for a campaign-description rejection.

## How to fix it

Write three things explicitly: the audience, the message content, and the opt-in source. Name the business and the website rather than describing a generic program.

## Example of a compliant value

```text
Acme Coffee sends weekly promotional offers, new product announcements, and loyalty rewards updates to customers who opted in via the checkout consent checkbox at acmecoffee.com or in person at our Mission St store. Messages include discount codes and store event invitations.
```

## Common mistakes

- "Marketing messages to our customers" restates the use case and will be rejected as too vague.

## Provider rejection codes

| Provider | Code | Resubmission allowed |
| --- | --- | --- |
| Twilio (gen1) | `30886` | yes |