_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 | Data or operation | Primary system | Current location | | ------------------------------------------------------------------------- | ---------------- | ------------------------------------------------------------- | | Subscriber profiles, subscription state, campaigns, and core email events | Neon PostgreSQL | AWS eu-central-1, Frankfurt, Germany | | Application and Redis runtime | netcup | Nuremberg, Germany | | Email delivery and bounce or complaint feedback | Amazon SES | ap-southeast-2, Sydney, Australia | | Sent-email content archives | Cloudflare R2 | APAC placement; no EU-only jurisdiction guarantee | | Transactional content and background-job data | Inngest | United States | | Queued message orchestration | Upstash QStash | EU service endpoint | | Product analytics and application diagnostics | PostHog Cloud EU | Frankfurt, Germany | | DNS, CDN, and security traffic | Cloudflare | Global edge network | | Limited operational delivery-failure alerts | Telegram | Global service; alerts may include a subscriber email address | 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](/legal/privacy) 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](/docs/legal/dpa) 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. 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 [help@codelynx.dev](mailto:help@codelynx.dev) for downstream deletion questions. ## Native and custom double opt-in Lumail's recommended flow is the native double opt-in: 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 creates the recipient as a subscriber when the address does not already exist. - With organization double opt-in disabled, that new record is immediately `SUBSCRIBED`. - With double opt-in enabled, it is created as `PENDING_CONFIRMATION`, but the transactional endpoint does not expose a supported public confirmation-token or confirmation-state transition for a custom confirmation email. - Adding a custom tag does not change `PENDING_CONFIRMATION` 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: ```json { "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 [help@codelynx.dev](mailto:help@codelynx.dev) 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 [help@codelynx.dev](mailto:help@codelynx.dev). ## 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.