Propagating suppression changes across marketing tools

A suppression change is complete only when every relevant sending route has the right state, pending sends are checked and failures have an owner. Updating the main contact record alone does not establish that an email platform, SMS service or outside sender will stop.

For electronic commercial messages, the Spam Act 2003 requires unsubscribe requests to be actioned no later than five working days after the request. ACMA can investigate and act on reports. APP 7 requires an organisation permitted to use or disclose personal information for direct marketing to offer an opt-out and comply with the request.

Compliance Requirements for Suppression Requests

Map the routes

List each tool, agency feed, uploaded audience and scheduled export that can use the affected contact for marketing. For each, record the identifier it uses, the channels and messages it controls, how it receives a change and where its resulting state can be checked. A current central flag will not automatically repair an old file already held elsewhere.

Examples to check, if present in your stack, include Insider One, Klaviyo, Omnisend, Brevo, Mailchimp, ActiveCampaign, TextMagic and SlickText. Insider One, Klaviyo, Omnisend and Brevo combine email and SMS, while Mailchimp, ActiveCampaign, TextMagic and SlickText are channel-specific tools. Treat each sending-capable account, audience or outbound feed as a separate route.

Record the identifier each destination uses, such as an email address or phone number, and the form it expects. Keep a branded SMS or MMS sender ID distinct from the contact identifier: it identifies the sender, not the recipient.

Preserve the scope of the request. An email unsubscribe may apply to an address, a sender or a wider preference, depending on what the person requested. “No marketing across channels” needs more than an email-only block. If a destination cannot be matched confidently, hold affected marketing and investigate the identity rather than changing a guessed record.

Send a change that can be checked

Give each withdrawal or suppression event a stable reference, received time and scope. Send each destination only the identifiers and instruction it needs, using the route recorded for that destination. Record the attempt time, response and state observed at the destination; reuse the event reference when investigating a retry, and do not assume the destination API deduplicates repeated requests.

For example, if Mailchimp and TextMagic are both in your stack, give each its own route entry and check each response and suppression state separately. An acknowledgement from one destination is not evidence that the other received or applied the change.

These are reconciliation outcomes, not universal platform statuses. An acknowledgement of receipt may still need a separate check that suppression took effect.

Prevent stale data from restoring eligibility

Choose which record governs suppression. A later profile sync should not turn a withdrawn contact back on merely because its source says subscribed. A later permission needs a new, suitably scoped event and a rule for how it affects the earlier withdrawal; retain both events.

Regenerate batch audiences from current eligibility before release, then inspect the set held by the actual sender. With an agency or provider, document how withdrawal requests return to the business, how updates are confirmed and who investigates failures.

Assign an owner to each destination who can investigate a failed update and confirm the final state. Record who is responsible for holding the affected route while its state remains uncertain.

Reconcile before the next affected send

Compare the central state with every destination that could still act. Prioritise rejected and timed-out updates, uncertain identity matches and sends scheduled before the change. If a destination cannot be checked in time, hold its affected marketing route until its state is known.

For a timeout, retry using the same event reference and check the destination state again before marking the change reconciled. A successful transport response alone does not prove that suppression took effect.

Ensure unsubscribe requests are acted on across the full sending arrangement, within the Spam Act 2003 limit of five working days, and verify affected routes before the next send. A controlled check can submit a withdrawal through each intake route, then inspect each destination and any queued send.