Master–Sub Account Suppression and Unsubscribe Logic

Master–Sub Account Suppression and Unsubscribe Logic

This guide explains how suppression statuses function when accounts are linked in a Master–Sub Account relationship. When accounts belong to the same account group (e.g., Accounts A, B, and C), they reference one another to enforce shared suppression rules for Unsubscribes and Spam complaints.

Master–Sub Account Relationship

In this configuration, accounts are linked to allow for shared data governance. If you have a Master account (Account A) and Sub accounts (Account B and C), actions taken by a contact in one account will affect their status in the others to ensure compliance and list hygiene.

1. Unsubscribe Propagation

When a contact unsubscribes, the system distinguishes between the account where the action took place and the other linked accounts.

The Rule

  • Source Account: The account where the unsubscribe occurred marks the contact as Unsubscribed.
  • Other Linked Accounts: All other accounts in the group mark the contact as Inactive.
The Inactive status on linked accounts prevents future sends while preserving the data trail. The reason field is automatically updated to indicate exactly where the unsubscribe originated.
  1. Example Scenario

A contact, user1@example.com, unsubscribes specifically from Account B (Sub).
Resulting Statuses:

Account
Status
Reason
A (Master)
Inactive
Unsubscribed from Account B
B (Sub)
Unsubscribed
Customer Unsubscribed
C (Sub)
Inactive
Unsubscribed from Account B

Behavior Note: Account B stores the original event. Accounts A and C inherit the suppression, and the reason field preserves the source account name for auditing purposes.

2. Spam Complaint Propagation

Spam complaints are treated with higher severity than standard unsubscribes. To protect your domain reputation, these are applied globally across the group immediately.

The Rule

  • Spam Complaint: If a complaint is received in any account, the email address is marked as Spam across all linked accounts.

Example Scenario

A feedback loop complaint is received from user2@example.com regarding an email sent from Account C (Sub).
Resulting Statuses:

Event Type
Status in Source Account
Status in Other Accounts
Stored Reason Format
Unsubscribe
Unsubscribed
Inactive
Unsubscribed from Account X
Spam Complaint
Spam
Spam
Spam complaint (Account X)


Use this table  to verify how status changes are reflected across your Master and Sub accounts based on the event type.