Should ESPs use global suppression lists for hard bounces across different customers?

Key findings

• Data isolation: Standard practice among most ESPs is to maintain separate bounce (and suppression) lists for each customer. This prevents the commingling of data and ensures each client's sending reputation is managed independently.
• Legal implications: Using a shared global suppression list could potentially shift an ESP's role from a data processor to a data controller, especially under strict privacy regulations. This change in classification carries significant legal responsibilities and risks.
• PII concerns: Even an email address that has hard bounced is often considered Personal Identifiable Information (PII) if it can be linked back to an individual. Sharing this across unrelated customers, even if only to prevent future sends, raises privacy concerns. Learn more about what data ESPs should share with clients.
• Effectiveness: Some past experiences suggest that shared hard bounce suppression lists were not particularly effective at significantly reducing overall hard bounce rates or improving deliverability.
• False positives: Hard bounces can occasionally be false positives. A global blocklist might incorrectly prevent a legitimate email from being sent by another customer if the original bounce was erroneous.

Key considerations

• Reputation management: ESPs are responsible for protecting the collective sending reputation of their shared IPs. Suppressing known bad addresses is critical, but this can usually be achieved through internal, customer-specific suppression lists without cross-customer sharing.
• Customer autonomy: Each customer generally expects full control over their own data and recipient lists. Imposing a global suppression list (or global blacklist) may infringe on this expectation.
• Regulatory compliance: ESPs must ensure their data handling practices align with all applicable data protection laws. Sharing bounce data globally could necessitate complex legal justifications or explicit consent mechanisms that are difficult to implement and maintain. This is highlighted in the Amazon Web Services (AWS) documentation, which describes how their SES global suppression list handles email addresses that have recently caused a hard bounce for any SES customer.
• Bounce classification: Properly managing bounces is crucial. ESPs classify hard and soft bounces and decide how to manage these effectively on a per-customer basis to maintain deliverability.

Key opinions

• Data segregation: Marketers typically expect their data to be isolated from other customers' data within an ESP. The commingling of bounce data is seen as undesirable because it doesn't align with customer-centric data management practices.
• Customer autonomy: A marketer's main concern is often maintaining control over their subscriber lists and ensuring that their legitimate recipients are not inadvertently suppressed due to issues experienced by other ESP users. Effective management of hard bounced email addresses is usually a client-side responsibility, supported by the ESP.
• Deliverability impact: While preventing sends to invalid addresses is good for deliverability, marketers want assurance that such measures are precise and don't unfairly penalize their campaigns. Accurately classifying bounces is key to preventing emails from going to spam.
• Transparency needed: If a global suppression list is used, marketers would require full transparency from their ESP about how it operates, what data is included, and how it might affect their sending.

Key considerations

• Brand reputation: Marketers are highly focused on their brand's sending reputation. Any mechanism that could potentially link their sending behavior (or bounce rates) to that of other, potentially poor, senders is a significant concern.
• List hygiene: Instead of relying on a global list, marketers prefer robust internal tools for email list cleaning services to actively manage their own suppression lists. Retainful's blog notes that a global suppression list includes email addresses that should be excluded from all campaigns, no matter the type, but emphasizes the need for marketers to manage their own custom lists for compliance and efficiency. Read more about suppression lists here.
• Multi-brand scenarios: For a single customer operating multiple brands, the situation changes. Here, a shared internal suppression list across those brands could be logical and beneficial, provided it falls under a single data controller entity.

Key opinions

• Data controller risk: Experts agree that if an ESP shares hard bounce data from one customer with other customers in a global suppression list, the ESP risks becoming a data controller rather than just a data processor. This shift has significant legal and compliance implications.
• Consent and PII: Adding an email address to a global suppression list without the explicit consent of the original sender or the recipient (even if it's a hard bounce) can be problematic from a privacy perspective. The address, even if invalid, might still be considered PII if associated with a person's past activity.
• Limited utility: Some experts point out that despite the theoretical benefits, shared global suppression lists for hard bounces haven't proven particularly effective in significantly reducing overall hard bounce rates or improving deliverability in real-world scenarios, particularly across diverse customer bases.
• Debatable ownership: The ownership of an invalid email address, especially one that previously existed, is a debated point among privacy professionals. This ambiguity makes cross-customer sharing legally precarious.
• Shared vs. dedicated IPs: While global suppression lists are sometimes discussed in the context of shared IPs to protect the sending reputation, experts often suggest that other methods, such as stringent list quality requirements for senders, are more effective. Learn more about how high-spam emails from shared IPs impact deliverability.

Key considerations

• Context is key: The applicability of a global suppression list depends heavily on the specific context, such as a single customer managing multiple brands versus an ESP managing multiple independent customers. The Kickbox Blog discusses how global suppression lists are used by platforms and ESPs to protect all clients from sending to addresses or domains that may be problematic. You can find more details here.
• Compliance framework: Any global suppression mechanism must be clearly described within the ESP's privacy policy and data processing agreements. Without a robust legal ground, it is a high-risk practice.
• False positives and re-engagement: Even hard bounces can sometimes be transient or false positives. A global blocklist could prevent a legitimate email from reaching a recipient if the bounce was not truly permanent or if the recipient's status has changed. See our guide on in-depth guides to email blocklists.

Key findings

• Separation of concerns: Most ESP documentation implies a clear separation between an ESP's internal anti-abuse mechanisms (which protect the overall platform) and individual customer data. Bounce data belonging to one customer should not be directly shared with others.
• Hard bounce handling: Documentation consistently advises immediate suppression of hard bounces at the individual customer level. This is a critical step for maintaining good sender reputation. Understanding which SMTP bounce codes require suppression is vital.
• Data privacy obligations: Privacy policies often state that customer data is treated confidentially and is not shared or used for purposes beyond providing the service to that specific customer. This implicitly discourages global suppression lists across different customers based on PII.
• Compliance frameworks: Official guidelines related to GDPR, CCPA, and similar regulations necessitate clear consent and purpose limitation for data processing. Sharing bounce data across unrelated customers would likely fall outside these strict boundaries without explicit justification and consent.

Key considerations

• Internal vs. global lists: Some documentation refers to an ESP's own 'global suppression list,' but this typically refers to a list of known problematic addresses (e.g., spam traps, domains with persistent issues) that the ESP maintains internally to protect its overall infrastructure, not customer-specific hard bounces shared across clients. Mailchimp documentation, for example, explains how an ESP might automatically suppress hard bounces for a specific account.
• Role of the ESP: Documentation often defines the ESP's role as providing the tools and infrastructure for sending, with the client bearing the primary responsibility for list quality and compliance. ESPs classify and manage SMTP bounce codes to assist clients with their deliverability efforts.
• Abuse prevention: While ESPs take steps to prevent abuse (like sending to known spam traps), this is distinct from globally suppressing hard bounces from one customer for another's campaigns, especially if it involves specific email addresses that could be PII.