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

# Email quiet hours vs the marketing/lifecycle classification: where timezone restraint stops and consent starts

> Why email has no federally mandated send window — quiet hours are a tenant opt-in here — how a classification of marketing vs lifecycle decides which rules apply to the recipient, and how the preference center versus suppression semantics bind the consent record.

# Email quiet hours vs the marketing/lifecycle classification

Two orthogonal choices decide what happens to an outbound email:

1. **The send-window gate** — quiet hours on in `organizations.settings.quiet_hours.email`. Tenant-owned, off by default. When it fires, a deferred dispatch lands on `skipped` with `quiet_hours` as the reason, carrying a `next_allowed_at` you can read back from the send chain.
2. **The recipient classification** — first-party policy your tenant declares per send: `metadata.traffic_lane: "marketing"` or `"transactional"` (lifecycle), implemented per the [traffic-lane resolution model](/concepts/message-priority-traffic-lanes). This controls which suppression layer binds and what evidence the export ledger must hold, not whether the recipient gets the email in their timezone — the timezone gates you set.

Neither choice silences the other. The gate can defer a transactional OTP send the same way it defers a campaign burst; the classification has no effect on the window arithmetic. Read both together, per send.

This page is the map that locates where the regulatory posture and the window gates intersect. The chain of gates a send walks, with quiet hours positioned in order, is covered by [Outbound send gating: the tenant-owned controls](/concepts/send-gating-and-quiet-hours). Here the classification determines which compliance burden attaches and which recipient-state surface binds.

## Marketing email: the regulatory fronts and their boundaries

A recipient classified as `marketing` enters an opt-in / opt-out posture specific to the jurisdiction you acquired them in — the classification is a property of your list and purpose, and it decides which fronts bind:

