Skip to main content

​
Set up the pre-send policy scanner and DLP rules

Every outbound message — SMS, MMS, WhatsApp, email, RCS, and the IM channels — runs through the policy scanner before it dispatches to the carrier. This guide walks the setup end to end: what the scanner checks, where you set the mode in the console and over the API, what each mode does to flagged traffic, how to work the findings it returns, and how to verify your posture before a campaign opens.
The policy scanner is a tenant-owned control. You pick the mode for your own organization; it defaults to warn (scan everything, refuse nothing), and Orbit never uses it to gate your traffic globally. This page is not legal advice — confirm your TCPA / SHAFT / GDPR / PCI obligations with counsel.

​
Step 1 — Know what the scanner checks

The scanner folds eight rule families into one verdict per message: pass, warn, or block. A channel with no applicable rules returns a clean pass. The full per-rule contract — channels, checks, and the precision validations that keep false positives rare — is on the policy scanner and DLP scanner reference pages.

​
What “scan mode” means

The verdict is the scanner’s opinion; the scan mode is your organization’s decision about what a verdict does. Three modes: Think of warn as pass with an audit trail, strict as block, and off as don’t scan. New organizations read back warn until an owner sets a mode explicitly.

​
Step 2 — Set the mode in the console or over the API

Console: open Settings → Compliance and set Policy scan mode to warn, strict, or off. The change applies to the very next send and is written to your audit log as settings.policy_scan_mode_updated. API: the mode is the one self-serve compliance toggle on the public surface. Read it (any workspace member):
200
Set it (owner role required):
A PATCH with anything outside strict, warn, off returns 422 VALIDATION_ERROR. The DLP rule’s own knobs — its category set and its block / redact / warn / off response mode — are not self-serve: they go through support, apply on the very next scan, and land on the same audit feed. The floor is credit_card, ssn, iban at severity block; ask support to add the context-gated passport category, narrow the set, or step the mode from block to redact (matched spans are substituted with typed sentinels like [REDACTED_CARD] before dispatch).

​
Step 3 — Choose how flagged messages flow

Pick the mode against what a refusal costs your traffic:
  • Start in warn. Every send proceeds and every finding lands on the message metadata and your audit feed. Watch the findings for a launch cycle so you learn your content’s real hit rate before you let the gate refuse anything.
  • Move to strict when the finding stream is clean. A block verdict then refuses the send — this is how you make SHAFT, a spam score ≥ 80, DLP, and the country sender gate a hard stop, and how TCPA quiet hours becomes enforceable on the SMS marketing lane. The DLP scanner validates every candidate twice (shape, then checksum or registry ranges) before it counts, so strict refuses actual card and identity data — not order ids, tracking codes, or phone-shaped numeral runs.
  • off is for a lane you have vetted another way. It removes every check, including the PCI/PII floor — a deliberate posture decision, not a debugging step.
There is no per-message override in any mode: no “send anyway” flag and no per-message waiver. The tenant-level mode and the DLP category set are the only supported levers.

​
Step 4 — Work the findings: SHAFT, DLP, and spam keywords

A violation entry names the rule, its severity, an operator-facing message, and a suggestion. Three worked examples: SHAFT rule hit. A US SMS body containing an alcohol term:
Fix the content, not the gate — rephrase, or move that promotion to an age-gated campaign. Hate-speech violations deliberately never echo the matched term back. DLP rule hit. The DLP detector is precision-built: a credit card candidate must pass the Luhn checksum and the card-network prefix/length table; an SSN needs a separator and valid SSA area/group/serial; an IBAN must pass the ISO 7064 mod-97 checksum and the per-country length registry. On a hit, the finding carries a category and character offsets only — never the matched text — so the scanner cannot leak a card or SSN into logs, headers, or the audit trail. Remediate by moving the regulated value to a surface you own end to end (a hosted payment page or form), never by waiving the gate. Spam-keyword score. Email and messaging bodies are scored 0–100 against a SpamAssassin-style ruleset. The lint response carries the score as a top-level spam_score field and lists every matched rule so you can rephrase the call-to-action — scores ≥ 80 are a block verdict, 60–79 a warn. Keep the body specific — name the product, the date, the action — and the score drops. The full matched-rule list comes back on every lint call, so you iterate on the draft, not on live sends.

​
Step 5 — Verify before a campaign opens

Never discover your posture mid-blast. Two read-only endpoints answer “would this go through?” without sending anything:
  • Content verdict — POST /api/v1/messages/lint runs the same scanner against a draft body and returns the same verdict, violations, spam score, and matched rules. Pass the to, subject, from_name, recipient_country, and scheduled_at hints so the lint sees the same context the send-path scan would. The dashboard compose dialog already calls it debounced; do the same in your campaign tooling.
  • Timing verdict — GET /api/v1/compliance/quiet-hours/preview answers “would this send to this recipient dispatch right now?” on the timing axis, with next_allowed_at when the window is closed. Worked per-channel calls are in the quiet-hours preview reference; the setup walkthrough is in quiet hours configuration.
Run both as the last two items of the outbound pre-flight checklist before a launch — content through lint, timing through the preview — and a blocked row on launch day is a surprise you chose.

​
Step 6 — Understand the transcript scrubber relationship

The DLP scanner is a send gate: it refuses or flags regulated data at dispatch time. It does not clean stored data. Two sibling controls cover the storage side:
  • The transcript PII scrubber strips personal data from agent conversation transcripts as they are written, so the stored record never holds the original text. It is destructive by design — it tolerates some false positives rather than hold up a conversation write. The contrast with the send gate is spelled out in DLP vs. the transcript scrubber.
  • The PII vault tokenizes contact identifiers (email, phone, SSN, national ID) so segmentation and activation run on opaque tokens instead of cleartext.
Use all three: the send gate stops regulated data from leaving, the scrubber keeps stored conversations clean, and the vault keeps raw identifiers out of audiences and exports.

​
Step 7 — Error codes and remediations

Three distinct failure surfaces come off this stack — tell a content block from a scanner outage before you retry: A refused send in strict mode also writes one audit event (policy.message_blocked) with the channel, verdict, and rule names — no matched text, ever — so your reviewers work the refusal feed as a review queue, not a retry loop. The full taxonomy is in Error codes.