# CMP-EMOJI — Registration fields must not contain emoji

> No campaign registration field may contain an emoji character.

- **Rule ID:** CMP-EMOJI
- **Layer:** Campaign (`CAMPAIGN`)
- **Checks:** `campaign.* (all text fields)`
- **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:** Deterministic (settled in code from the submitted values)
- **Fix type:** Fix the field — a better value in the form clears it
- **Required by:** TCR
- **Applies:** Applies to every 10DLC registration.
- **Canonical URL:** https://ekas.io/rules/10dlc/campaign/cmp-emoji/

## Why this rule exists

Emoji are fine in live message traffic but rejected inside the registration record itself, because the downstream systems that parse and display campaign metadata do not handle them consistently. It surfaces only in the DCA vetting reason list rather than in any provider documentation, which is why generic implementations never check for it — and why a generator that writes a cheerful emoji into a description silently creates a rejection.

## How to fix it

Remove emoji from the registration fields. They are allowed in live message traffic, but not in the registration record itself.

## Example of a compliant value

```text
Acme Coffee sends weekly promotional offers to customers who opted in at checkout.
```

## Provider rejection codes

| Provider | Code | Resubmission allowed |
| --- | --- | --- |
| TCR/DCA | `6103` | yes |

## Notes

Surfaces only in the DCA vetting reason list, not in any provider doc — which is why generic implementations miss it entirely.