An opt-out test should follow the request through the send decision. Use two checks: confirm that the recipient preference changed, then verify that a later send is stopped. A suppression list is a set of email addresses the workspace does not deliver to.1 An unsubscribe records the recipient's stated preference and lives on the Preferences tab.2 Keep those states separate in the test case. A confirmation page shows that the request was accepted, but it does not prove that the send path will honor it.
Run the test
- Prepare
- Trigger
- Inspect
- Gate
- Recheck
Give each checkpoint a different question. Move on only after you can see the expected state change.
| Stage | What you are trying to learn | Example question |
|---|---|---|
| Prepare | whether the test uses a live marketing message and an inbox with easy unsubscribe support, such as Gmail or Yahoo3 | Does this message expose the recipient-facing unsubscribe route? |
| Trigger | whether the request travels from the email link through database fulfillment4 | What record changes after I submit the request? |
| Inspect | whether the record has the right reason, applies_to policy, and category scope5, 6 | Which message category should this address leave? |
| Gate | whether the suppressed address is stopped before the send leaves the platform7 | What happens when I include this address in the next send? |
| Recheck | whether contact changes leave the suppression state intact8 | Did changing the contact record alter the send result? |
Test the request path
Use the same path as a recipient. Skipping the live message can hide a broken link, an incomplete header, or a request that never reaches the database.
Send a live marketing message to an inbox that supports easy unsubscribe, such as Gmail or Yahoo.3 Use the unsubscribe link in the message, or the easy unsubscribe control when it appears. Follow the request from that entry point through database fulfillment.4
After sending the test message, inspect its Unsubscription section to confirm that the list-unsubscribe header was injected.9 This checks the mailbox-level route separately. Continue only after exercising both the recipient-facing route and the header route, then record what changed in the underlying contact state.
Before the next send, verify that the test contact is suppressed.10 Keep the test address and its expected outcome visible during the next check so a successful click is not mistaken for a successful send block.
Read the resulting state
Check the record's scope before testing delivery. Decide what the opt-out should block, then compare the stored state with that expectation.
Each suppression record has a reason and an applies_to policy that controls which categories it blocks.5 Subscriptions are managed per Message Category.6 An unsubscribe from one category has no impact on subscriptions to other categories.11 Ask which category the request should affect and which categories should remain eligible.
For a full suppression test, expect the contact to receive no email from the account.12 For a category-level opt-out, test one send in the affected category and another in an unaffected category. Write the expected scope before triggering the request, because the pass condition differs between the two cases.
Prove the send gate
A correct preference record still has to control the path that creates a send. Test the address in the same kind of send operation that could otherwise reach it.
The platform stops sends to suppressed addresses before they leave the platform.7 Put the test address into a controlled send and inspect the result. Look for a blocked send, not only a changed preference record.
If the send is accepted, stop the test and trace the address through the suppression lookup, category policy, and final send decision. Do not continue sending to the address while you investigate. This check proves that the stored state reaches the enforcement point.
Re-test after changes
Run the same test after changes that could create a second copy of the contact or alter how a send is assembled. A working unsubscribe can lose coverage at this stage.
Suppression lists and contact records are separate stores.13 Changing or deleting a contact record leaves addresses on suppression lists in place.8 After a contact or list change, inspect the suppression state again and repeat the send-gate check. A contact that appears eligible in a list view has not necessarily cleared the suppression result.
Editing suppression lists requires specific steps to avoid emailing previously suppressed recipients and damaging sender reputation.14 Treat every removal, import, merge, and list rebuild as a reason to rerun the test path. If your workflow updates the contact preference through a later integration sync, test the request before the sync and the send gate after it completes. A documented flow updates the email Contact Preference during an overnight sync.15
Keep a record of the address, expected scope, observed preference state, and send result. This gives you a comparison point after system changes instead of relying on the status shown in a single interface.
What not to do
These shortcuts can produce false passes or create a route back to previously suppressed recipients.
- Treat a successful confirmation page as proof that database fulfillment worked. Follow the request through that stage.4
- Place an unsubscribe on the suppression list. An unsubscribe is kept as a preference record outside that list.16
- Change or delete a contact record and assume the suppression address has been removed.8
- Edit a suppression list without a controlled procedure for protecting previously suppressed recipients.14
- Keep mailing addresses that bounce or report spam during a test, because repeated mailings can get the domain blocked by mailbox providers.17