GDPR-Minded Transactional Email: Consent, Data Minimisation, Retention

Developers often assume GDPR means asking for consent before every email. It does not: a receipt, a password reset or a security alert is part of delivering the service and needs no opt-in. What GDPR does ask is that you send only what the service requires, put no more personal data in the message than needed, keep logs for a defined period, and be able to answer "what did you send this person and why". This guide turns those principles into engineering rules.

Quick answer

Transactional messages (receipts, confirmations, codes, security and service notices) rest on contract performance or legitimate interest and need no consent. Anything promotional, including upsells inside a receipt, is marketing and needs consent or a valid soft opt-in with an unsubscribe. Keep personal data in emails and logs to the minimum, define retention periods for sent-message content and delivery logs, and document all of it in your privacy notice.

Which emails need no consent

• Order confirmations, invoices, receipts, shipping updates: necessary to perform the contract.
• Account emails: verification, password reset, magic links, new-device alerts, changes to email or password: security and contract.
• Service notices: planned maintenance, terms changes, price changes, data breach notifications: legal obligation or legitimate interest.
• Appointment reminders for a booked appointment: contract.
• Not in this list: newsletters, product announcements, "you might also like", re-engagement, and abandoned cart emails. Those are marketing (see the ePrivacy rules and your national implementation) and need a lawful basis for marketing.

The line inside a single email

Regulators look at the purpose of the message, and a receipt with a discount banner has two purposes. Keep transactional emails purely transactional: the facts of the transaction, how to get help, and legally required footer information. If you want to cross-sell, send a separate marketing email to people who have consented, with an unsubscribe link. This also keeps your transactional mail out of the promotions tab and out of the scope of unsubscribe requests, which you must honour for marketing but should not apply to a security alert.

Data minimisation in the message

1. Include only what the recipient needs to act. A shipping notice needs the tracking number and the address; it does not need the customer's date of birth or full card number.
2. Prefer links to authenticated pages over embedding sensitive data. An invoice email states the total and links to the PDF behind login; it does not attach the full document to a message that may be forwarded.
3. Never put passwords, full card numbers, national ID numbers or health details in an email.
4. Mask what you can: "Visa ending 4242", "the account for j***@example.com".
5. Use the text and html fields for the same content; do not hide extra personal data in one part.

The send request, minimal by design

curl -X POST https://api.oqumail.com/api/v1/emails \
  -H "Authorization: Bearer $OQUMAIL_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{"from":"orders@yourdomain.com","to":"jane@example.com","subject":"Order #10482 confirmed","html":"<p>Your order #10482 is confirmed. Total: EUR 89.00.</p><p><a href=\"https://app.yourdomain.com/orders/10482\">View order details</a> (sign-in required)</p><p>Acme GmbH, Musterstrasse 1, 10115 Berlin. <a href=\"https://yourdomain.com/privacy\">Privacy notice</a></p>","text":"Your order #10482 is confirmed. Total: EUR 89.00. Details (sign-in required): https://app.yourdomain.com/orders/10482"}'

Logs and retention

Your sending records are personal data too: recipient addresses, subjects, timestamps, message bodies if you store them. Decide and document how long you keep each. A common pattern is: full rendered bodies for 30 days (enough for support), send metadata (recipient, subject, status, message id) for 12 months, financial records such as invoices for whatever your tax law requires (often 6 to 10 years), and application logs that mention addresses for 90 days. Delete on schedule with a job, not by hand. When a user exercises their right to erasure, delete or anonymise their address in your email_sends table and stop future sends; keep invoice records if the law requires them and say so in your privacy notice. Delivery logs on the sending platform are part of this picture; know what your provider keeps and for how long, and cover it in your records of processing.

Processor, contract, transfers

• Your email platform is a processor: you need a data processing agreement with it, and it should appear in your list of sub-processors.
• Know where the platform stores and processes mail, and cover any transfer outside the EEA with the appropriate mechanism in the agreement.
• Keep the platform's API key in a secrets store with access limited to the people who need it; access control is part of the security obligation.
• Be able to export what you sent to a person on request: a query on your email_sends table by address should answer a subject access request.
• Record the lawful basis per email type in your records of processing: contract for receipts, legitimate interest for security alerts, consent for marketing.

Where OquMail fits

OquMail sends transactional messages from your own verified domain through an API with Bearer keys, keeps a delivery log per message so you can show exactly what was sent to whom and when, and hosts the mailboxes that receive replies on the same domain. Keep your own email_sends table alongside it for the retention and erasure logic that is specific to your product, and note the platform as a processor in your privacy documentation.

Common questions

Do transactional emails need an unsubscribe link?

No, and adding one creates a problem: a user who clicks it expects not to receive security alerts, which you must still send. Provide a way to reach you instead, and keep marketing on a separate list with its own unsubscribe.

Can I email a user after they delete their account?

One final confirmation of the deletion is reasonable as part of completing their request. After that, no, except for legal obligations such as a tax invoice already issued.

Is the UK the same?

The UK GDPR and PECR follow the same structure: no consent for service messages, consent or soft opt-in for marketing, and the same minimisation and retention principles. The details of soft opt-in differ slightly; check the ICO guidance.