GDPR and ESP Suppression Lists

If you run an email service provider (ESP) with clients or recipients in the EU, suppressing an address can change your role under the General Data Protection Regulation (GDPR). Depending on who decided the suppression, you remain a Data Processor or become a Data Controller.

The guidance below comes from M3AAWG Support Document: The GDPR and ESP Suppression Lists, December 2024. The document's own caveat applies here too: it is not legal advice. It is background for ESPs reviewing their suppression-list practice, and specific legal questions should go to counsel. The document was fetched from the URL of its final revision (the_gdpr_and_esp_suppression_listsfinal.pdf). The URL originally circulated now returns 404s.

The conflict between suppression and erasure

An ESP suppresses addresses so that no mail is sent to them. The whole industry expects this, because it protects deliverability (see List Hygiene & Sunset Policies, and the operational design in Suppression-List Architecture).

Under GDPR, however, every act of processing personal data needs a legal basis, and email addresses are personal data. When an ESP suppresses an address that its client did not instruct it to suppress, the ESP is acting outside the client's instructions. That can turn the ESP from a Data Processor, with low liability, into a Data Controller, with all of a controller's obligations.

At the same time, a "right to be forgotten" (erasure) request seems to demand that the ESP delete the very record it needs to keep in order to guarantee that 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, as long as the ESP can show that it followed the controller's instructions and did not process data for any purpose, or by any means, beyond what the controller decided.

Are email addresses personal data?

Generally, yes. There are exceptions, such as generic role addresses (info@example.com) or generic reply addresses (lotteryentry@example.com), but design systems on the assumption that all the email addresses involved are personal data. The domain itself can be personal data, for example js@john-smith.example.com.

When the ESP sends mail on a client's behalf as a Processor, its legal basis is the contract with the client (Art. 6(1)(b)). ESPs can suppress data that is not personal (such as known spam traps) without the GDPR applying at all, provided the trap address really is not personal data.

The 13 events that drive suppression

M3AAWG lists the situations in which suppression arises. Each has a different character under GDPR:

In addition, removing an address because its owner is known to have died involves no personal data, because the dead do not have rights under GDPR.

Per-client suppression lists: safe Processor territory

An ESP can run suppression lists for each client separately, made up of the people who marked that sender's mail as spam, unsubscribed, or whose addresses bounced, and remain "just a Data Processor". The contract between the ESP and the client should make these conditions explicit:

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

Global suppression lists: Controller territory

ESPs may consider a global suppression list, shared across clients, essential to staying in business. It is hard to serve any client well if clients keep mailing spam traps or people who complain repeatedly. However:

• Using the ESP's own suppression list to block addresses that the client instructed it to mail goes against the contract to act "on their behalf". The ESP is then "determining the purposes and means of the processing", which means it has become a Data Controller.
• It is "very likely" that the ESP is acting beyond the Processor role if it keeps its own suppression list to block specific addresses, for example individuals hostile 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 say how it is applied, so that the client can meet its own obligations as Controller. Data-protection complications generally arise whenever the ESP takes actions the client did not request.
• An ESP that has become a Controller must act as one. 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 does not state a resolution of the conflict between erasure and suppression outright, but it implies one:

1. An erasure or stop-processing request that the ESP receives concerns data the ESP processes on behalf of clients. Route it and record it in the way the contract provides.
2. The contract between the ESP and their client should make clear how this type of suppression will work in practice. This is the key sentence. The lawful way to keep a suppression record after an erasure request is for the contract to have defined that record as part of the processing the Controller instructed.
3. Distinguish the kinds of suppression. Suppressing addresses that are objectively invalid or not personal (traps) raises no problem. Suppression for each client, driven by consent, is Processor work under the contract. Global suppression started by the ESP is Controller work, and the ESP must take on a Controller's duties.

Operational checklist for an ESP

• Write the suppression behavior (for each client, and any global list) explicitly into the data processing agreement (DPA) or contract, including the suppression of disposable addresses and traps.
• Define how data is handed over when the contract ends: unsubscribes and complaints must reach the client, who stays bound by them at its next ESP.
• Treat all addresses as personal data by default, and make exceptions only for cases that are objectively not personal.
• If you operate a global suppression list, accept that you are a Controller: document the purposes, legal basis, retention, and handling of data subjects' rights (see the ICO checklist above).
• Refer questions of whether you are a Processor or a Controller in a given case to legal counsel. The document says this twice.

Related articles

• Suppression-List Architecture, on how the split between per-client and global suppression is built
• CAN-SPAM
• CASL
• UK PECR
• Complaint Feedback Loops
• List-Unsubscribe