D-08 · COMPLIANCE · SUPPRESSIONS
Suppression list sync across vendors
Migrations fail on suppressions, not templates. This scenario treats unsubscribes, bounces, and complaints as portable truth synced before first send.
Symptom
A team ports templates to a new vendor over a weekend, imports the contact list, and launches Monday’s newsletter. By noon, spam complaints quintuple and the new domain reputation craters. The cause surfaces in the old vendor’s dashboard: 8,000 suppressed addresses — unsubscribes, hard bounces, complaint reporters — never exported. The “clean list” was everyone, including everyone who had opted out.
The legal shadow is worse than the reputation hit. Mailing unsubscribed addresses violates consent records in regulated regions, and the team cannot prove suppression continuity across the migration boundary.
Cause
Suppressions live in three places — vendor dashboards, app databases, and marketer spreadsheets — with three semantics: global do-not-mail (complaints, hard bounces), per-stream opt-out (newsletter unsub), and temporary holds (soft-bounce cooling). Migrations typically export only the mailable list, dropping the negative space that makes it legal and deliverable. Webhook history older than vendor retention windows vanishes entirely.
Scope confusion finishes the job: importing global suppressions as per-stream, or vice versa, either re-mails people who opted out globally or over-suppresses transactional alerts users still need.
Fix
Export suppressions first, categorized by type, reason, timestamp, and scope. Build a canonical suppression store in your own database — address, SHA-normalized, reason, source event, scope — and push it to every vendor before any bulk send. Seed the new vendor’s global suppression with complaints and hard bounces, per-stream unsubscribes with their stream mapping, and temporary holds with expiry. Verify counts match per category, not just totals.
Run a suppression canary: attempt test sends to a sample of suppressed addresses in sandbox or suppression-check mode and confirm rejection before production. Keep the old vendor’s suppression export archived with migration logs for audit.
Prevention
Make your database the system of record, with vendor suppressions as synced replicas fed by real-time webhooks. Reconcile nightly, alert on drift, and require suppression-sync confirmation in every launch checklist. Quarterly, re-export and diff — silent vendor-side expirations and stream remaps surface here before they surface as complaints.
Worked example
A media company migrates vendors over a weekend, importing 120,000 “active” contacts but leaving 8,000 suppressions behind. Monday’s newsletter re-mails 3,000 unsubscribed readers and 2,000 hard-bounce traps. Complaints quintuple, the new subdomain lands in spam within 48 hours, and legal flags the consent breach. Recovery costs six weeks of engaged-only sending.
The corrected rerun exports suppressions first — 4,100 unsubscribes scoped per stream, 2,900 hard bounces global, 1,000 complaints global — into a canonical database table, pushes them to the new vendor before any bulk, and canary-tests suppressed addresses in sandbox. Counts reconcile per category, the launch proceeds cleanly, and the archived export satisfies the later compliance audit. Suppressions first is now migration law.