CASL consent, French language and unsubscribe workflows for US teams marketing to Canada

What to take away

What CASL demands of automation built in the United States

Canada's anti-spam legislation applies to any commercial electronic message sent to a Canadian device, regardless of where the sender sits. A US marketing ops team running Marketo, HubSpot or Braze from Chicago or Austin is fully in scope the moment a contact has a Canadian number or address.

CASL covers email, SMS, social direct messages and some app notifications. That breadth matters for automation design, because a US team may have a single email preference center and no equivalent for SMS consent. Canadian contacts need consent state recorded for each channel you actually use.

The law sets three conditions for a commercial electronic message: consent, sender identification, and a working unsubscribe mechanism. Express consent is explicit and does not expire on its own. Implied consent comes from a relationship or a conspicuous publication, and it does expire.

The burden of proof sits with the sender. If a Canadian regulator asks why a contact received a message, the US company has to show the consent record. That is a data model problem before it is a legal problem, and it is the same problem covered in CASL consent workflows.

Penalties are administrative monetary penalties, and the maximum per violation is set high enough that compliance teams treat it as material. The practical risk for most US firms is not a headline fine but a complaint that forces a manual audit of years of automation logs.

US frameworks do not create the same record-keeping duty. The CAN-SPAM Act, described in the CAN-SPAM Act: A Compliance Guide for Business | Federal Trade Commission, relies on opt-out and honest headers rather than prior consent. A US-built flow can be fully CAN-SPAM compliant and still fail CASL on day one.

State privacy laws such as the CCPA and CPRA in California, plus laws in Colorado, Washington and elsewhere, add disclosure and deletion duties but not a prior consent rule for business email. Teams that treat state privacy compliance as equivalent to CASL miss the consent gate entirely.

The FTC maintains a public library of the statutes it enforces, including the Statutes | Federal Trade Commission, which is a useful reference when mapping which US rules apply to a campaign and which do not.

For structuring consent records and retention schedules, the Privacy Framework | NIST gives US teams a familiar vocabulary of profiles, controls and data processing purposes. It is voluntary, but it maps cleanly onto what a CASL audit trail needs.

Express consent records: what to store and where in the workflow

Express consent is the durable state. Once a Canadian contact gives it, the consent does not lapse with time, though the contact can withdraw it. That makes the record itself the asset, and the automation should treat it as one.

At minimum, store the consent text the contact saw, the timestamp with time zone, the source URL or form ID, the IP address, and the channel consented to. Add the language of the form, because a French opt-in page and an English one are different legal artifacts.

Where the record lives matters. A field on the contact object is easy to query but hard to audit. A separate consent table with one row per grant gives you history, and it survives contact merges and list imports.

Consider a three-part model: a consent event table, a current-state field for fast segmentation, and an immutable log for audit. The current-state field is what your workflow automation branches on; the log is what you produce when asked.

That fifth step catches the most common failure in US-built flows: a contact imported from a trade show list with a checkbox set by a human, and no underlying record.

Consent scope should be granular. A contact who agreed to receive a newsletter has not agreed to receive event invitations or partner offers. Build the consent record with a purpose field, and let the workflow check purpose before send.

Withdrawal deserves its own event type rather than a simple flag flip. If a contact withdraws and later re-subscribes, the record should show both, in order.

Retention is a judgment call, but the safe pattern is to keep consent evidence for as long as the contact is marketable plus a buffer. NIST's framework language about data processing purposes and retention helps justify that choice internally.

Implied consent expiry windows and the automation that retires them

Implied consent is time-limited, and the clock differs by source. An existing business relationship gives 24 months from the last purchase or the last inquiry, depending on which triggered it. A business card or conspicuous publication can give a shorter window.

That 24-month figure is the one US teams get wrong most often, because it feels generous. It is not, if the contact's last transaction was three years ago and nobody updated the record.

The automation needs a dated trigger and a scheduled retirement. Set an implied consent start date when the relationship event occurs, compute the expiry date, and write both to the contact.

When the expiry date passes with no express consent on file, the contact must move to a suppressed state for commercial messages. The clean way to do this is a scheduled workflow that runs daily and evaluates expiry against today's date.

The final notice is optional and risky. Some teams send a re-permission email inside the window; others suppress silently. Either is defensible, but the decision should be documented before the first expiry wave hits.

Watch for contacts with multiple relationship events. A purchase in 2024 and a webinar registration in 2025 may produce two different clocks. The automation should use the event that gives the longest valid window, and record which one it used.

Expiry also interacts with list hygiene. If your suppression logic lives only in the email platform, SMS and push will keep sending. Push the suppressed state to every channel with a send capability.

Reporting matters here. A dashboard that counts contacts by consent type and days to expiry turns a legal obligation into an operational metric, and it gives marketing leadership a reason to care about data quality.

French language requirements and how they affect template builds

Quebec's Charter of the French Language requires commercial communications to be in French, with limited exceptions. In practice, that means a US firm marketing into Quebec needs French versions of the messages it sends to Quebec contacts.

