> ## 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.

# Outbound gate chain: the interaction, campaign-preflight, keyword-rules, frequency-caps, and message-suppression stack

> The named outbound gate chain for messages: the engagement gates (interaction surface, campaign pre-flight), the quality gates (keyword rules, duplicate-content suppression), and the compliance gates (blocklist, opt-out, consent) — in the order send-mail reads them — plus the block/flag/pass verdict vocabulary and regional quirks.

# 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](/compliance/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

| Gate                    | Question it answers                                                                                                                | Verdict it returns                                                                                                                     |
| ----------------------- | ---------------------------------------------------------------------------------------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------- |
| **Interaction gate**    | Is the recipient-side contact state readable at send time — opt-outs, preferences, consent flags that live on the contact profile? | Pass, or a **block** (`422 RECIPIENT_OPTED_OUT` / a `skipped: opted_out` row)                                                          |
| **Campaign preflight**  | Does the org have an approved sender for this channel, and a compliance profile for the destination country?                       | Pass, or a **flag** (a yellow warning panel in the campaign wizard — the send still runs and the send-time fork remains authoritative) |
| **Keyword rules**       | Does the body match a brand-level keyword the operation declared — an opt-in/opt-out phrase, or a spam-policy word?                | Pass, or a **block** (an opt-out keyword flips the contact's consent flags pre-dispatch and writes a suppression row)                  |
| **Message suppression** | Has this exact body already reached this contact on this channel inside the policy window?                                         | Pass, or a **flagged skip** — the send reports `status: "skipped"`, reason `duplicate_content`, and the batch continues                |
| **Frequency caps**      | Has this contact already received too many sends of this category inside the rolling window?                                       | Pass, or a **block** (`429 FREQUENCY_CAP_EXCEEDED` / `skipped: frequency_capped`)                                                      |

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](/compliance/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:

* [Send-gate decision fork](/compliance/send-gate-decision-fork) — the
  full compliance fork (quiet hours, DNC, RND, TFV/10DLC, spend caps) and
  per-code fix pages.
* [Outbound compliance pre-flight checklist](/guides/send-gates-preflight-checklist) —
  the launch-time walk across every gate.
* [Message suppression guide](/guides/message-suppression) — the
  duplicate-content policy end-to-end.
* [Messages blocklist guide](/guides/messages-blocklist) — the org-side
  destination ban that runs upstream of the chain.
* [Opt-out & suppression lists](/compliance/opt-out-suppression) — the
  recipient-initiated consent records the interaction gate reads.
* [Frequency caps](/guides/frequency-caps) — the per-category counter.