Case Study: My Cold Email Engine Passed Every Check and Broke the Law Anyway

On September 13, 2026, I found out my own cold-email system had been sending real prospects real emails for eleven days with no opt-out line and no postal address in any of them. My weekly deliverability check had been green the whole time.

This is the second of the case studies I said were coming when I published the first one, and it follows the same rule: nothing in it you cannot check yourself. The system is Smart AI Workspace's own lead-generation engine, the repository is public and MIT licensed, and the fix is one commit you can read in full.

Client Zero, Again

Same rule as last time: the system under discussion is my own, running live cold email for my own consultancy, not a client story dressed up for a portfolio. I found this gap in my own sending, on my own leads, and I'm naming the exact commit that closed it. Everything below is either in the public repository or in that day's Sent folder. Where I don't have a number, I don't give one.

The Gap: A Dashboard That Measured the Wrong Thing

By September 13, the outbound engine had sent 59 first-touch and follow-up emails to real prospects since September 2 (69 messages counting every follow-up, one bounce at 1.7%). The system watching that traffic was thorough. /deliverability-monitor confirmed SPF, DKIM and DMARC passing, scanned every sending domain against public blocklists, tracked the bounce rate, and returned a verdict:

Bounce:   0.0% (0/23)  [GREEN]
Auth:     PASS (spf=pass dkim=pass dmarc=pass)
Blocklist: clean (Spamhaus DBL/ZEN, SURBL, SpamCop, Barracuda)
Verdict:  GREEN

None of those checks, or anything else in the send path, verified the one thing that made sending legal in the first place: whether the email gave the recipient a way to say stop. CAN-SPAM (US) and CASL (Canada) both require a working opt-out mechanism and a physical postal address in every commercial email. The reply-triage skill would catch and honor an unsubscribe once someone sent one, but nothing put an opt-out line or an address into the message before it went out, and nothing would have stopped a send if one were missing.

A new client could have been onboarded and gone live the exact same way (sourced, scored, drafted in voice, sent, monitored for deliverability), with no compliance footer at any step, because no step checked for one.

What It Cost

Fifty-nine real people got a cold email from me over eleven days with no opt-out line and no postal address in it. That is the entire claim, and I'm deliberately not dressing it up: no regulatory contact, no complaint that I know of, and I am not implying one. But "no one complained" is not the same as "compliant," and at the time I had no way to tell which one was true. That gap is the cost, whether or not anyone ever tested it.

The Fix Was a Gate, Not a Footer

The obvious patch is adding an opt-out line and a postal address to the email template. That covers the next email. It doesn't cover the next client, because the requirement still lives only in someone's memory of updating every template by hand.

The actual fix, shipped the same day in commit 901c133, moved the requirement into the onboarding contract and the send path itself. The validator that checks a client config before it can go live now includes this:

def check_sending(slug):
    """Every cold email carries a postal address (compliance footer)."""
    identity = CLIENTS / slug / "identity.md"
    m = re.search(r"postal_address_env\W+([A-Z][A-Z0-9_]{2,})",
                  identity.read_text(encoding="utf-8"))
    if not m:
        return [f"no 'postal_address_env' line naming the .env var"]
    if not _env_is_set(m.group(1)):
        return [f"env var {m.group(1)} is not set"]
    return []

And the send skill checks the same variable before drafting or sending a single email:

A fresh clone of the repository sends zero emails until someone sets that variable. That's the difference between a footer and a gate: a footer can be forgotten once; a gate cannot be skipped without noticing.

The Footer Itself

Every email, first touch through the final follow-up and the breakup message, now ends with:

<founder name>
<business name>

Not relevant? Reply "stop" and I won't email you again.
<business name>, <postal address>

A reply of "stop" is the opt-out. The reply-triage skill classifies it as an unsubscribe and adds the address to a suppression list, which every future send checks against. CAN-SPAM allows 10 business days to honor an opt-out, which is why that skill has to run at least twice a week while a campaign is live. A suppression list that's only checked once a month isn't really a suppression list.

The Rest of the Hardening

The same commit closed three other gaps that aren't part of this story but shipped alongside it:

• Untrusted-input guardrail: reply emails, CSVs and enrichment data are now explicitly treated as data, never as instructions, closing a path where a crafted reply could otherwise steer the agent.
• Tool and spend gates: the system now denies tools it never needs and requires explicit confirmation before a domain purchase, a DNS write, or domain forwarding.
• Runtime data hygiene: the files that accumulate real prospect data during a run are gitignored and untracked, so they stop sitting in a public repository.

One Honest Caveat

The gate proves an address is configured. It doesn't prove the address is current, and during those eleven days the only way a recipient could have opted out was a manual reply, not a one-line unsubscribe link. The suppression mechanism existed, but it depended on someone writing back. And all 69 messages went out from the business's primary domain with no dedicated warmed sending domain, which the system's own playbook flags as fine at this scale and explicitly wrong for a paying client at volume. That's not a compliance gap, it's a documented limit, and it's why a separate onboarding skill exists to stand up dedicated sending infrastructure before any client is asked to trust this for real volume.

Verify It Yourself

The repository is public and MIT licensed: github.com/tariqosmani/smai-leadgen. You can check every claim above without asking me:

• .env.example: the SENDER_POSTAL_ADDRESS line and the comment explaining why a blank value blocks every send.
• scripts/check_client.py: the check_sending() function above, in full.
• docs/outreach-playbook.md: the Compliance footer section, with the exact text every email ends with.
• README.md: the running numbers, 59 leads emailed, 69 messages counting follow-ups, 1 bounce.
• Commit 901c133: the exact diff that turned a missing footer into a blocked send.

The Question Worth Asking About Your Own Outbound

Most people running cold outreach cannot answer this: if tomorrow's email is missing the one line the law requires, does anything stop it from going out, or does compliance depend entirely on someone remembering to paste it into a template?

If the honest answer is "depends on someone remembering," that's worth an hour of attention before it's worth sending the next batch.

How Smart AI Workspace Approaches This

I'm Tariq Osmani, founder of Smart AI Workspace. Every engagement is founder-led: the person who scopes your build is the person who writes the code, which is also why I found this gap in my own outbound before it ever ran for anyone else's.

That order is deliberate. I would rather find a compliance gap in my own lead flow, at my own cost, than discover it in yours. When I audit a client's outbound, the first thing I check is whether the send path can refuse to send, not whether the template looks right. For the wider context on how this kind of work gets scoped, see what an AI workflow automation consultant actually does and how I price.

Get Your Outbound Audited

If you cannot say for certain what happens when your cold email is missing a required line, that's worth an hour of attention before it's worth a rebuild. Contact me for a free audit: I'll trace your outbound system end to end and tell you what breaks. See what I build, how I price, or check verified work history on my Upwork profile.

Case study three is in progress, and it follows the same rule: nothing in it you cannot check.

Sources: CAN-SPAM Act: A Compliance Guide for Business, FTC · Canada's Anti-Spam Legislation (CASL), Government of Canada · smai-leadgen, public repository · Commit 901c133, the compliance gate diff