Unsubscribe once, stop everywhere: build suppression above the individual outbound mailbox

What is authoritative in this case

Receiver guidance for bulk or promotional mail increasingly expects easy unsubscribe handling, but the systems problem exists even at small scale: one human address can be queued from several mailboxes, campaigns, or workers.

If several mailboxes contact the same lead, an unsubscribe must live above the mailbox queue. Storing it only in the account that received the request creates a race where another sender, sequence, or campaign can continue messaging the same person. The suppression key should match the identity model you actually use—typically a normalized recipient address, with any additional contact-level mapping applied deliberately—and every scheduler should consult the shared suppression source immediately before send. This is an application-state problem as much as a message-content problem: a perfect unsubscribe link cannot protect the recipient if the send workers do not share the resulting state.

The assumption most likely to age badly

Marking one sequence “cancelled” is not equivalent to suppressing the recipient. Another campaign can create a fresh sequence because it does not know about the local cancellation record.

The dangerous shortcut is a nightly “sync unsubscribes” job. A follow-up can be scheduled minutes after a recipient opts out, long before the next batch copy reaches other mailboxes. Another failure mode is treating each campaign as an independent universe and allowing a new sequence to import the address again. Decide what the unsubscribe scope means for your operation and encode that scope explicitly. For a small outbound team, a global suppression by recipient is often simpler and safer operationally than trying to maintain subtle campaign exceptions that every worker must interpret identically.

How to verify with independent evidence

Search the database for all jobs keyed to the recipient, including aliases of normalized casing where applicable. Trigger a controlled opt-out and verify that every mailbox sees the same suppression before dequeue.

Test the system as a concurrency case. Put the same test recipient into two sequences assigned to different mailboxes. Trigger an unsubscribe from the first message while the second worker already has a future job queued. The database should record the suppression, and the second worker should re-check that state at execution time and cancel rather than relying on the state captured when the job was created. Repeat with an API import or manual CSV upload to confirm the suppressed identity cannot be casually reintroduced. This fixture catches more real bugs than testing the link on one isolated mailbox.

A repair that remains maintainable

Use a central suppression table or service keyed to the address and reason, and make the final send transaction check it atomically before the provider API call. Keep sequence state as a separate layer.

Log the suppression event once with source, timestamp, normalized identity, scope, and the request or message that caused it. Workers can then record “send skipped: global suppression” without creating duplicate unsubscribe rows. Make the write idempotent so repeated one-click requests or duplicate reply processing do not create inconsistent state. Backups and migrations must preserve this table before campaign data because losing suppression while keeping queues is the worst recovery order. When adding a new sending channel or mailbox, make shared suppression a launch prerequisite, not a later deliverability enhancement.

How the issue appears in day-to-day outbound

Mailbox A and mailbox B can both have pending step-two jobs at 09:00. An opt-out at 08:59 must make both jobs ineligible even if each worker loaded its queue earlier.

The same shared table can support other irreversible recipient-level stops, but preserve reason priority. An unsubscribe or complaint should not be overwritten by a later “hard bounce” event, nor should a transient bounce clear a prior stop. Use an append-only event history or at least retain the earliest/strongest reason and timestamps so imports cannot silently resurrect the contact. At send time, make the guard cheap enough to run for every message; performance is not a reason to cache suppression for hours. If the system must cache, design invalidation so a new opt-out propagates immediately. For disaster recovery, restore suppression before queues and campaigns. A backup that brings back scheduled sends but not the opt-out table can create a burst of mail to people who already said stop.

What belongs beside the raw artifact

Record recipient, suppression reason, source message or endpoint, timestamp, campaign context, and which queued jobs were cancelled as a consequence.

Avoid solving a local problem with a global change

This guide is about reliable state propagation, not legal interpretation. Your obligations can vary by jurisdiction and message type; the technical system should at minimum honor the state you have decided to enforce.

Run a regression test whenever a new mailbox, queue, or import path is added. A suppressed test recipient should be rejected at import or at final send authorization no matter which mailbox owns the job. This single fixture catches the most dangerous integration mistake: a new component that bypasses the shared stop state because it was built against campaign tables only.

Field checklist

• Capture the raw evidence for global unsubscribe suppression across outbound mailboxes before editing DNS, queue state, or mailbox metadata.
• Confirm the cited mechanism using oneclick-rfc, gmail-faq rather than a generic deliverability score.
• Keep a known-good control case so the failing layer can be compared without changing several variables at once.
• Apply the narrow repair described for Unsubscribe once, stop everywhere: build suppression above the individual outbound mailbox and preserve a rollback or retry path.
• Repeat the original failing test after the change; do not substitute a different checker as proof of recovery.
• Store timestamp, affected identity, raw result, action taken, and the post-change result in the operator log.