This is broader than the campaign email. Opt-in pages, preference centers, automated confirmation messages, and unsubscribe pages all carry language obligations when they reach Quebec residents. A translated email with an English preference center is a partial fix at best.

The practical build change is to make locale a first-class attribute in the template system. Every template gets a locale code, every send resolves locale from the contact record, and every sequence has a fallback rule for contacts with no locale set.

Locale resolution should not rely on country alone. A contact in Montreal may prefer English, and a contact in Ontario may prefer French. Store a language preference separately from a country field, and let the preference win.

Dynamic content blocks are the usual shortcut, but they can produce mixed-language messages if the fallback logic is loose. Where the obligation is strict, build separate templates and route by locale rather than swapping fragments inside one template.

Subject lines, preheaders and footer legal text all need translation. So do the automated messages that US teams rarely review: password resets, event reminders, cart abandonment and re-permission notices.

Quebec rules also touch how you present the French version. It should be at least as prominent as the English version, not a link buried at the bottom of the page. That is a design constraint on the opt-in form, not just on the email.

The full set of constraints is worth reviewing before you rebuild templates, and the Quebec language requirements piece covers the detail. Budget translation as a recurring line item, not a one-time project, because every new campaign adds strings.

Track which templates have approved French versions. A simple status field on the template record prevents an English-only message from going to a Quebec segment because someone cloned a template and forgot to localize it.

Unsubscribe handling that satisfies both CASL and CAN-SPAM

The two regimes overlap but do not match. CAN-SPAM requires a clear opt-out mechanism and honored requests within 10 business days. CASL requires an unsubscribe mechanism in every commercial electronic message and honored requests within 10 business days.

The difference is scope. CASL's unsubscribe obligation attaches to the message type, including SMS and some social messages, while CAN-SPAM is email-specific. A US team with one email unsubscribe link and no SMS path is exposed on the Canadian side.

The safest design is a single preference center that handles all channels, reachable from every message, with no login required. One click should be enough to unsubscribe from the message type received, and the page should offer a full opt-out.

Unsubscribe must not require a fee, an account, or more steps than the original opt-in. That last point trips up teams whose opt-in is one checkbox and whose opt-out is a three-page survey.

Process the request immediately in the automation, then let the batch sync catch downstream systems. Immediate suppression in the sending platform is what prevents the message that generates the complaint.

Keep the unsubscribe event in the consent log with a timestamp. It is the mirror image of the consent grant, and it is the record you produce when someone says you kept mailing them.

Do not treat an unsubscribe as a deletion request. The suppression record has to persist, or a later list import will resurrect the contact and start the cycle again.

For US contacts, the same preference center works, and it may exceed what CAN-SPAM requires. That is fine. One flow for both countries is simpler to maintain than two, as long as the Canadian rules set the floor.

Where US and Canadian consent workflows diverge in practice

The core divergence is consent model. US email law is opt-out with disclosure duties. CASL is opt-in with proof duties. Everything else follows from that.

Second is record retention. US teams often keep minimal send logs. Canadian exposure requires consent evidence, withdrawal evidence and the ability to produce both quickly.

Third is language. No US state requires French commercial communications. Quebec does, and that obligation lands on the template layer rather than the send layer.

Fourth is channel scope. CASL reaches messages that US law does not, so a US-built flow with email-only consent logic will have gaps in SMS and messaging channels.

Fifth is the expiry concept itself. US law has no equivalent to implied consent expiry, so no US-built workflow has a timer to retire it. That timer has to be added deliberately.

Sixth is vendor and data location. Canadian contacts in a US-hosted platform are fine under CASL, but PIPEDA expectations and provincial rules may shape how you document transfers, retention and cross-border access.

Cost is a practical divergence too, since platform pricing, add-ons and regional support differ for Canadian operations. The Canadian pricing breakdown is a useful input when you scope the build.

Most of these gaps trace back to how the automation identifies a person and what it does when that identity changes. That design question is covered in identity, consent and triggers.

Teams that get the data model right tend to find the rest manageable. Teams that bolt consent onto an existing contact field usually rebuild within a year.

A worked example: one sequence, two countries

Take a US software firm running a webinar nurture. A contact in Texas and a contact in Ontario enter the same sequence. The Texas contact gets the standard flow with an opt-out link. The Ontario contact hits a branch that checks consent type before the first send.

If the Ontario contact has express consent, the sequence continues and the send resolves to the French template if the locale is French. If consent is implied from a demo request, the sequence continues but writes an expiry date 24 months out and sets a task to watch for a re-permission opportunity.

If the expiry date has passed, the contact exits the sequence and enters a suppressed segment. No send occurs. The log records the reason.

That single branch is the whole difference. The work is in the data model and the templates, not in the sequence logic itself.

A pre-launch checklist for Canadian sends

Run the checklist against a staging copy of the automation before the first Canadian campaign. Most failures show up in the reconciliation step, not the send.

Common questions