Email suppression list checklist for form follow-up

Stable definition and boundary

An email suppression list is an enforceable record of addresses or identities that must not receive a defined class of email. It is different from segmentation: a segment selects possible recipients, while suppression removes recipients who are not permitted or safe to message.

A form submission can add new contact context or request a service response, but it does not by itself cancel a prior stop event. Store the new request beside the existing evidence, then evaluate the exact sender, channel, purpose and message class before delivery.

Stop-state precedence model

The most restrictive applicable state wins inside its documented scope. Treat unknown scope as a review condition, not permission. A new form submission must not silently erase an earlier complaint, bounce or opt-out, and a purpose-specific re-consent must not revive unrelated subscriptions.

Keep promotional material out of receipts, password resets, one-time codes and other narrowly transactional messages. A message does not become transactional merely because a workflow labels it that way.

Suppression-event contract

Append events instead of overwriting the history. Derive the current state from the applicable events and policy version so an import, delayed webhook or retry can be reconciled without destroying evidence.

Worked merge example

A person unsubscribes from a newsletter, later submits a product-consultation form and requests one response. The requested service reply is evaluated under its own narrow purpose; the newsletter suppression remains in force. The consultation does not place the address back into the newsletter segment.

If the form contains a separate marketing choice and the person affirmatively selects it, record a new purpose-specific event with the choice, notice version and time. Do not delete the earlier evidence. The new event can change only the scope it actually covers, subject to any stricter complaint, bounce or legal hold.

The follow-up workflow may use answers to choose useful content, but it must intersect that candidate path with the current suppression state. Use the lead follow-up sequence contract for timing and stop rules and the consent-record checklist for purpose evidence.

Send-time enforcement method

1. Normalize without guessing.Store the submitted address and a documented normalized form; do not merge distinct mailboxes solely because they look similar.
2. Collect stop events.Ingest provider complaints and bounces, form choices, unsubscribe requests, imports and support corrections with source timestamps.
3. Resolve identity carefully.Link events to the intended address and contact while preserving conflicts for review.
4. Calculate scope.Evaluate sender, channel, list, purpose, message class and any stricter global stop under the current rule version.
5. Intersect after segmentation.Build the eligible audience, then remove suppressed recipients immediately before each send, including messages released after a wait.
6. Record the decision.Keep the candidate message, evaluated events, rule version and allow, suppress or review outcome.
7. Recheck retries.A replay or provider recovery must run the current state again rather than reuse an earlier allow decision.

Do not rely only on a weekly export or a campaign-level exclusion copied at launch. A person can unsubscribe during a wait, a provider can report a complaint after queueing and a hard bounce can arrive before the next step.

Current source boundary

As checked October 11, 2026, Google's subscription guidelines define subscription messages separately from transactional messages such as password resets, receipts and one-time passcodes. They require one-click unsubscribe for subscription messages and say requests should be honored within 48 hours.

Google's current email sender guidelines require qualifying marketing and subscribed messages to support one-click unsubscribe and include a clearly visible body link. The documented headers are List-Unsubscribe-Post: List-Unsubscribe=One-Click and an HTTPS List-Unsubscribe URL.

RFC 8058 defines the authenticated one-click mechanism: the DKIM signature covers both list-unsubscribe headers and the receiver sends an HTTPS POST without redirect, cookie or authentication context. These sources describe subscription control and transport; they do not define every jurisdiction's lawful basis or every provider's suppression scope.

Current involve.me Email Automation documentation says the opt-out link cannot be removed, that once someone opts out they receive no further workflow emails, and that conditional branches can evaluate opt-in status or segment membership during a sequence. Those are useful platform controls, not evidence that every external import, alias or provider complaint is reconciled automatically.

Ten-case suppression proof test

1. Unsubscribe during a wait:the pending marketing message is suppressed when the wait ends.
2. Complaint event:all marketing in the documented sender scope stops before the next attempt.
3. Hard bounce:retries stop until a corrected address is verified under policy.
4. Duplicate contact:the stricter event applies across records linked to the same sending address.
5. Case variant:normalization finds the applicable stop without corrupting the submitted value.
6. Alias change:the system neither over-merges distinct mailboxes nor loses linked evidence.
7. New service request:the requested reply stays narrow and the prior marketing stop remains.
8. Purpose-specific re-consent:only the documented purpose changes, unless a stricter stop still applies.
9. External import:missing or older permission data cannot overwrite a current suppression event.
10. Provider outage and replay:recovered sends re-evaluate the latest state and cannot resurrect a suppressed recipient.

Run the cases with synthetic contacts in the published form, contact store, workflow and delivery provider. Record the observed state and correction path using the end-to-end form testing checklist.

Evidence and limitations