GDPR-compliant transactional email: a developer's guide

Most GDPR advice about email is written for marketing teams: consent checkboxes, unsubscribe links, double opt-in. Transactional email (password resets, receipts, magic links, security alerts) works under different rules, and the compliance work sits mostly with the developer who wires up the sending path. This guide walks through the eight decisions that matter, in the order you hit them, and links to a deeper post for each.

This is general information for engineers, not legal advice. Your data protection officer or counsel has the final word on your specific processing.

1. Lawful basis: you usually don't need consent

A password reset or an order confirmation is necessary to perform the contract you have with the user, which is a lawful basis under Article 6(1)(b) GDPR. Security alerts and service notices often sit under legitimate interests, Article 6(1)(f). Neither needs a consent checkbox.

The line moves the moment you add promotional content. A receipt with a "you might also like" block is no longer purely transactional, and the marketing rules under the ePrivacy framework start to apply. Keep transactional templates free of promotion, or send marketing as a separate message with its own consent.

2. Data minimisation: what goes in the message

Article 5(1)(c) says process only what you need. For email that means the subject line and body are the biggest risk: they're stored by every mail server and provider the message passes through, and shown on lock screens. Put the minimum in the email and link to the authenticated app for the rest.

• No health, financial or other special-category detail in subject lines.
• Link to an invoice in your app rather than attaching one, where you can.
• Don't log full message bodies in your own application logs.

3. Your provider is a processor: get the DPA

Your email API provider processes recipient addresses and message content on your behalf, which makes it a processor under Article 28. Article 28 requires a written contract (the data processing agreement) covering what the provider may do with the data, its security measures, subprocessors, and deletion at the end of the contract. Without a signed DPA, you're out of compliance before the first send.

Envello includes a signed DPA on every plan, including Free, with no sales call. Before you sign any provider's data processing agreement, check the subprocessor, deletion and breach-notification clauses.

4. Transfers: where the data actually goes

Chapter V of the GDPR (Articles 44 to 49) restricts transfers of personal data outside the EEA. An email provider that sends from an EU region but stores logs, account data or support tickets elsewhere is still transferring data, and needs a mechanism such as Standard Contractual Clauses (Article 46).

Ask your provider where four things live: the API, the database, the delivery logs and the backups. Envello runs all four in the EU, with sending through AWS SES in Frankfurt. That's what EU data residency means in practice: every copy of the data, not just the sending endpoint.

It also has to survive the question of whether the US CLOUD Act reaches a provider's parent company.

5. Retention and erasure: delete on a schedule

Storage limitation, Article 5(1)(e), means delivery logs shouldn't live forever. Pick a retention window you can justify (long enough to debug delivery problems and answer "I never got the email", short enough to defend) and make sure the provider actually deletes when it expires.

Envello's log retention job hard-deletes event and log data past your window: 7 days on Free, 90 on Pro, configurable from 7 to 365 on Scale.

That schedule is also how the right to erasure under Article 17 is met in practice for delivery logs.

6. Open and click tracking: off unless you need it

Tracking pixels and rewritten links collect extra personal data: when someone opened a message, from roughly where, and what they clicked. For a password reset, that data rarely serves a purpose you could defend. Turn tracking on only for messages where you'll actually use it, and document why.

On Envello, open and click tracking are off by default and enabled per sending domain.

7. Security: what Article 32 means for a sending path

Article 32 asks for security appropriate to the risk. For transactional email the practical list is short:

• API keys in a secret store, scoped per environment, rotated when someone leaves.
• TLS for every hop you control, and SPF, DKIM and DMARC on the sending domain so your mail can't be spoofed.
• Webhook signature verification before you act on any webhook.
• An audit trail of who created keys and changed domains.

8. Breaches and records

If personal data leaks, Article 33 gives you 72 hours to notify your supervisory authority once you're aware of it. Your DPA should oblige the provider to tell you without undue delay, so check that clause. Separately, Article 30 requires a record of processing activities; add the email provider and what it processes, and keep its subprocessor list on file.

A checklist to copy into your ticket