Skip to main content

​
CASL (Canada’s Anti-Spam Legislation) for Commercial Email

Canada’s Anti-Spam Legislation (S.C. 2010, c. 23, enforced by the CRTC) governs commercial electronic messages — including email — sent to Canadian recipients. Unlike the US CAN-SPAM opt-out model, CASL is largely an opt-in statute: you need consent before you send, and the consent has to be documented. CASL came into force on 1 July 2014; the enforcement and private-right-of-action phases are CRTC matters, so check current guidance on fightspam.gc.ca alongside your own counsel. CASL is a tenant-owned burden. Orbit never mandates your posture — it gives you the send surfaces (sender domains, templates, headers), the consent ledger, and the suppression layer. This page maps each CASL obligation to the Orbit surface you already have so your reviewers can close the gaps deliberately before you send to Canadian recipients.
This page is documentation, not legal advice. CASL carries administrative monetary penalties and a private right of action; have counsel review your consent capture, identification text, and unsubscribe mechanics. Orbit supplies the record-keeping and suppression surfaces — the legal posture is yours.

​
What CASL actually requires

The statute’s core duties for a commercial electronic message:
  1. Consent — the recipient must have given express consent, or fall under one of the statute’s implied consent categories (existing business relationship, conspicuously published address relevant to the relationship, a few narrow carve-outs).
  2. Identification — the message must identify the sender and the person on whose behalf it is sent, with a valid postal address (or, where the addressee can reach you, a readily reachable electronic address).
  3. Unsubscribe — the message must carry an unsubscribe mechanism that is readily performed and remains valid for at least 60 days after the message is sent.
  4. Record-keeping — a three-year record-keeping duty on consent evidence; a CRTC audit asks for the record, not for your recollection.
The implied-consent categories are where most operators get this wrong: a customer who bought from you is in an existing business relationship, but that implied consent expires (generally two years after the last transaction for purchases, six months after an inquiry). Track the tier on your consent records, or you cannot tell a CRTC auditor whether a given recipient was implied or express.
CAN-SPAM in the US lets you send until the recipient opts out. CASL in Canada requires consent before you send. Map that difference to the two relevant Orbit surfaces: The scope decision matters more under CASL than it does under CAN-SPAM: a Canadian recipient’s unsubscribe click defaults to scope email (everything on Opt-Out & Suppression Lists applies), but because consent is opt-in, many operators route Canadian opt-outs through the Consent API with scope all so the revocation propagates to SMS and voice too. Pick your scope deliberately — the defaults are per-entry-point, not per-jurisdiction.

​
Identification requirements

CASL s.6(1) requires the message to identify the sender and to carry a valid postal address (or a reachable electronic one). Orbit’s side of this maps the way CAN-SPAM’s header-integrity requirement maps: Domain verification is a deliverability gate, not a statutory one — but it is what gives the recipient and the CRTC a verifiable true-origin header, which is the substance CASL’s identification clause asks for.

​
Unsubscribe mechanism

CASL s.6(2) requires an unsubscribe mechanism that is readily performed and stays valid for at least 60 days. Two shipped Orbit surfaces satisfy this by construction, and either can carry the burden:
  • List-Unsubscribe headers — every outbound email carries the List-Unsubscribe / List-Unsubscribe-Post pair for RFC 8058 one-click unsubscribe, plus an in-body unsubscribe link. A click or a provider POST writes an email-scope suppression row and an email.unsubscribed audit event — silent, no login wall. (full header behavior)
  • Preference Center — a signed per-contact link your customers can reach directly, let them revoke per-channel from one place. Issue it via POST /api/v1/compliance/preference-center and the same suppression ledger records the click. (Preference Center anchor)
Keep both available; the 60-day validity is a property of the signed link, which Orbit’s token satisfies by construction.
CASL s.13 and the record-keeping guidance make the consent record the thing a CRTC audit asks you to produce. Orbit’s Consent API is exactly the surface that gives you that record — each entry is timestamped, scoped to a channel, and exportable. A worked request: fetch the express-consent evidence for a Canadian recipient before a campaign runs:
A typical response showing the CASL-necessary record:
An opt_in: true (or state: opted_in, depending on the endpoint’s return shape) entry is the CASL-grade evidence you’d hand to the auditor: timestamped, scoped, and idempotent. If your capture form already writes consent through POST /api/v1/compliance/consent at acquisition time, the audit trail exists — CASL’s three-year record window is a GET/export-away (Consent Management/export). For implied-consent tiers, keep the tier note on your own CRM and point the consent entry at the tier you claim — the ledger is the transport, the category is yours.
Implied consent is a tier with a statutory clock: two years from the last purchase, six months from an inquiry, or unbounded while the conspicuously-published-address carve-out holds. The clock is yours to track — Orbit stores the consent record, but the audit-askable tier note (which tier you claimed, what triggered it, and when the clock expires) lives in your CRM, with the Consent API source field pointing back at it. These three scenarios cover the tiers most senders carry.

​
Scenario A — existing purchase (2-year)

