> ## 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. # US CAN-SPAM Compliance for Email > Meet the seven CAN-SPAM content requirements when you send commercial email to US recipients through Orbit — sender identity, physical address, unsubscribe mechanics, and the suppression layer that honours opt-outs. # US CAN-SPAM Compliance for Email Email is a fully shipped Orbit channel — you send transactional and marketing messages through `POST /api/v1/messages/email` (see [Email](/channels/email)). Any commercial email you send to US recipients falls under the **CAN-SPAM Act of 2003** (15 U.S.C. § 7701 et seq.), enforced by the FTC. CAN-SPAM is a sender-side statute: it regulates what *your message contains and how you handle opt-outs*, not which transport carries it. CAN-SPAM's controls are **tenant-owned**. Orbit never mandates your posture — it gives you the send surfaces (sender domains, templates, headers) and the suppression layer that makes an opt-out stick. This page maps each statutory requirement to the Orbit surface you already have, so you can close the gaps deliberately. *** ## The seven CAN-SPAM content requirements The FTC summarizes the Act in seven requirements. For each: what the statute asks, and which Orbit surface covers the mechanics. | # | Statutory requirement | Where the control lives in Orbit | | - | ----------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | 1 | No false or misleading header information | **Sender domain verification** — your `From` domain is DKIM/SPF-verified before it can send, so the header always identifies its true origin (see [From-identity / sender domain](#from-identity--sender-domain)) | | 2 | No deceptive subject lines | **Your copy.** Orbit sends the `subject` you pass; the statute binds you, not the platform. Keep the subject consistent with the body | | 3 | Identify the message as an ad | **Your body content / template** — a disclosure line in the template satisfies this when the promotion isn't obvious | | 4 | A valid physical postal address | **Footer block in your template or HTML body** — see [Opt-out mechanism](#opt-out-mechanism) | | 5 | A clear, conspicuous opt-out mechanism | **`List-Unsubscribe` headers + in-body unsubscribe link** — every outbound email carries both (see [List-Unsubscribe header behavior](#list-unsubscribe-header-behavior)) | | 6 | Honor opt-outs within 10 business days | **The suppression list** — a recipient click writes a scope-`email` suppression entry and every later send to that address is dropped; Orbit honours it immediately, well inside the 10-day window (see [Opt-out & Suppression Lists](/compliance/opt-out-suppression)) | | 7 | Monitor email done on your behalf | **Engagement + suppression telemetry** — bounce/complaint reputation (`GET /api/v1/email/suppressions/reputation`) and the [Compliance Health](/compliance/compliance-health) view tell you what third parties sending for you are producing | Requirement 1 has a hard mechanical prerequisite, and requirements 5–6 have one on the opt-out side. Both are worth spelling out. *** ## From-identity / sender domain CAN-SPAM's first requirement — no false or misleading headers — is backed by Orbit's domain verification. A custom sending domain only accepts traffic once its **DKIM**, **SPF**, and **DMARC** records verify (configure them under **Channels → Email → Domains**; a daily health check re-validates and drifts are flagged with a bell notification). An unverified domain fails with a `403` at send time, which means recipients always see a `From` identity your mail actually originated from — the header-can't-lie property the statute asks for. Complete the domain setup first; it is the mechanical prerequisite for everything else on this page. See [Email → Domain Setup](/channels/email) for the DNS record table, the **Verify DNS** flow, and the per-record traffic-light status endpoint. SMS and voice have an analogous sender-identity posture — [Sender-ID Registration](/compliance/sender-id-registration) — but email has no such registration step. Domain verification is the email-side equivalent, and it is a deliverability gate rather than a statutory one. *** ## Opt-out mechanism Two physical manifestations of the opt-out obligation, both sender-side: 1. **Physical postal address.** Include your organization's valid physical postal address (a street address, PO box, or registered private mailbox) in the footer of every commercial email. Keep it in a shared footer block so every template carries it by construction. 2. **One-click unsubscribe link.** Every outbound email that leaves Orbit carries an in-body unsubscribe link, alongside the transport headers described next. No end-user menu, login wall, or reply-mail step between the click and the suppression. The unsubscribe target is a signed Orbit URL; a click writes a suppression entry against that recipient, idempotently, and appends an `email.unsubscribed` audit event. The recipient lands on your configured redirect page or a default acknowledgement. The two suppression surfaces you compose with are documented on their own pages and unchanged by this one: the suppression ledger itself ([Opt-Out & Suppression Lists](/compliance/opt-out-suppression)) and the bulk CSV import/export that moves an existing list in ([consent-suppression-export](/compliance/consent-suppression-export)). Orbit does not render your commercial email for you — the HTML (or the rendered blocks output of the email builder) is yours. The seven requirements above are checked by your reviewers, not by a platform gate. Keep the footer block and the ad-disclosure line in your base template so no campaign ships without them. *** ## List-Unsubscribe header behavior Alongside the in-body link, every outbound email sets the recipient- client headers that major mailbox providers (Gmail, Yahoo, and others) read for their native unsubscribe buttons: ``` List-Unsubscribe: >, List-Unsubscribe-Post: List-Unsubscribe=One-Click ``` * `List-Unsubscribe` names where a client should send the opt-out — an HTTPS URL *and* a mailto fallback, per RFC 2369. * `List-Unsubscribe-Post` signals **RFC 8058 one-click unsubscribe**: the mailbox provider may POST to the header URL and the opt-out must complete without any further interaction. This pair is also what Gmail's and Yahoo's bulk-sender policies (required since 2024 for senders above 5,000 messages/day) demand on marketing traffic. The inbound unsubscribe POST lands at Orbit's unsubscribe endpoint — the same endpoint your in-body link points at — where the signed token is verified and a suppression row is written with **scope `email`**. (If you route your own inbound mail, note the blog-side distinction: [inbound parse](/guides/inbound-email-parse) is for content you receive; unsubscribes happen on the *outbound* path and never touch your inbound routes.) The walk-through end-to-end: 1. Recipient clicks the Gmail "Unsubscribe" button or your footer link. 2. Provider (or browser) POSTs to the `List-Unsubscribe` URL with `List-Unsubscribe=One-Click`. 3. Orbit verifies the signed token, writes an `email`-scope suppression row for the recipient, and appends an `email.unsubscribed` audit entry. 4. The next send to that recipient — campaign, contact import, or API call — is dropped before dispatch, because the suppression gate is fail-closed for entries that exist ([posture map](/compliance/posture-overview)). A worked request — a commercial send with the correct header pair, physical address in the footer, and unsubscribe link resolved into the body at dispatch: ```bash theme={null} curl -X POST https://api.orbit.devotel.io/api/v1/messages/email \ -H "X-API-Key: dv_live_sk_YOUR_KEY" \ -H "Content-Type: application/json" \ -d '{ "to": "customer@example.com", "from": "Acme Marketing ", "subject": "This week at Acme", "html": "

