Skip to main content

​
Sender identity classification model

A tenant’s sender pool usually mixes several kinds of from identity — geographic long codes, NANP toll-free numbers, numeric short codes, and alphanumeric A2P sender IDs ("Devotel", "INFO"). The sender-identity classifier resolves each of those to its true identity type so every compliance surface can label the sender under the right class instead of lumping every row under “Number”. This page is the model for that link: how the classification flows, which send-time gates apply differently per class, how you read the verdict in the dashboard, where it meets the messaging services console, and the constraints of the classification.

​
1. The classification flow

The classifier is a pure mapping: sender number → line-type classification → sender-identity type output. The line-type and reachability model owns the layer that decides the structural shape; the sender-identity resolver layers its per-class rules on top to emit exactly one of five outputs. The display layer flattens each verdict to a label — the badge component keys on these five ids.
A NANP toll-free number beats the plain E.164 long-code branch: +1 numbers carrying the 800/833/844/855/866/877/888 prefixes resolve to toll_free, not long_code. The ordering matters — toll-free senders carry their own Toll-Free Verification registration path, so labelled surfaces must distinguish them from geographic long codes.

​
2. Per-classification guidance — which gates apply differently

The classification does not itself change the gate chain; it makes the gate chain readable per class and selects which registration and gate-wiring guidance applies. Every per-sender gate remains tenant-owned (except the sole platform-global federal TCPA dialing window) — where a gate’s posture differs by sender class, the class badge makes that visible.
  • alphanumeric — mandatory in EU / MENA / APAC A2P markets. US and Canada corridors reject alphanumeric MT, so a per-country pool map must keep numeric-only pools for +1 recipients. Registration posture varies per country (none / recommended / required) — read it in Country Compliance Requirements, and register where required via Sender-ID Registration.
  • long_code — passes the alphanumeric classes above but still hits the per-country sender-type rules; on US corridors the 10DLC registration path applies instead of alphanumeric or Toll-Free Verification. Quiet-hours and RND safe-harbor gates resolve on the recipient line, not the sender class — the sender class only shapes which sender-identity rules apply, not the recipient-time gates.
  • toll_free — carries its own Toll-Free Verification registration path rather than 10DLC. Unverified toll-free senders hit their own gating before a send dispatches, which the classifier’s distinct toll_free label on the compliance panel is what makes visible.
  • short_code — gated by short-code-specific preflight; see Short-code preflight for the checklist. Their quiet-hours and opt-out posture differs from 10DLC numbers by corridor, not by the classifier itself.
  • unknown — read as an inventory anomaly, not a hunt-the-shape signal. Re-check the sender value — a malformed or unmatched sender string never classifies on send either, so verify the stored value rather than assuming a wrong type was applied.
For the quiet-hours, RND, and opt-out gates matched per surface, see Send Gates — the identity resolver only makes those gate decisions readable per sender class; ownership and wiring stay with the tenant.

​
3. How you read the classification

The Messaging Compliance Health panel’s per-sender table renders each sender under its classified type label — “Long code”, “Toll-free”, “Short code”, “Alphanumeric sender ID” — rather than a bare “Number” column. The resolver computes the class on render from the message’s from identity; label rendering lives in the component, and the classifier itself returns the raw id the chip keys on. Without this layer every row in the per-sender table would claim “Number” for an alphanumeric or short-code sender identity, or carry a wrong claim when the stored string is invalid (unknown) rather than classify it as a telephone number.

​
4. Interaction with messaging services and pools

The classifier resolves on the sender identity value — it does not know or care which construct owns the sender. An inline from, a pool member, or a messaging service’s resolved sender all pass through the same classification function. For which construct wins on a given send, see the sender construct decision model; for how services bundle defaults, see Messaging services. The classification surfaced on the compliance panel is the same verdict regardless of construct — it carries no service-specific advisory.

​
5. Constraints

  • The classification is static per sender value, not per send. A given from string always resolves to the same five-output id; the resolver holds no state between calls.
  • The classifier labels; the gates decide. Sender-type resolution tells the surfaces what a sender is. The send gate chain (quiet hours, DNC, RND, country sender-type rules) evaluates recipient-time and corridor posture separately — see Send Gates.
  • Fail-safe over assertive. unknown never throws; the badge renders muted rather than assert a wrong class on an invalid stored value.
  • Pool-type and sender-type are separate classifications. A pool’s purpose (inbound_did_route vs a2p_sender vs mixed) is derived from its membership and documented on Sender resolution; the identity classifier classifies each member’s type independently. Both feeds reclaim per-sender compliance panels.
  • Class movements are rare and manual. An invalid value stays unknown; a sender you re-register as toll-free verified changes nothing in the classification layer — verification state lives elsewhere, the type does not change.