If you're building a product that sends transactional emails to users in the European Union, GDPR applies to you. Not just to your marketing emails. Every password reset, order confirmation, and account notification you send involves personal data and falls under the regulation.
Most developers know GDPR exists. Far fewer know what it actually requires in the context of transactional email, and where the real risks are. This guide covers the practical decisions you need to make: what data you're allowed to process, what your obligations are to your users, how to choose an email provider that doesn't create compliance problems for you, and what to do when something goes wrong.
Why transactional email is a GDPR concern
GDPR regulates the processing of personal data belonging to EU residents. An email address is personal data. So is a name, a device identifier, an IP address, or anything else that can be linked back to an individual.
When you send a transactional email, you're processing personal data in several ways at once: you're storing the recipient's address, transmitting it to an email provider, logging delivery events, and potentially retaining open and click tracking data. Each of these is a processing activity that needs a legal basis under GDPR.
The good news is that transactional email has a clear legal basis: legitimate interest or contract performance. If a user signed up for your product and you're sending them a password reset they requested, you don't need separate consent. You're fulfilling a contract. The same applies to order confirmations, security alerts, and account notifications.
What doesn't have that clear legal basis: marketing emails, re-engagement campaigns, or anything the user didn't directly trigger. Those require explicit consent and belong in a separate system entirely.
Data minimization: only process what you need
GDPR's data minimization principle requires that you only collect and process personal data that is necessary for the stated purpose. For transactional email, that means questioning every field you send to your email provider.
Do you need to send the user's full name, phone number, or company in the email payload? If the only purpose is sending a delivery confirmation, probably not. Send the minimum: recipient address, the content of the email, and whatever metadata is necessary for delivery and troubleshooting.
This applies to logging too. Many email providers log delivery events with rich metadata by default. Review what your provider retains and for how long. You are the data controller: you're responsible for that data even when a third party processes it on your behalf.
AhaSend gives you direct control over retention at the message level via special headers. ahasend-metadata-retention sets how long metadata and delivery logs are kept (1-30 days). ahasend-data-retention controls retention of the message content itself, and can be set to 0 for immediate deletion after processing. This means you can apply different retention periods per email type: a password reset doesn't need to be stored as long as an invoice. See the retention headers documentation for details.
You are the controller. Your email provider is the processor.
This distinction matters. Under GDPR, the data controller decides the purpose and means of processing. The data processor processes data on the controller's behalf. As the developer or company sending transactional emails, you are the controller. Your email provider is the processor.
This means:
- You are responsible for ensuring the processing is lawful.
- Your email provider must process data only according to your instructions.
- You must have a Data Processing Agreement (DPA) in place with your email provider.
A DPA is not optional. It's a legal requirement under Article 28 of GDPR. Any GDPR-compliant email provider will offer a DPA. If yours doesn't, that's a red flag.
AhaSend's DPA is available at ahasend.com/dpa. It covers the standard requirements: purpose limitation, confidentiality obligations, sub-processor disclosures, data subject rights support, and breach notification procedures.
Where your data lives matters
GDPR restricts the transfer of personal data outside the European Economic Area (EEA) unless adequate protections are in place. In practice, this means that if your email provider routes data through servers in the United States or other non-EEA countries, you need to verify that the transfer mechanism is legally valid.
The safe harbor framework is gone. Privacy Shield is gone. Transfers to the US currently rely on the EU-US Data Privacy Framework, which has faced legal challenges and could be invalidated again. If your email infrastructure is US-based, this is a compliance risk you're carrying.
AhaSend is incorporated in The Netherlands (AhaSend B.V., KvK 99533111) and processes email on European infrastructure by default. We do offer a US egress node for customers who need it for performance or deliverability reasons, but data sent through that node is in transit only and never stored on US infrastructure. Your data stays in Europe.
This matters not just for legal compliance but for your customers. As we explored in Why Your Email Provider's Location Matters, European businesses increasingly face scrutiny over which infrastructure providers they use, and "our email provider is in California" is not the answer procurement teams want to hear.
Suppression lists and the right to erasure
GDPR gives users the right to erasure (Article 17), commonly called the "right to be forgotten." In the context of transactional email, this creates a practical tension: if a user asks you to delete their data, you also need to stop sending them emails. But to stop sending them emails, you need to remember not to email them. Which means you need to retain some record of their address.
The standard solution is a suppression list: a minimal record that an address should not receive email, without storing any other personal data associated with that user. This is distinct from a full account record and is considered compliant because it serves the specific purpose of honoring the erasure request.
AhaSend supports suppression list management with full API access. You can import suppressions, query them, and sync them with your own systems. When you receive a deletion request, you add the address to your suppression list: that's the correct approach, not deleting the record from your email provider entirely (which could cause the address to start receiving email again).
You can read the full walkthrough in our suppression list import guide.
Breach notification: the 72-hour rule
Under GDPR Article 33, if there's a personal data breach, you must notify your supervisory authority within 72 hours of becoming aware of it. A data breach in the context of email could mean unauthorized access to your sending logs, a misconfigured webhook exposing delivery data, or a provider-side incident that exposes email addresses.
The 72-hour window starts when you become aware, not when the breach occurred. This makes incident response planning important: you need to know who makes the call to notify, who drafts the notification, and which supervisory authority is relevant for your users.
For Netherlands-based businesses, the supervisory authority is the Autoriteit Persoonsgegevens (AP). Their breach notification portal is at autoriteitpersoonsgegevens.nl/themas/beveiliging/meldplicht-datalekken.
Article 34 adds a further requirement: if the breach is likely to result in a high risk to individuals, for example if email content contained sensitive information - you may also need to notify the affected users directly.
Choosing a GDPR-compliant email provider
Not all email providers are equal from a compliance standpoint. When evaluating providers, the questions to ask are:
Where is data processed and stored? European infrastructure removes transfer risk entirely. A provider that stores your data in the US creates ongoing exposure regardless of what their privacy policy says.
Do they offer a DPA? If they don't, you can't use them legally for EU personal data processing.
What data do they retain, and for how long? Some providers retain email content and metadata indefinitely by default. That's your data, and your liability.
Are they transparent about sub-processors? Your email provider likely uses third-party infrastructure. Under GDPR, you need to know about material sub-processors because their data handling is your responsibility too.
Do they support suppression list management? Handling erasure requests correctly requires this.
AhaSend was built for developers who need to answer yes to all of the above. European infrastructure, a proper DPA, configurable data retention, sub-processor transparency, and full suppression list API. We also have an appointed Data Protection Officer (DPO). Having a dedicated DPO means there's a named, accountable person responsible for data protection decisions, not just a policy document.
As we covered in the AhaSend vs SendGrid vs Resend vs Mailgun comparison, the major US-based providers have different default assumptions about data handling, assumptions built for the US market, not for GDPR compliance.
A note on tracking pixels and click tracking
Open tracking (the invisible 1x1 pixel) and click tracking (rewriting links through a tracking domain) both involve processing personal data. An open event is tied to a device and IP address. A click event records what the user clicked and when.
For transactional email, whether tracking requires consent is a nuanced question. The Article 29 guidance suggests that tracking strictly necessary for delivery and technical performance may not require consent, while tracking used for profiling or analytics purposes does.
In practice: if you're tracking opens to understand deliverability, that's arguably legitimate interest. If you're tracking opens to trigger behavioral marketing workflows, that's a different story and likely requires consent.
The safe approach is to be explicit with users about what you track, give them a way to opt out, and use tracking data only for the purpose you've disclosed.
Practical checklist
Before you go live with transactional email to EU users, run through this:
- Legal basis documented for each type of transactional email you send
- DPA signed with your email provider
- Data minimization reviewed: only necessary fields sent to provider
- Retention policy configured on your provider account
- Suppression list workflow in place for handling erasure requests
- Incident response procedure documented with 72-hour notification in mind
- Tracking practices reviewed against what you've disclosed to users
- Email infrastructure location confirmed as EEA (or valid transfer mechanism documented)
GDPR compliance isn't a one-time checkbox. It's an ongoing discipline. But for transactional email specifically, the rules are relatively clear, and building it right from the start is far less painful than retrofitting compliance after a user complaint or a regulatory inquiry.
If you're evaluating whether a failed or delayed transactional email creates additional liability beyond the compliance angle, that's worth reading about separately. What does a failed email actually cost you? covers the business impact in detail.
AhaSend is a transactional email provider incorporated in Amsterdam, Netherlands. For questions about our data processing practices or to request our DPA, contact [email protected].