Suppression list maintained; unsubscribed users never emailed

CAN-SPAM §5(a)(4), GDPR Art. 21, and CCPA §1798.120 all require that opt-out requests result in permanent cessation of marketing communications. Tracking opt-out status only as a boolean on the user record — rather than in a dedicated suppression table — creates a structural fragility: account reactivation, user import, or a provider migration can silently re-subscribe opted-out addresses. A dedicated suppression table that is append-only and provider-agnostic survives provider changes, list exports, and bulk data operations without losing the opt-out record.

Maintain a dedicated, append-only email_suppressions table in your primary database and filter every campaign send against it — never rely solely on the provider's suppression list.

-- Append-only suppression table — never delete rows
CREATE TABLE email_suppressions (
  id         UUID PRIMARY KEY DEFAULT gen_random_uuid(),
  email      TEXT NOT NULL,
  reason     TEXT NOT NULL CHECK (reason IN ('unsubscribe', 'bounce', 'complaint', 'manual')),
  created_at TIMESTAMPTZ NOT NULL DEFAULT now(),
  UNIQUE (email)
);
CREATE INDEX idx_email_suppressions_email ON email_suppressions (email);

// Filter every bulk send against the suppression table
const suppressed = new Set(
  (await db.$queryRaw<{ email: string }[]>`SELECT email FROM email_suppressions`)
    .map(r => r.email)
)
const eligible = recipients.filter(r => !suppressed.has(r.email))

Sync provider-side bounces and complaints back into this table (via webhook) so suppression is complete regardless of the send path.