Skip to main content

​
The outbound gate chain: messages

A send goes through only when every gate in the outbound gate chain says yes. The gates are a deliberately ordered stack — engagement gates first, quality gates next, compliance gates last — so a cheap recipient-state check absorbs a send before any policy evaluation burns quota. This page names the chain and the ordering decision. The dashboard exposes this surface under Messages → Settings and Messages → Blocklist; the API side is the /message-suppression policy and the /messages/blocklist ledger the send path reads. The full compliance carve-outs (wallet pause, quiet hours, country rules, DNC/RND/RMD, TFV/10DLC) are the subject of the sister concept Send-gate decision fork — this page covers the four gates the send-mail path reads plus the blocklist, and how they interlock with that fork.

​
Gate vs gate — what each one decides

The blocklist (/messages/blocklist) sits upstream of the chain: a destination on the org-side list is rejected with 422 CHANNEL_BLOCKED_DESTINATION before any gate above runs, so an operator ban takes precedence over every content-and-consent policy. Manage that list under Messages → Blocklist in the dashboard; manage the content policy under Messages → Settings → Message suppression — a thin wrapper over the GET / PUT / DELETE /api/v1/message-suppression route.

​
How checks are ordered: engagement → quality → compliance

The chain evaluates in three tiers, and a refused send never reaches the later tiers:
  1. Engagement. The interaction gate reads the contact record — per-channel preference flags, global opt-out state, consent history. These are cheap reads against recipient state and absorb most refused traffic before any downstream policy runs.
  2. Quality. Keyword rules evaluate the body brand-for-brand; message suppression claims a content hash over (recipient, channel, body); frequency caps test-and-increment the per-category counter. Quality gates are what separates “the recipient is reachable” from “this send is worth sending.”
  3. Compliance. The full fork — quiet hours, country rules, DNC/RND/RMD, HIPAA BAA, fraud shield, spend cap — is what Send-gate decision fork walks. It runs last because its failures are the most expensive to fix: each gate has its own registry, registry-fed feed, or per-country profile check.
The ordering consequence to internalize: a suppressed duplicate never burns a frequency-cap slot, and an opted-out recipient never reaches either check. Engagement absorbs the recipient before quality evaluates the body; the compliance fork only sees a send every earlier gate already accepted.

​
Verdict types: block, flag, pass

Each gate answers pass, flag, or block, and the downstream event record differs per verdict:
  • Pass — the send advances. No event is emitted for a pass on an engagement or quality gate beyond the message’s normal queued → sent → delivered lifecycle.
  • Flag — the send can still leave, but the chain records a structured advisory. Campaign preflight’s ready: false yellow warning and the suppressed-duplicate skipped outcome are flags: the batch keeps moving, and the flag is what the delivery log shows instead of an error.
  • Block — the send is refused at the gate with a 4xx envelope whose error.code names the gate. Direct sends return that 4xx; a batch send to a blocked member fails its own row while the rest of the batch proceeds.
For campaign traffic, a block at the recipient list level lands as a skipped outcome on the message (an operational sentinel) — the campaign continues and the blocked row is visible in the delivery log, never a campaign-level abort.

​
Regional quirks

A small set of markets overlay send-side rules on the chain. They only run when the tenant opted into that region’s gate(s) under Organization → Settings → regional_send_gates, and each is one more quality-tier check the chain reads after the global gates above:
  • Brazil, Saudi Arabia, UAE, Singapore — an alphanumeric sender-ID requires a registry-approved entry: MESSAGING_BR/SA/AE/SG_SENDER_NOT_REGISTERED rejects the send 422. Attach the approved sender under Channels → Senders.
  • India (TRAI DLT) — every A2P SMS must carry a metadata.dlt_template_id and the body must match the approved template; a missing field or a mismatched body rejects with MESSAGING_IN_DLT_TEMPLATE_REQUIRED / MESSAGING_IN_DLT_CONTENT_MISMATCH 422.
  • Mexico (NOM-184) — promotional A2P SMS needs a consent record with metadata.nom184=true on the recipient.
  • Japan — carriers strip URLs from A2P SMS aggressively, but non-deterministically; the gate surfaces a flag, not a block, so dashboard compose can hint “replace the URL” without silently killing traffic.

​
Where to drill down

The ordering decision lives in one fork; the four per-gate guides own their own fix pages: