GDPR-Compliant Email Operations for European Senders

• November 2018
• Engineering Memo · External Release

The General Data Protection Regulation (GDPR) entered into force on 25 May 2018, establishing the broadest data protection framework that European email senders have operated under. For email marketing specifically, GDPR creates requirements that extend well beyond the consent collection moment — they govern how contact data is stored, how long it is retained, what happens when a contact exercises their data rights, and how the infrastructure that processes contact data is configured and documented.

This note documents the email-specific implications of GDPR for infrastructure operators: which processing activities require documentation, what contact data fields create compliance obligations, and how the technical architecture of the email sending stack must be designed to support compliance obligations efficiently.

Lawful Basis for Email Marketing Under GDPR

GDPR Article 6 requires that every processing activity involving personal data has a documented lawful basis. For email marketing to EU residents, the two most commonly applicable lawful bases are:

Consent (Article 6(1)(a)): The data subject has freely given, specific, informed, and unambiguous consent to receiving marketing email. For email marketing, consent must be: freely given (not bundled with unrelated services or as a condition of providing services), specific (for the type of email communications described), informed (the sender's identity and the nature of the communications are clearly stated), and unambiguous (by a clear affirmative action — a pre-ticked checkbox is not valid consent under GDPR). Consent must also be as easy to withdraw as to give — the unsubscribe mechanism must be at least as accessible as the original consent mechanism.

Legitimate interest (Article 6(1)(f)): Legitimate interest may be available for email marketing to existing customers about similar products or services (the "soft opt-in" concept familiar from pre-GDPR ePrivacy Directive guidance). The legitimate interest basis requires a three-part test: the interest must be legitimate and real, the processing must be necessary for the purpose, and the interest must be balanced against the data subject's interests and fundamental rights. Legitimate interest is not available as a blanket justification for email marketing — it requires a documented balancing test specific to the use case.

The practical infrastructure implication: the lawful basis for each contact in the email list must be recorded and accessible. A contact whose lawful basis is consent must have the consent event recorded — the date, the mechanism, and the specific communications consented to. A contact whose lawful basis is legitimate interest must have the balancing test documented at the programme level. If a contact challenges the lawful basis or exercises their right to erasure, the infrastructure must be able to produce the consent record or the legitimate interest documentation quickly.

Data Minimisation and the Fields You Actually Need

GDPR's data minimisation principle (Article 5(1)(c)) requires that personal data collected and processed is "adequate, relevant and limited to what is necessary in relation to the purposes for which they are processed." For email marketing, this means the contact database should contain only the fields necessary to send and manage the email relationship — not every data point that might someday be useful.

The minimum necessary fields for email marketing: email address (required), first name (for personalisation — but only if the programme uses it), consent date and mechanism (for lawful basis documentation), and suppression status (for processing unsubscribes and opt-outs). Additional fields — surname, phone number, full postal address, purchase history, demographic data — are only compliant to hold if they are used for a specific documented purpose and are covered by the lawful basis under which the contact was acquired.

The infrastructure implication: MailWizz contact databases often accumulate fields over time as programmes add tracking, segmentation, and personalisation features. Each field addition should trigger a data minimisation review: is this field necessary for the programme's legitimate purpose? Is it covered by the existing lawful basis? If the answer to either question is no, the field should not be added to the contact record. Fields already in the database that cannot be justified under a current lawful basis should be removed in a documented data minimisation exercise.

Click and open tracking data creates a specific data minimisation question: is the individual-level tracking of each recipient's interaction with each email campaign necessary, or would aggregate analytics (campaign-level open rate, campaign-level click rate) serve the programme's legitimate purpose? Individual-level tracking enables personalisation and engagement-based segmentation — both of which have legitimate purposes. Aggregate-only analytics cannot support these purposes. The case for individual tracking data can generally be made on the basis of legitimate interest, but the privacy policy must disclose the tracking and explain its purpose.

Data Retention: How Long Can You Keep Contact Data?

GDPR does not specify specific retention periods for email marketing data — it requires that data be "kept in a form which permits identification of data subjects for no longer than is necessary for the purposes for which the personal data are processed" (Article 5(1)(e)). For email marketing, this means the contact data retention period should be linked to the active email relationship — how long data can reasonably be retained depends on the programme's sending frequency and the contact's engagement.

A practical retention policy that many EU-focused email programmes use: active contacts (those who have received email and have not unsubscribed) are retained as long as the email relationship continues and the lawful basis remains valid. Inactive contacts (those who have not engaged in a defined period, typically 12–24 months) should be either suppressed (no longer sent marketing email) or deleted, unless a specific legitimate interest justification supports retaining their data.

The operational implementation: MailWizz can be configured with automated list hygiene rules that flag or suppress contacts who have not opened or clicked in a specified period. These automated rules serve double duty — improving deliverability by removing disengaged contacts from the active list, and supporting GDPR retention compliance by removing contacts for whom the original purpose of the data collection (active email marketing) is no longer being served.

Suppression lists present a specific retention question: when a contact unsubscribes, GDPR's right to erasure (Article 17) may require deleting their data on request. But permanently deleting all record of the contact creates a risk — if the contact's email is re-acquired through a future acquisition source, the programme has no record that this person previously unsubscribed. The standard approach is to retain a minimal record on the suppression list — email address only, suppression date, and suppression reason — under the legitimate interest of preventing re-sending to someone who has explicitly opted out. This minimal retention satisfies both the right to erasure (all other data is deleted) and the operational need to prevent re-sends.

Data Subject Rights: Infrastructure Requirements

GDPR grants data subjects (email recipients) several rights that the infrastructure must be able to support within specific timeframes. The most operationally significant for email programmes:

Right to erasure (Article 17). When a contact requests deletion of their data, all personal data in all systems that process it must be deleted within one month. For an email programme, this includes: the contact record in the ESP/MailWizz database, the tracking data (open and click records), any segmentation data, the consent record (which is in tension with the right to erasure — document the resolution approach in your privacy policy), and any backup data that contains the contact's information. The technical challenge is identifying and deleting the contact's data across all systems — not just the primary ESP, but also any analytics systems, CRM integrations, and third-party tools that receive contact data.

Right of access (Article 15). Contacts can request a copy of all personal data held about them. The infrastructure must be able to generate a complete report of all data held about a specific contact across all systems. For MailWizz deployments, this requires querying the subscriber table, the tracking tables, the suppression list, and any custom fields to produce a complete data export for the specific contact. Automation of this process — a script or admin interface function that can generate the complete data report on request — is more reliable than manual data compilation under the one-month response SLA.

Right to portability (Article 20). Contacts can request their data in a machine-readable format that they can transfer to another service. For email marketing, this typically means the email address, consent date, and preferences in a standard format (CSV or JSON). MailWizz's built-in export functions can support this requirement with appropriate configuration.

Data Processing Agreements with Infrastructure Providers

GDPR Article 28 requires that when a data controller (the email programme operator) uses a data processor (any third party that processes personal data on the controller's behalf), a written Data Processing Agreement (DPA) must be in place. For email marketing, this requirement covers every system that processes contact data: the ESP or sending platform, the MTA provider (if managed), the list cleaning/validation service, the analytics platform, and any other tool that receives email addresses or engagement data.

The DPA must specify: the subject matter and duration of the processing, the nature and purpose of the processing, the type of personal data involved, the categories of data subjects, and the processor's obligations and rights. It must also require that the processor only processes data according to the controller's documented instructions, implements appropriate technical and organisational security measures, assists the controller in responding to data subject rights requests, deletes or returns all data at the end of the service, and allows audits of its GDPR compliance practices.

For Cloud Server for Email clients: the service agreement includes provisions covering GDPR's Article 28 requirements. Contact data is processed within the EU at our Tallinn, Estonia datacenter without transfer to non-adequate third countries, which satisfies the Article 44–46 international transfer restrictions without requiring Standard Contractual Clauses. Clients who need documentation of these arrangements for their own compliance obligations can request the relevant DPA documentation through the account management process.

The Unsubscribe as GDPR Withdrawal of Consent

GDPR Article 7(3) requires that consent can be withdrawn at any time, as easily as it was given. For email marketing where consent is the lawful basis, an unsubscribe is a withdrawal of consent — it must be processed immediately, and the contact must no longer receive marketing email after the withdrawal. GDPR does not specify a technical timeframe for the cessation of sending, but "immediately" is the practical standard — a contact who unsubscribes should not receive another marketing email from the programme.

The infrastructure requirement: the unsubscribe process must add the contact to the global suppression list before any subsequent campaign injection runs. Batch-processed unsubscribes — where the suppression list is updated daily — create a window during which a contact who has withdrawn consent may receive additional emails. Real-time unsubscribe processing (as described in the bounce processing notes) closes this window and provides the immediate processing that GDPR's consent withdrawal requirement implies.

The suppression list architecture for GDPR compliance: the suppression list must be the source of truth for all sending, checked before each message is injected, across all systems that send marketing email from the same domain. A contact who unsubscribes from a newsletter must also be suppressed from the transactional-grade promotional pool, from re-engagement campaigns, and from any other promotional email stream. Maintaining separate suppression lists per campaign or per system creates the risk of sending to a contact who has withdrawn consent through a channel the sending system checks but another one doesn't.

Cross-Border Data Transfers: The EU Infrastructure Advantage

GDPR Article 44 prohibits transfers of personal data to countries outside the EU/EEA unless specific conditions are met. The standard conditions: the receiving country has been assessed by the European Commission as providing adequate protection (the adequacy decision approach), the transfer uses Standard Contractual Clauses (SCCs) approved by the European Commission, or the controller has binding corporate rules in place.

For email marketing, this means that contact data (which includes email addresses and engagement data about EU residents) may not be transferred to servers in countries without an adequacy decision or SCCs, without specific contractual protections. The United States does not have a blanket adequacy decision from the EU (the Privacy Shield framework was invalidated in 2020 by the Schrems II judgment), though the EU-US Data Privacy Framework adopted in 2023 provides a new adequacy mechanism for US organisations that certify to the framework.

The practical implication for organisations evaluating email infrastructure: EU-based infrastructure (servers in Germany, Netherlands, Estonia) eliminates the cross-border transfer concern entirely. Contact data processed on EU-based servers never leaves the EU, so no adequacy decision or SCCs are required for the infrastructure layer. Organisations with EU-based infrastructure can document their data residency as "processed within EU/EEA" without the additional compliance overhead of maintaining SCC documentation for US-based infrastructure providers.

This is not merely a legal technicality — the cross-border transfer compliance overhead for US-based infrastructure is real. Each SCC implementation requires legal review, and the adequacy of SCC protection was subject to challenge before the EU-US Data Privacy Framework was adopted. Organisations that chose EU-based infrastructure from the outset avoided the compliance uncertainty that those relying on US-based infrastructure experienced during the period between the Schrems II judgment and the adoption of the new framework. For organisations processing significant volumes of EU resident contact data, the compliance simplicity of EU-based infrastructure is a meaningful operational advantage alongside the deliverability benefits of EU datacenter proximity for EU audiences.

The Privacy Policy and the Email Programme

GDPR Article 13 requires that data subjects be informed at the time their data is collected of: the controller's identity and contact details, the DPO's contact details (if applicable), the purposes and lawful basis for processing, any legitimate interests relied upon, recipients or categories of recipients of the data, transfer to third countries if applicable, retention periods, and data subject rights. For email marketing, this information is typically provided through the privacy policy that is linked from the sign-up form and included in the footer of marketing emails.

The email footer privacy policy link is not a GDPR requirement per se — the required information can be provided through other mechanisms. But a clearly accessible privacy policy link in every marketing email is the standard practice that satisfies the transparency requirement while also serving as the reference document for contacts who want to understand their rights or make a data request.

The privacy policy must accurately describe the actual processing activities — not a generic template. If the programme uses tracking pixels (open tracking), click tracking, third-party analytics, retargeting integrations, or data sharing with other services, each of these must be disclosed in the privacy policy. A privacy policy that does not disclose tracking practices that are actually implemented creates compliance risk even if the underlying consent for marketing email is valid, because GDPR's transparency obligation applies to all processing activities, not just the primary marketing email activity.

GDPR and Email Infrastructure Documentation

GDPR Article 30 requires data controllers to maintain a Record of Processing Activities (ROPA) that documents all significant processing activities, including email marketing. The ROPA entry for email marketing should include: the name and contact details of the controller, the purpose of the processing, the categories of data subjects and personal data, recipients of the data (ESPs, analytics providers, etc.), transfers to third countries and the safeguards in place, retention periods, and the technical and organisational security measures applied.

The ROPA is not a public document — it is an internal compliance document required to be available to supervisory authorities on request. For organisations that have never created a ROPA, the email marketing processing activity is typically one of the larger and more clearly defined processing activities to document, which makes it a good starting point for building the complete ROPA. The documentation work for email marketing's ROPA entry typically takes 2–4 hours when the necessary information about the infrastructure and processing activities is readily available.

The infrastructure operator's contribution to the ROPA: documenting where contact data is stored (which systems, in which countries), what security measures are applied (encryption, access controls, audit logging), what retention periods apply to different categories of data, and what sub-processors are used. For managed infrastructure clients, the infrastructure provider should be able to supply the technical portions of this documentation — the EU datacentre locations, the security measures applied, and the sub-processor relationships — as input to the client's ROPA.

GDPR compliance for email marketing is not primarily a technical problem — it is a governance problem that requires the organisation to understand and document its processing activities, apply appropriate controls, and maintain the records that demonstrate compliance. The technical infrastructure supports compliance by enabling the required capabilities (real-time unsubscribe processing, consent record storage, data deletion on request), but the compliance obligation rests with the organisation operating the programme, not the infrastructure provider. The infrastructure makes compliance achievable; the organisation's processes and documentation make it demonstrable.

GDPR compliance is not a one-time achievement — it is an ongoing operational standard. As the programme evolves (new acquisition sources, new integrations, new data fields, new processing purposes), the compliance posture must evolve with it. The quarterly deliverability audit described in the audit note is an appropriate cadence for also reviewing the programme's GDPR compliance status: has anything changed in the past quarter that requires updating the privacy policy, the ROPA, or the DPA with any processor? This combined quarterly review — deliverability and compliance together — ensures that both operational and regulatory standards are maintained as the programme grows and changes.