A complaint report is an input to a workflow, not proof that the workflow has finished. The real outcome is that the relevant sending systems stop the unwanted communication while preserving the evidence needed to explain the decision. Design the pipeline around trust, correlation, scope and enforcement.
Validate the report before extracting an instruction
RFC 5965 defines a multipart feedback report containing human-readable information, machine-readable fields and returned message material. It also addresses forgery and privacy risks. Parse MIME with explicit size and nesting limits; do not execute returned content or follow links embedded in it. RFC 5965.
Require provenance appropriate to the provider and receiving system. A matching display name is not enough. Preserve trusted authentication results from the receiving boundary rather than accepting attacker-supplied headers at face value. Keep an untrusted or malformed report in a restricted review queue, distinct from an actionable complaint.
Correlate and choose the authorized scope
Resolve the report against the sending application's retained identifiers. The output should identify a subscriber, stream and complaint event with a documented confidence basis. If a report lacks a safe unique match, keep it unresolved. Do not suppress every person who received a message with the same subject.
Apply the organization's approved suppression policy. A promotional complaint may require removing that recipient from marketing, while essential account-security communications require a separate service and policy decision. Do not describe that distinction as permission to repackage promotions as transactional mail. Honor the recipient's expressed preferences and applicable obligations with the responsible business owner.
Make persistence and enforcement separate checkpoints
Write the suppression decision durably before acknowledging successful processing. Propagate it to every relevant sender, and verify that scheduling or queue preparation consults the current suppression state. A database row that the campaign engine never checks is not effective suppression.
Use a stable event key to make duplicate reports harmless. Record first receipt, decision time, downstream acknowledgement and any retry. If a downstream service is unavailable, retain a retryable task and prevent the workflow from reporting fully enforced success. Avoid deleting the original event merely because one API call succeeded.
Separate a supported decision from an unresolved report
Consider hypothetical Alice/News, Alice/Security and Bob/News subscriptions. A complaint whose source has been independently validated and whose retained send identifier uniquely maps to Alice/News supports a decision under the organization’s approved scope. Under this deliberately narrow teaching policy, Alice/News is suppressed while the other two records are unchanged. This policy example is not a legal determination about every complaint.
An untrusted report or a send identifier with two plausible subscribers does not support guessing. Keep it in restricted review and request the missing provenance or correlation evidence. A repeated validated event should retain the same intended suppression without creating a second unrelated action. No reports were processed or subscriptions changed for this example.
Test the complete failure path
Before production enablement, exercise duplicate delivery, parser failure, expired correlation records and downstream outages. Verify that support staff can see pending enforcement without viewing unnecessary message content. Define retention for raw reports separately from the minimum suppression record needed to avoid resending unwanted mail.
Review re-subscription deliberately. A later import should not erase a complaint suppression merely because it contains an older “subscribed” value. If the person makes a new valid subscription choice, preserve the evidence and approved process for that transition. Finish with a measurable outcome: verified complaint, supported identity, approved scope and confirmed enforcement, or an explicitly pending gap.
Keep a downstream outage visible
Suppose the suppression decision is stored durably, but the campaign service is unavailable. Mark enforcement pending for that specific sender and retain a retryable task. Receiving the complaint again should find the existing event, not create another outbox item or erase the pending decision. A later acknowledgement must correspond to the intended recipient, scope and sender.
Distinguish an API acknowledgement from verification that the next audience-selection path actually honors the change. If a stale export can bypass it, the suppression is not fully enforced. These are proposed state and evidence requirements, not an executed persistence or outage experiment. In an authorized implementation test, retain decision time, downstream attempts and the controlled next-send exclusion.
Assign the remaining enforcement work
For a durable decision with pending enforcement, retain the specific event and downstream target, next retry and owner. Restore the failing route without losing the decision or creating duplicate side effects. Report completion only when the intended sending path honors it.