Our July offers…

" }' ``` Orbit merges the `unsubscribe_url`, attaches the `List-Unsubscribe` / `List-Unsubscribe-Post` headers, and delivers. A recipient click → suppression → a later send to the same recipient returns a skipped / suppressed outcome on the send result (and an `email.unsubscribed` audit event is already on the ledger). *** ## Suppression scope for email Scope on the suppression entry decides **which channels the opt-out blocks**, and the default is written by entry point: * **An unsubscribe click / unsubscribe link / List-Unsubscribe flow** writes an entry with scope `email`. * **A bulk CSV import** infers `email` for email rows, and the import's `channel` column can override per row — say `all` if you mean "this address stays out of everything". * **STOP keyword, Preference Center, and Consent API** opt-outs always write scope `all`, regardless of address type. The consequence is **deliberate**: an email opt-out under the default `email` scope does **not** block SMS or voice to that contact, and vice versa. This is a tenant choice, not a default Orbit secretly fixed for you — so if your policy is "an unsubscribe anywhere means no marketing anywhere," either route the opt-out through the [Consent API](/compliance/consent-management) or bulk-import with the `channel` column set to `all`. The scope matrix is spelled out in [Opt-Out & Suppression Lists](/compliance/opt-out-suppression); the posture map in [Compliance posture overview](/compliance/posture-overview) says which default applies per entry point. *** ## Bounce and complaint suppression (the FTC's other flank) CAN-SPAM is not only about opt-outs. Hard bounces and abuse complaints are also health signals the mailbox providers score, and Orbit seeds your suppression list from the same events: * **Hard bounces and invalid addresses** are tracked per message; the address lands on the suppression list so a later send is dropped before dispatch, protecting sender reputation. * **Spam complaints** (recipient hits "Report spam") feed the same ledger — the recipient is suppressed, and the complaint appears in the delivery events stream. * Aggregate bounce/complaint rates per domain are visible on `GET /api/v1/email/suppressions/reputation` — the same surface the [Email](/channels/email) page calls out for warmup and new-domain caution. The statute's 10-business-day clock never comes into play here: these suppressions are recorded at event time, and the suppression gate runs ahead of every dispatch. *** ## Non-US email is not covered here This page is scoped to **the US federal CAN-SPAM Act only**. Other jurisdictions layer their own rules on commercial email — CASL's express-consent model in Canada, the GDPR + ePrivacy regime in the EU/EEA, PECR in the UK. For per-country sender rules and required documentation, see [Country Compliance Requirements](/compliance/country-requirements). For the map of every compliance surface and which toggles default where, see [Compliance posture overview](/compliance/posture-overview). *** ## Related references * [Email](/channels/email) — domain verification, send, limits, bounce/complaint lifecycle. * [Opt-Out & Suppression Lists](/compliance/opt-out-suppression) — the suppression ledger, scopes, bulk CSV import. * [Consent Management](/compliance/consent-management) — record an opt-in/opt-out with scope `all` from your own UI. * [Inbound email and SMS routing](/guides/inbound-email-parse) — the inbound side, distinct from unsubscribe handling. * [Country Compliance Requirements](/compliance/country-requirements) — non-US sender rules. * [Compliance posture overview](/compliance/posture-overview) — the toggles and their defaults, all in one table.