GDPR and ESP Suppression Lists

Source: M3AAWG Support Document: The GDPR and ESP Suppression Lists, December 2024. The document's own caveat applies here too: it is not legal advice — background for ESPs considering suppression-list practice; specific legal questions go to counsel. Fetched from the final-revision URL (the_gdpr_and_esp_suppression_listsfinal.pdf); the originally circulated URL now 404s.

The tension in one paragraph

An ESP suppresses addresses so that no mail is sent to them — the deliverability-protective act the whole industry expects (see List Hygiene & Sunset Policies, and the operational design in Suppression-List Architecture). But under GDPR, every act of processing personal data needs a legal basis, and email addresses are personal data. When an ESP suppresses an address its client did not instruct it to suppress, the ESP is acting outside the client's instructions — which can convert the ESP from a low-liability Data Processor into a Data Controller with full controller obligations. Meanwhile, a "right to be forgotten" (erasure) request appears to demand deleting the very record the ESP needs to retain in order to guarantee the person is never mailed again.

Definitions (GDPR Article 4)

• Data Controller — any "body which, alone or jointly with others, determines the purposes and means of the processing of personal data…" (Art. 4(7)).
• Data Processor — any "body which processes personal data on behalf of the controller…" (Art. 4(8)).

Being a Processor carries less risk and liability — provided the ESP can show it followed the controller's instructions and did not process data for any purpose or by any means beyond what the controller determined.

Are email addresses personal data?

Generally yes. Exceptions exist — generic role addresses (info@example.com) or generic reply addresses (lotteryentry@example.com) — but design systems on the assumption that all email addresses involved are personal data. The domain itself can be personal data, e.g., js@john-smith.example.com.

Legal basis for the ESP-as-Processor sending mail on a client's behalf: the contract with the client (Art. 6(1)(b)). ESPs can suppress non-personal data (such as known spam traps) without engaging the GDPR at all — where the trap address is genuinely not personal data.

The 13 events that drive suppression

M3AAWG enumerates the circumstances in which suppression arises, each with different GDPR character:

#	Event	GDPR notes
1	Invalid addresses (nonexistent TLD, e.g. example.con)	Objectively invalid — suppressing addresses that cannot possibly be valid involves no personal-data processing outside the contract
2	Addresses likely to be invalid (common typo domains, e.g. hotmial.com for hotmail.com)	ESPs may block the domain globally
3	Country-code suppression (sanctions regimes, country-specific rules e.g. gambling)	Per-ESP judgment; .de (Germany) treated differently than .tv (Tuvalu, widely non-geographic)
4	Disposable/single-use addresses	⚠ Suppressing these when the client contract does not envision it may make the ESP a Data Controller
5	Role addresses (noreply@…) inconsistent with the mail's nature	Case-by-case: some role addresses are directly assignable to known individuals and hence personal data
6	Email delivery failures (server refuses; nonexistent address, mailbox "full", content deemed unacceptable)	Where failure is very likely to recur for a given mail (or type), stop attempting
7	Bounce messages (asynchronous failure after apparent acceptance)	Analyze the reason; may justify no further attempts
8	Feedback-loop info (provider reveals spam-foldering / marked-as-spam)	May indicate further delivery should be suppressed
9	Opening/engagement information (instrumented mail; prolonged non-engagement)	Engagement-based sunsetting is itself a processing act
10	Requests to unsubscribe (hand-crafted, link clicks, header-driven client unsubscribes)	Further email needs to be suppressed
11	Abuse complaints (correspondence showing mail from this sender is unwanted)	Suppress for that sender
12	Known spam-trap addresses	Sending harms the sending IP/domain reputation, degrading delivery for everyone; ESP may suppress (often non-personal data)
13	Requests to be forgotten	Erasure request from a data subject in a GDPR (or similar) territory, or instruction to stop processing their personal data

Also: removing an address because its owner is known to be deceased involves no personal data — the dead do not have rights under GDPR.

Per-client suppression lists: safe Processor territory

Suppression lists operated per-client — composed of people who marked that sender's mail as spam, unsubscribed, or whose addresses bounced — can be run while remaining "just a Data Processor." Conditions the ESP-client contract should make explicit:

• How suppression works in practice: on a bounce, does the ESP track it on the client's behalf, or must the client update their own list?
• End of contract: how does the client (the Data Controller) learn about unsubscribe requests received via the ESP? The client is obliged to honor those requests even when later sending through a different ESP.

Global suppression lists: Controller territory

ESPs may see global (cross-client) suppression as essential to staying in business — it becomes hard to serve any client well if clients keep mailing spam traps or serial complainers. But:

• Using the ESP's own suppression list to block addresses the client instructed it to mail is action contrary to the contract to act "on their behalf" — the ESP is then "determining the purposes and means of the processing," i.e., has become a Data Controller.
• It is "very likely" the ESP is acting beyond the Processor role if it maintains its own suppression list to block specific addresses — e.g., individuals antagonistic to the ESP's business, role accounts, trap domains, known hard bounces, and so forth.
• If an ESP operates a global suppression list, the client contract should cover how it is applied, so the client can meet its own Controller obligations. Data-protection complications generally occur whenever the ESP takes actions the client did not request.
• An ESP that has become a Controller must operate accordingly; the document points to the UK ICO controllers checklist as a starting point: https://ico.org.uk/for-organisations/sme-web-hub/checklists/data-protection-self-assessment/controllers-checklist/

Handling "forget me" requests — the practical resolution

The document's implicit resolution of the erasure-vs-suppression tension:

1. An erasure/stop-processing request received by the ESP concerns data the ESP processes on behalf of clients — route and record it in a way the contract anticipates.
2. The contract between the ESP and their client should make clear how this type of suppression will work in practice — that is the load-bearing sentence: the lawful way to keep a suppression record after an erasure request is to have contractually defined it as part of the processing the Controller instructed.
3. Distinguish suppression classes: objectively-invalid and non-personal (traps) suppression is unproblematic; per-client consent-driven suppression is Processor work under contract; ESP-initiated global suppression is Controller work requiring the ESP to shoulder Controller duties.

Operational checklist for an ESP

• Write suppression behavior (per-client and any global list) explicitly into the DPA/contract, including disposable-address and trap suppression.
• Define contract-end data handoff: unsubscribes and complaints must reach the client, who stays bound by them at their next ESP.
• Treat all addresses as personal data by default; carve out only objectively non-personal cases.
• If operating a global suppression list, accept the Controller analysis: document purposes, legal basis, retention, and subject-rights handling (ICO checklist above).
• Refer "am I a Processor or Controller here?" questions to legal counsel — the document repeats this twice.

Related: Suppression-List Architecture (the operational companion — how the per-client vs. global split above is built) · CAN-SPAM · CASL · UK PECR · Complaint Feedback Loops · List-Unsubscribe.