GDPR in Lumail

Last reviewed: 2026-08-23

Current limitation: Lumail is an early-stage service and does not currently offer a GDPR Article 28 DPA, customer SCCs, or an EU-only processing commitment. If your organization requires those terms, do not process EEA, UK, or Swiss personal data in Lumail until the required agreement is available and signed.

This page describes the product and infrastructure as they operate today. It is intended to help customers perform their own assessment; it is not legal advice and is not a certification that a particular use of Lumail complies with GDPR or French ePrivacy rules.

Roles and responsibility

For subscriber lists, campaigns, and transactional recipients, the Lumail customer normally determines the purpose and means of processing and is the data controller. Codelynx, LLC operates Lumail and processes that data to provide the Service.

Codelynx is a separate controller for account, billing, security, support, and its own website analytics data. Customers remain responsible for their notices, legal bases, consent records, email content, recipient selection, and responses to data-subject requests.

Current data map

Opens, clicks, bounces, complaints, and unsubscribe events are stored in the same Frankfurt PostgreSQL region as subscriber records. This does not mean all related data stays there: SES, Inngest, R2, Cloudflare, and operational alerts can process related data elsewhere.

See the Privacy Policy for the complete public disclosure.

International transfers

Codelynx does not currently claim certification under the EU-U.S. Data Privacy Framework. The current Lumail customer terms do not contain the European Commission's Standard Contractual Clauses and Lumail does not currently offer another customer transfer addendum.

Some infrastructure providers publish their own DPAs, SCCs, Data Privacy Framework participation, or other safeguards. Those upstream arrangements may protect Codelynx's use of a provider, but they do not replace the Article 28 agreement and transfer analysis required between a customer and Codelynx.

See DPA and GDPR Contract Status for the current contractual status.

GDPR setup checklist

Before collecting subscribers, an EU customer should:

1. Wait for the required contract. If you require an Article 28 DPA, SCCs, an EU-only commitment, or a transfer impact assessment, do not start production processing yet.
2. Publish your own privacy notice. Identify your purposes, legal bases, recipients, transfers, retention periods, and how subscribers can exercise their rights.
3. Enable native double opt-in. In Settings → Configuration → Double Opt-In, enable the setting before collecting subscribers when confirmation is appropriate for your legal basis and market. Step-by-step: Enable Double Opt-In.
4. Minimize data. Send only fields needed for the stated purpose. Do not place special-category or children's data in Lumail without a separate assessment and written agreement.
5. Choose tracking deliberately. Open pixels and tracked links can require notice or consent. The transactional API defaults both options to enabled; explicitly set tracking.open and tracking.links to false when tracking is not necessary or lawful.
6. Keep independent consent evidence. Store the notice version, source, timestamp, purpose, and consent wording in your own system. Native Lumail confirmation stores confirmedAt and confirmationIp, but those fields are not a complete consent record by themselves.
7. Test rights handling. Verify export, unsubscribe, suppression, and deletion procedures before launch. Contact [email protected] for downstream deletion questions.

Native and custom double opt-in

Lumail's recommended flow is the native double opt-in. See Enable Double Opt-In for the Configuration screenshots and the confirmation email editor.

1. Enable Double Opt-In in organization configuration.
2. Add the subscriber through the Subscribers API or a Lumail capture flow.
3. Lumail creates the subscriber as PENDING_CONFIRMATION and sends the native confirmation email.
4. The Lumail confirmation link changes the status to SUBSCRIBED and records the confirmation time and IP address.

The transactional email API behaves differently:

• It always creates a subscriber row when the address does not already exist.
• By default that row is TRANSACTIONAL: delivery, bounce, and complaint tracking without marketing eligibility.
• If Settings → Configuration → Add transactional recipients to the marketing list is on, the new row is SUBSCRIBED and a subscribed event is recorded. Double opt-in is ignored on this path.
• Existing contacts are reused and never have their status changed. TRANSACTIONAL becomes SUBSCRIBED only on a real subscribe (capture, import, admin, or API upsert with resubscribe).
• Adding a custom tag does not change PENDING_CONFIRMATION or TRANSACTIONAL to SUBSCRIBED, populate confirmedAt, or prove consent in Lumail.

Therefore, do not use the transactional API plus a confirmation tag as Lumail's custom double-opt-in mechanism. Use the native flow, or keep the entire consent and marketing-eligibility state in your own system and do not treat Lumail's SUBSCRIBED status as proof of consent. For confirmation emails, explicitly disable tracking unless you have determined that it is lawful:

{
  "transactional": true,
  "tracking": {
    "open": false,
    "links": false
  }
}

Retention, deletion, and suppression

Lumail does not currently provide a contractually guaranteed retention period for every data category.

Deleting a subscriber removes the subscriber and related relational records from the primary application database. It does not currently guarantee deletion of every sent-email archive object, provider log, backup, or legally required suppression record. Suppression data may be retained to avoid sending again to an address that unsubscribed, bounced, or complained.

If a data-subject request requires downstream archive or provider action, contact [email protected] before promising a completion date.

Security and incident handling

Lumail uses TLS, access controls, separated environments, provider security controls, and abuse monitoring. These measures reduce risk but do not create an absolute security guarantee. Customers should limit API-token permissions, rotate credentials, use separate development and production tokens, and report suspected incidents to [email protected].

Planned compliance work

Lumail plans to prepare an Article 28 DPA, SCC modules and transfer documentation, a maintained subprocessor notice process, clearer retention schedules, and stronger downstream deletion controls. These items are plans, not current contractual commitments, and no availability date is promised.