A customer buys from you on 2025-04-12; CASL implied consent (s.10(8)(a)) runs for two years from the transaction:
The source string names the CRM record that holds the tier decision. Keep the expiry date in the string (or your CRM’s full note format, e.g. casl-tier:purchase;txn:ord_5123;expires:2027-04-12) so a CRTC auditor can reconstruct the tier from the ledger row alone — that audit-askable tier note is the difference between “we had consent” and “here is the consent we had.”

​
Scenario B — inquiry (6-month)

A prospect asks a pricing question on 2026-03-04; implied consent (s.10(8)(b)) runs for six months from the inquiry:

​
Scenario C — conspicuously published address

The recipient’s email address was conspicuously published (their own website, a directory) and your message is relevant to their role. CASL doesn’t place a hard expiry on this tier (s.10(8)(b)) — but the relevance test is yours to document:
Expiry reminder to keep on your CRM: casl-tier:published;expires:null; review:quarterly.

​
Stopping sends at tier expiry — checklist

When the tier clock runs out and no express consent exists, the contact is sending-ineligible, not suppressed — the distinction matters because you don’t want to quarantine a ledger entry for a contact who might re-tier (a new purchase) and deserve a lawful send window again.
  1. Flag the tier expiry in your CRM’s sync job — a nightly or hourly job computes expires_at < now() for each implied-consent tier.
  2. Write the ineligible state back to the consent ledger through the Consent API (e.g. state: unknown, or opt the contact out of the marketing channel if that is your pattern). Either way, the ledger is the transport; your CRM explains why.
  3. Recheck before continuing — if a new purchase lands, write the new purchase tier; the ledger now has the full breadcrumb history an auditor can walk.
  4. Never suppress an expired-implied contact unless they opted out — the suppression ledger is the durable opt-out signal, not a “lawful-then-expired” marker. Mixing the two breaks both records.

​
The 60-day unsubscribe lifecycle

CASL s.6(2) requires the unsubscribe mechanism to remain valid for at least 60 days after the message is sent. Orbit satisfies the clock by construction — the operational fail point is proving, on day 59 of a campaign, that the signed preference-center link and the RFC 8058 one-click headers were still valid when a recipient clicked. Two surfaces carry the day:
  • RFC 8058 one-click headers — the List-Unsubscribe / List-Unsubscribe-Post pair Orbit stamps on every outbound email. The provider POST hits a direct Orbit endpoint, so 60-day validity is a property of Orbit’s own route, not of an expiry clock you manage. Keep the sender domain live for the full 60 days — retiring the domain breaks the route.
  • Signed preference-center links — issued by POST /api/v1/compliance/preference-center; the signed token doesn’t expire on its own clock, so a click on day 59 of the campaign hits the same long-lived link that day 1 produced. The validity proof is Orbit’s HMAC signature, not a countdown timer.
Your day-59 checklist:
  1. Keep the preference-center link Orbit issued for the whole campaign — do not swap providers mid-campaign; re-signing the link trashes the validity chain the CRTC auditor is testing.
  2. If a recipient reports on day 59 that “the link is broken,” treat it as a platform signal to escalate — a broken-link screenshot is evidence your link was not Orbit-validity-tracked from day 1.

​
Evidence-bundle export — the complete CASL packet

The Export Consent & Suppression Records page gives you both halves of the CASL evidence packet; this section wires them into the three files a CRTC audit asks for — the consent proof, the campaign send log, and the suppression proof. Pull the consent events for the audit window, scoped to the channel the message was sent on:
The source column carries your audit-askable tier note — every tier-flagged row points straight back at the CRM record an auditor can reconstruct the tier from.

​
2. Campaign send log

The send records the CRTC asks for live in Orbit’s message/campaign export surfaces (warehouse export ways, or your own message-send export from the API). Keep one row per send attempt: contact, template, dispatch timestamp, and the consent-check outcome. Quote these together with the consent export above — the auditor is reconstructing which consent state covered which send.

​
3. Suppression proof

If the CRTC asks “you said the unsubscribe ran on day 59, prove it,” the suppression export answers with the (channel, address) STOP row timestamped and status=active:
Pass status=all so revoked rows surface too — an expired-implied contact that later opted out shows up correctly.

​
Audit checklist

  1. Pull the consent export before the audit window opens — bound to to the audit cut-off so the file contains only what was true at that point in time.
  2. Cross-check every send row in the campaign log against a consent row in the same packet; an orphaned send row is the finding you want to find yourself first.
  3. Answer the suppression question from the same packet, not a fresh suppression export run later — a packet-of-record approach keeps the auditor’s file identical to your own.
  4. Keep the export run’s audit-log entry with the packet — the consent and suppression exports both audit themselves, and the export-event row is part of the evidence trail the auditor walks.

​
Canadian numbers and quiet hours — a brief note

Canada has no federal quiet-hours statute the way the US TCPA defines one for voice. A Canadian recipient simply defaults to whatever window you have configured on the org-wide gate or the campaign fallback window (21:00 → 09:00 recipient-local if you never set one). Configure the window deliberately for Canadian recipients under Quiet hours configuration — and if you run voice into Canada, the same recipient-local default window applies there too.