Anonymised, illustrative composite. The unsubscribe page loaded perfectly every time someone clicked it. The suppression it was supposed to trigger had been silently broken for weeks — and nobody had tested the difference between the two.
At a glance
A team switched email platforms mid-year. During migration, the automation behind the unsubscribe link — the part that was supposed to add a suppression tag to a contact’s record — broke silently, because the API key it relied on expired during the changeover. The link itself kept working perfectly: clicking it still loaded a normal “you’ve been unsubscribed” confirmation page, so nothing looked wrong to anyone who tested it by eye.
A past client unsubscribed after the June newsletter, saw the confirmation page, and assumed that was the end of it. He received the July newsletter anyway, emailed the team “I already unsubscribed,” and got an apologetic auto-reply — but nobody actually checked the platform’s backend, treating it as a one-off blip instead. He received the August newsletter too. By the time someone finally investigated, in September, roughly eleven weeks — about 55 business days — had passed since his original request, with the platform still sending to him the entire time.
One unsubscribe request in June, two further newsletter sends afterward in July and August, and roughly 55 business days elapsed before the actual fix — against a legal ceiling of 10 business days to give effect to the request in the first place. That is not a near miss; it is more than five times the maximum window the law allows.
Section 11 of CASL requires an unsubscribe mechanism to let the recipient opt out “at no cost to them,” and requires the sender to give effect to that request “without delay, and in any event no later than 10 business days.” The CRTC’s own guidance states the same ceiling plainly. A confirmation page rendering correctly is not what the rule measures — the standard is whether the request was actually given effect, and a request that visually “worked” but never technically executed fails that standard just as completely as no unsubscribe link at all.
Once flagged, the team found and fixed the expired API key, then manually suppressed every account that had clicked unsubscribe during the broken window — cross-referenced from the platform’s own click logs, which had continued recording the unsubscribe clicks even though the suppression action itself had failed. Each affected recipient got a direct apology rather than waiting to see who else would complain. No CRTC complaint followed once the client saw the fix and the apology. The near-miss is now a standing step on the team’s platform-migration checklist: after any migration, send a real test unsubscribe from a real test account and confirm the next send actually excludes it — not just that the confirmation page loads.
CASL’s administrative monetary penalties cap at $1,000,000 for an individual and $10,000,000 for an organization — the same statutory ceiling that applies whether the failure is one broken automation or a deliberate scheme, since the CRTC does not need to find intent to have grounds to investigate, only a failure to give effect to a valid request inside the ten-business-day window.
This is a different CASL problem from a list that has simply aged out of implied consent: here, the recipient did everything right — found the link, clicked it, got a confirmation — and the sender’s own mechanism still failed him. A consent window lapsing is a data-hygiene problem; an active, explicit unsubscribe request going unhonoured is arguably the more serious failure of the two, because the system told the recipient it had worked when it had not.
CASL separately requires the unsubscribe mechanism itself to stay functional for a minimum of 60 days after a message is sent, so a recipient reading an email late still has a working way to opt out. That is a narrower, easier requirement than the one actually broken here — the link itself stayed live and functional the entire time; what failed was the suppression step behind it. A team auditing itself after a scare like this one should check both: does the unsubscribe link still work two months after a send, and, separately, does clicking it actually stop the next one?
A confirmation page proves the front end works. It proves nothing about whether the backend suppression actually happened. The only real test is sending a fresh test account through the unsubscribe flow and confirming it receives nothing on the next send — anyone who has never actually run that test cannot know whether their unsubscribe mechanism works, no matter what the platform’s dashboard reports.
Related reading: unsubscribe mechanism, defined the National Do Not Call List, defined a related CASL failure, on the consent side
A 30-minute call is enough to tell you whether AI pays for itself here.
