CAN-SPAM rules every US automation workflow has to enforce

What to take away

The CAN-SPAM requirements that apply to every automated send

CAN-SPAM is a US federal law, enforced by the Federal Trade Commission, that governs commercial email. It does not require prior consent the way GDPR does for EU recipients. It requires that the recipient can get out, that they know who is writing, and that the subject line does not lie.

The FTC compliance guide sets out the core duties in plain terms. Commercial email must have a working return address, a clear and conspicuous opt-out mechanism, a valid physical postal address, and accurate routing and header information. Deceptive subject lines are prohibited.

Automation changes the risk profile. A human sending one campaign can notice a broken footer. A workflow that fires on a form submission, a trial expiry or an abandoned cart will send thousands of copies of the same defect before anyone reads one.

Four obligations apply to essentially every automated commercial send:

The advertisement identification requirement is the one teams forget. It can be satisfied by a line in the footer, but it has to be clear. A grey 8px label buried under tracking pixels is not clear.

State law adds a layer. California's CCPA and CPRA govern personal data handling for California residents, and they interact with suppression logic. If someone exercises a deletion right, your suppression list needs to survive that deletion in a form that still blocks future sends.

US companies serving EU customers also carry GDPR obligations on top of CAN-SPAM. The two regimes differ on consent, so a single global workflow template is usually non-compliant in one direction or the other. Split the templates by region.

For teams auditing this, the hubspot ops hub vs zapier comparison is a useful starting point before sign-off, alongside the footer and the suppression path.

Opt-out mechanics: what the FTC guide requires and where each platform hides the setting

The opt-out requirement is the one most automation teams get wrong, usually because the setting lives somewhere unexpected.

The FTC guide is specific. The opt-out must be clear and conspicuous, it must work for at least 30 days after the message is sent, and you must honor it within 10 business days.

You cannot charge a fee for opting out, require the recipient to provide information beyond an email address, or make them take a step beyond replying to the message or visiting a single page.

That last point kills a common pattern. A preference center that requires login before it will accept an unsubscribe is a violation. So is a two-step confirmation flow that asks for a reason before processing.

An unsubscribe link that routes to a page asking the recipient to log in is the single most common violation in B2B automation.

Here is where the setting usually lives in the major platforms:

Defaults are the problem. Marketo's global unsubscribe applies across workspaces unless you override it, which is fine for compliance and bad for business units that need separate suppression. Klaviyo's smart unsubscribe, which suppresses across channels, is off until someone turns it on.

The List-Unsubscribe header is a separate control from the visible link. Gmail and Yahoo bulk sender rules expect it, and it makes one-click opt-out available in the client. Most platforms expose it in the same settings screen as the footer, but it is a distinct toggle.

Suppression has to propagate. If a recipient unsubscribes from a nurture track, the abandoned cart workflow must also stop. Platforms that treat subscription state per-list will keep sending unless you build a central suppression list and reference it in every enrollment filter.

That propagation work is where marketing workflow automation pricing us stops being a settings task and becomes a data model task.

Test the opt-out from a real inbox, not a preview. Click the link, confirm the page loads without login, confirm the confirmation does not require a second action, and confirm the suppression lands in every workflow that could reach that address.

Sender identification, physical address and subject line rules in workflow templates

Sender identification and the physical address requirement both live in the footer, and both are frequently broken by template inheritance.

Header information must be accurate. The from name, from address, reply-to and originating domain all have to identify the sender truthfully. A from address of noreply@ is fine. A from name that claims to be a person who did not write the message is not.

The physical address requirement means a valid postal address where the sender can receive mail. A registered PO box works. A virtual office address that forwards mail works. What does not work is a city and state with no street address, or a placeholder that shipped to production.

The classic failure is a template fork. A regional team clones the parent template, edits the footer, and removes the address because it looked cluttered in the design review. The workflow then sends from that template for a year.

Subject line rules are simpler than teams assume. The subject cannot mislead about the contents or the subject of the message. That is the whole test. A subject line that says "Your invoice" on a promotional message fails it. A subject line that says "Your September invoice is ready" on an actual invoice passes.

Automation adds a specific hazard here: merge fields in subject lines. A subject line built from a fallback value can produce "Hi, your order" or worse, a subject that reads as a different message entirely. Always set a fallback and test the empty-value case.

Preheaders matter too. They are part of the message and the FTC treats the whole message as the unit. A subject line that is accurate and a preheader that contradicts it is still a problem.

For templates that serve multiple regions, keep the compliance block in a locked module that regional editors cannot modify. Locking the footer is the single highest-value template control in a US sending program.

If your team is consolidating templates across markets, the migration mistakes usually involve exactly this kind of inherited footer.

Transactional versus commercial messages inside the same automation

CAN-SPAM's primary purpose is regulating commercial messages. Transactional or relationship messages are largely exempt from the opt-out and advertisement-identification requirements, but not from the accuracy requirements.

The FTC guide defines transactional or relationship messages as those that facilitate an agreed-upon transaction, provide warranty or product recall information, or deliver account information. A receipt, a shipping notification and a password reset all qualify.

The exemption is narrower than most teams assume, and it turns on the primary purpose of the message. If a transactional message also contains promotional content, the whole message can be treated as commercial. A shipping confirmation with a banner ad for a related product is the standard example.

This matters inside automation because the same workflow often sends both. An order confirmation workflow may send a receipt, then a review request, then a cross-sell. The receipt is transactional. The review request is a gray area. The cross-sell is commercial and needs the full footer.

Build the distinction into the workflow itself. Tag each message node as transactional or commercial, and route the commercial nodes through a compliance check that verifies the footer, the address and the opt-out link before send.

The canadian marketing workflow automation pricing questions teams ask most often tend to cluster around this boundary, because it determines which messages need the full treatment.

A practical rule: if the message would still make sense to someone who never bought anything, it is commercial. Apply the full footer.

Penalty exposure and the FTC enforcement pages worth monitoring

CAN-SPAM penalties are assessed per email, which changes how you should think about risk. A single defective send to a 200,000-person list is 200,000 potential violations, not one.

The FTC has brought cases against senders for failures as basic as a non-functioning opt-out and a missing physical address. Enforcement has also targeted companies whose affiliates sent on their behalf, because the law holds the sender and the brand accountable.

The FTC's advertising and marketing guidance pages are the practical reference for how the agency reads the rules, and they are worth a quarterly review. The FTC statutes library is where you confirm the underlying text when a platform vendor claims a configuration is compliant.

For anything that touches SMS or messaging alongside email, the FCC consumer guides cover the separate rules that apply to text-based marketing. Teams running coordinated email and SMS journeys need both sets of rules in scope.

Practical monitoring routine:

Penalty amounts are set by statute and adjusted for inflation, so check the current figures rather than relying on a number from an old deck. The exposure math is what drives prioritization: fix the workflows with the largest send volume first.

A pre-launch checklist mapped to platform configuration screens

This checklist maps each requirement to the screen where it is actually configured. Run it before any workflow goes live, and again after any template change.

Two items on this list need engineering help rather than a settings change: suppression propagation and merge-field fallbacks. Everything else is configuration.

That split matters for planning. A compliance remediation project is mostly a settings audit with a small data engineering component, not a rebuild.

Teams running low-code marketing workflow automation platforms often find the suppression propagation is the one piece the visual builder cannot express, and it needs a scheduled job or a webhook into a central list.

Assign an owner to each checklist line. Compliance items with no named owner get reverted by the next template redesign, usually within two quarters.

Common questions