> ## Documentation Index
> Fetch the complete documentation index at: https://docs.orbit.devotel.io/llms.txt
> Use this file to discover all available pages before exploring further.

# Troubleshooting: TEN_DLC_NOT_REGISTERED on US SMS sends

> The pre-send gate returns TEN_DLC_NOT_REGISTERED when a US 10-digit long code sender has no approved TCR brand+campaign registration. Diagnose the scope, decide between register/fix-route/strict-mode, and clear the advisory from your sends.

# Troubleshooting: TEN\_DLC\_NOT\_REGISTERED on US SMS sends

Your SMS request returned HTTP 422 with code `TEN_DLC_NOT_REGISTERED`, or
the send went through but carries a `ten_dlc_advisory` on the message
metadata. Both point to the same finding: the pre-send gate found no
approved TCR (The Campaign Registry) brand+campaign registration for the
sending number. The full code table is in the
[messaging error codes reference](/reference/error-codes); this page maps
the gate's verdict to the corrective step.

<Note>
  Since February 2025 every US carrier (AT\&T, T-Mobile, Verizon) silently
  filters A2P SMS sent from an unregistered 10-digit long code (10DLC).
  The gate is protective: it stops you from paying for a message the
  carrier will drop.
</Note>

## Two ways the verdict surfaces

How the gate treats an unregistered sender depends on your tenant's
settings:

* **HTTP 422 `TEN_DLC_NOT_REGISTERED`** — your tenant has strict
  enforcement enabled (`Settings → Compliance → 10DLC`). The send is
  rejected at the platform edge; no message row is created and no charge
  is made.
* **Advisory in the response** — with strict enforcement off (the
  default), the send is handed to delivery anyway, and the verdict comes
  back as a structured `ten_dlc_advisory` on the message metadata:

  ```json theme={null}
  {
    "ten_dlc_advisory": {
      "code": "TEN_DLC_NOT_REGISTERED",
      "reason": "not_registered",
      "from": "+1212****",
      "to": "+1415****",
      "message": "Sender +1212**** is a US 10-digit long code (10DLC) that is not registered with The Campaign Registry (TCR). US carriers may filter unregistered A2P SMS. The message is being dispatched, but register a brand + campaign to protect deliverability.",
      "register_url": "/settings/compliance/10dlc"
    }
  }
  ```

The gate applies to SMS channel sends only, and only when the sender is a
US 10-digit long code. It is a no-op for toll-free numbers (covered by the
TFV gate), short codes, alphanumeric senders, the platform-default US
number, and non-US recipients.

## Diagnose the scope

Answer three questions before you touch anything:

1. **Which sender?** The 422 error details and the advisory carry the
   masked sender in `from`. If you omit `from`, the pipeline resolves to
   the platform-default US number, which is registered at the platform
   level and exempt from this gate — so the flag only appears when you
   send from one of your own numbers.
2. **Is this sender in the 10DLC class?** A US toll-free number routes
   through the TFV gate instead; a short code is registered upstream
   outside TCR. If the flagged sender you expect to be toll-free or a
   short code is being treated as a 10DLC, check the number format you
   sent — the gate classifies by the E.164 digits, not by what your
   inventory calls the number.
3. **Is any of your org's campaigns approved?** Read the status endpoint:

   ```bash theme={null}
   curl https://api.orbit.devotel.io/api/v1/compliance/10dlc/campaigns/CXXXXXX/status \
     -H "X-API-Key: $ORBIT_API_KEY"
   ```

   The gate counts the org as registered only when at least one campaign
   id sits in a terminal-approved TCR state. A campaign at `PENDING`,
   `FAILED`, suspended, or never reconciled does not count.

## Symptom → cause → fix

