Skip to main content

​
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). 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. 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 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 — 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) and the bulk CSV import/export that moves an existing list in (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 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 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).
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:
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 or bulk-import with the channel column set to all. The scope matrix is spelled out in Opt-Out & Suppression Lists; the posture map in 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 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. For the map of every compliance surface and which toggles default where, see Compliance posture overview.