* **United States** — sender-side statute. Every commercial email must carry true header identity, a non-deceptive subject, a working unsubscribe mechanism, and an opt-out honored within 10 business days. The seven requirements map to surfaces you already own; the mechanics per requirement are in [US CAN-SPAM Compliance for Email](/compliance/can-spam). `List-Unsubscribe` and in-body unsubscribe links ride every outbound email automatically.
* **Canada** — consent-first statute. You need documented express consent, or a narrow implied-consent carve-out, before you send. Unsubscribe is mandatory and must remain functional for 60 days. The consent ledger entry you build at capture is the evidence you cite. The tiers are mapped in [CASL (Canada's Anti-Spam Legislation)](/compliance/casl-canada-anti-spam).
* **United Kingdom and EU** — PECR sits beside UK GDPR: direct marketing by email requires consent unless the narrow "soft opt-in" for existing customers applies. Cross-channel posture and unsubscribe handling are mapped in [UK PECR and ePrivacy](/compliance/uk-pecr-eprivacy). Elsewhere in the EEA, the ePrivacy Directive overlays GDPR.

The through line across all three: no federal time-of-day restriction binds email — the window question is a tenant decision (next section). The heavy burden is on consent-holding and unsubscribe honoring, and the suppression surfaces exports below bind.

## Transactional / lifecycle email: the exemption

Lifecycle traffic — order confirmations, receipts, account and security alerts, OTP — is exempt from marketing consent burdens on opt-in statutes like CAN-SPAM, because the message is primarily about an existing transaction, not commercial promotion. The unsubscribe mechanism may be omitted; a preference-center-based unsubscribe still suffices. The [Consent & Suppression model](/concepts/consent-and-suppression-model) describes how those preference-center entries and consent records interact on one recipient state.

The same classification is resolved for throughput routing and gating precedence. A direct-API send defaults to `transactional` when you give no metadata; campaign and journey sends are read as `metadata.traffic_lane: "marketing"` unless you mark them otherwise. This is individually controllable, per send — a service announcement drip stays transactional; a win-back campaign accepts the marketing classification.

## Where the tenant picks each posture

Both knobs live in the same tenant-owned surfaces:

* **Quiet hours** — enable per channel, `organizations.settings.quiet_hours.email.enabled`, with optional per-channel hours and `unknown_timezone_policy` at the org level. On a deferred send the dispatch records `status: "skipped"` with `quiet_hours` as the reason; the [quiet-hours configuration guide](/guides/quiet-hours-configuration) walks the two knobs and timezone-resolution order. The full gate stack — how this composes with wallet pause, frequency caps, block lists — is one chain documented in [Outbound send gating](/concepts/send-gating-and-quiet-hours). Preview the verdict before sending via [Send gates](/compliance/send-gates). Align cadence with windows using [Channel-rate overrides](/compliance/channel-rate-overrides).
* **Classification** — declare per send with `metadata.traffic_lane: "marketing"` | `"transactional"`. The scheduler and the send service resolve the lane identically; the result drives the suppression semantics below and the traffic-lane routing in [Message priority and traffic lanes](/concepts/message-priority-traffic-lanes).

Both are yours to carry. The platform owns exactly one platform-wide time gate — the TCPA federal voice dialing window documented in [Federal vs state vs tenant voice gates: the three-layer stack](/concepts/federal-vs-state-vs-tenant-voice-gates) and [TCPA federal voice guard: the one 422 you can't unset](/concepts/tcpa-federal-voice-guard). Email has no such federal window — hence the tenant-opt-in treatment below.

## Suppression semantics per classification — and how exports stay accurate

Consent scope, unsubscribe mechanism, and the audit ledger surface differ by classification. Consent with a lawful basis is the export; a revocation entry is never a deletion.

* **Marketing sends:** a recipient's opt-out binds the [`suppression_list`](/concepts/consent-and-suppression-model). A scope-`email` entry (or the cross-channel `all`) is enforced against every send to that address, on either classification lane — the gate deliberately does not distinguish transactional from marketing here; the lifecycle exemption is an unsubscribe-mechanism carve-out, not a suppression bypass. If you fire transactional sends at a block-listed address, the gate still refuses. The scope defaults and the CSV-import `channel` override column are in [Opt-Out & Suppression Lists](/compliance/opt-out-suppression). The [`consent_records` audit row](/concepts/consent-and-suppression-model) binds your lawful basis at capture — proof for CASL evidence and regulator records requests.
* **Transactional sends:** a preference-center unsubscribe writes `channel_preferences` — a per-channel opt-out flag the send path checks alongside the block list. There is no CAN-SPAM-style 10-day deadline here — the exemption applies as preference-based rather than as a statutory bar — but the preference entry binds the next send the same moment it lands. Scoped consent provenance lands on [`consent_records`](/concepts/consent-and-suppression-model) so exports can show the revocation was routed through the preference center, not the block list.

Both rows land in your export surfaces, and the export carries both stories: `/compliance/suppression-list/export` emits every scoped block-list row (scope `all`, per channel), `/compliance/consent/export` emits the consent state and lawful basis at the audit cut-off. The schemas and the two endpoints' channel filters are in [Export Consent & Suppression Records](/compliance/consent-suppression-export).

The bulk CSV import chooses scope per row from the address type — phone and WhatsApp addresses default to `all` (a STOP on a number blocks every channel reachable on that number), while email addresses default to scope `email`. A `channel` column in the CSV overrides the default per row. Whichever entry point wrote the revocation — unsubscribe link, preference center, Consent API, CSV import — the send gates read the same stores.

## Why email has no federal window — and why quiet hours stay tenant-opt-in

Unlike voice dialing (TCPA's federally codified 8 AM–9 PM recipient-local window for US recipients, the single platform-owned gate), email carries no such federal statutory window anywhere in CAN-SPAM, CASL, or PECR. The restraint is instead carried by your tenant-selected quiet hours — a softer, opt-in counterpart. That split is deliberate and is covered in depth by [Federal vs state vs tenant voice gates: the three-layer stack](/concepts/federal-vs-state-vs-tenant-voice-gates). On email, the tenant gate is fail-open on a malformed window (the dispatch proceeds with a warn log, never a black-hole) while the recipient-classification burden stays hard: send a marketing email to a suppressed address and the gate refuses before any window math happens.

Turning email quiet hours on is a deliberate customer-experience and deliverability decision — not a legal floor. Choose the window you'd apply to marketing traffic and enforce it with `quiet_hours.email.enabled: true`.

## See also

* [Outbound send gating: the tenant-owned controls](/concepts/send-gating-and-quiet-hours) — the full admission chain this page slots into
* [Message priority and traffic lanes](/concepts/message-priority-traffic-lanes) — how the two lanes shape the throughput budget
* [Consent & Suppression model](/concepts/consent-and-suppression-model) — the stores, scopes, and entry points the record binds
* [Export Consent & Suppression Records](/compliance/consent-suppression-export) — the CSV/JSON schemas (consent state + lawful basis; suppression scope/status/reason)
* [US CAN-SPAM Compliance for Email](/compliance/can-spam) — the seven US sender-side requirements
* [CASL (Canada's Anti-Spam Legislation)](/compliance/casl-canada-anti-spam) — express/implied consent tiers
* [UK PECR and ePrivacy](/compliance/uk-pecr-eprivacy) — UK direct-marketing posture beside UK GDPR
* [Federal vs state vs tenant voice gates](/concepts/federal-vs-state-vs-tenant-voice-gates) — the voice three-layer stack email deliberately lacks
* [TCPA federal voice guard](/concepts/tcpa-federal-voice-guard) — the one platform-owned 422
* [Quiet hours configuration](/guides/quiet-hours-configuration) — the org-wide gate knobs and timezone resolution
* [Send gates](/compliance/send-gates) — the preview endpoint for gate verdicts
* [Channel-rate overrides](/compliance/channel-rate-overrides) — per-channel throughput caps to align with window strategy
* [Opt-Out & Suppression Lists](/compliance/opt-out-suppression) — the ledger semantics and CSV import override column