| Symptom                                                                                           | Cause                                                                                                                                                                         | Fix                                                                                                                                                                                                                   |
| ------------------------------------------------------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| `FAILED` campaign; every send flagged                                                             | The campaign you filed was rejected, so no approved campaign exists                                                                                                           | Read `rejectionReason` from the status response and work the fix table in [10DLC campaign rejected](/troubleshooting/10dlc-campaign-rejection), then resubmit; until a campaign is approved the gate flags every send |
| `PENDING` campaign stuck past typical review time                                                 | A pending campaign is not registered; the gate keeps flagging                                                                                                                 | Watch the dashboard notification or poll the status endpoint; do not treat a long `PENDING` as approved. If it never closes, check for a resubmission-blocking cause with support                                     |
| Approved campaign for brand A, but you send from a number tied to unregistered brand B            | The gate checks the org's approved registrations as a whole, but the fix is always a registration that covers the actual sending number                                       | Register the brand+campaign that covers the number you send from; approvals do not transfer across brands                                                                                                             |
| You expected the platform-default sender to cover you, but sent from your own unregistered number | The platform pool exemption applies only when the pipeline resolves the sender to the platform-owned default — an explicit `from` of your own number routes through this gate | Omit `from` to use the platform default, or register your own number                                                                                                                                                  |
| HTTP 422 (strict mode) but the same send in the dashboard proceeds                                | Dashboard sends use the checker against the same verdict; a 422 means strict enforcement is on and both paths should refuse                                                   | Confirm with support which toggle state you are on — `Settings → Compliance → 10DLC` shows the current mode                                                                                                           |

## Choose the resolution path

Three legitimate resolutions, in order of preference:

1. **Register the sender.** File a TCR brand + campaign for the number —
   the [10DLC registration guide](/guides/10dlc-registration) walks the
   full flow (brand → campaign → approval, expected 1–5 business days).
   This is the durable fix and the only one that protects deliverability.
2. **Route through an exempt sender.** Omit `from` to fall back to the
   platform-default US number, or move US traffic to a toll-free number
   (subject to TFV — see
   [Toll-free TFV required](/troubleshooting/toll-free-tfv-required)) or
   a short code. Use this when you cannot finish registration yet and
   cannot afford carrier filtering.
3. **Keep strict mode of your own choosing.** The advisory is a nudge,
   the 422 is a refuse. If you opted into strict enforcement previously
   and now want sends to dispatch with the advisory while registration
   proceeds, turn the toggle off; if you previously ran advisory and your
   compliance policy requires a hard block, turn it on.

## What not to do

* **Do not keep retrying on the same verdict.** The gate reads your
  org's registration state; until an approved campaign exists the result
  is the same, and strict-mode retries just re-eat the 422.
* **Do not treat `PENDING` as passed.** Expect the advisory/422 to clear
  only when a campaign is in a terminal-approved state — the gate never
  accepts a pending one.
* **Do not stop at "the campaign is approved" if one carrier still
  reads `REVIEW`/`FAILED`.** The `mnoStatuses` map is per-carrier; hold
  traffic to any carrier still not approved until that entry flips. The
  [message undelivered or failed](/troubleshooting/message-undelivered-failed)
  page covers the send-side symptoms when registered traffic still fails.

## When to escalate

Escalate to [support@devotel.io](mailto:support@devotel.io) when you have
an approved campaign in `status` but the verdict still flags your sends,
or when the status endpoint shows no campaigns at all despite a
submission that returned a campaign id. Include:

1. Your **tenant ID** (dashboard → Settings → Organization, or
   `organizationId` on `GET /api/v1/me`).
2. The **masked sender** from the error `details.from` (or the advisory's
   `from`).
3. The full `GET .../campaigns/<id>/status` response so support can see
   the reconciliation state.

## See also

* [10DLC registration guide](/guides/10dlc-registration) — the full
  brand → campaign → approval flow, use-case codes, and throughput tiers
* [10DLC campaign rejected](/troubleshooting/10dlc-campaign-rejection) —
  the resubmission-side page this one defers to
* [Toll-free TFV required](/troubleshooting/toll-free-tfv-required) — the
  sibling US sender-registration gate for toll-free numbers
* [Message undelivered or failed](/troubleshooting/message-undelivered-failed) —
  the send-side page for traffic that is registered and still fails