Last updated
Data processing agreement
When you use Mailbay to receive and send email, we process personal data in that mail on your behalf. This agreement sets the terms GDPR Article 28 requires, and incorporates the EU Standard Contractual Clauses for transfers outside the EEA.
Contents (15)
Scope and parties
This Data Processing Agreement ("DPA") forms part of the Terms of service between the customer that holds a Mailbay workspace ("Customer", the controller, or a processor acting for its own customer) and [Legal entity name], [Registered address], India ("Mailbay", the processor). It applies whenever Mailbay processes personal data on the Customer's behalf, and it takes effect when the Customer accepts the Terms. No signature is needed; [a countersigned copy is available from Contact email for privacy].
Account and billing data about the Customer's own users is processed by Mailbay as controller under the Privacy policy, not under this DPA.
Definitions
"GDPR" means Regulation (EU) 2016/679, and where applicable the UK GDPR and the Swiss FADP. "Personal data", "processing", "controller", "processor", "data subject", "personal data breach" and "supervisory authority" have the meanings in the GDPR. "Customer Data" means personal data in the mail, attachments and related metadata that the Customer's inboxes receive or send through Mailbay. "SCCs" means the standard contractual clauses annexed to Commission Implementing Decision (EU) 2021/914 of 4 June 2021.
Processing on instructions
- Mailbay processes Customer Data only on the Customer's documented instructions, including for transfers, unless the law Mailbay is subject to requires otherwise; in that case Mailbay tells the Customer first unless that law forbids it. The Terms, this DPA, and the Customer's configuration of the service (inboxes, domains, forwarding, webhooks, retention settings, API calls) are the Customer's complete instructions.
- Mailbay tells the Customer if it believes an instruction infringes data protection law.
- Mailbay does not sell Customer Data, does not use it for advertising or profiling, and does not use it to train machine learning models.
- The Customer is responsible for having a lawful basis for the mail it sends and receives, and for the instructions it gives.
Confidentiality
Mailbay ensures that everyone authorised to process Customer Data is bound by confidentiality. Today that is the operator alone; anyone added later will be bound in writing before getting access. [confirm: staff or contractors with access]
Security
Mailbay implements the technical and organisational measures in Annex II (GDPR Article 32), and may change them only in a way that does not lower the overall level of protection.
Subprocessors
- The Customer gives Mailbay general authorisation to engage the subprocessors in Annex III, also published on the subprocessors page.
- Mailbay announces any intended addition or replacement at least [30] days in advance, by email to workspace owners and on the subprocessors page. The Customer may object on reasonable data protection grounds within that period; if the parties cannot resolve the objection, the Customer may terminate the affected service and receive a pro rata refund of prepaid fees.
- Mailbay imposes data protection obligations on each subprocessor that are no less protective than this DPA, and stays liable to the Customer for its subprocessors.
Assistance and data subject rights
Taking into account the nature of the processing, Mailbay helps the Customer respond to data subject requests, mostly through the product itself: messages and inboxes can be read, exported and deleted through the API and dashboard, and the workspace owner can export the whole workspace (GET /v1/workspace/export) and delete it (DELETE /v1/workspace). Mailbay forwards to the Customer any request it receives directly about Customer Data, without answering it itself. Mailbay also gives reasonable help with data protection impact assessments and consultations with supervisory authorities (GDPR Articles 32 to 36).
Personal data breaches
Mailbay notifies the Customer without undue delay, and in any case within [48] hours, after becoming aware of a personal data breach affecting Customer Data. The notice describes, as far as then known, the nature of the breach, the categories and approximate numbers of data subjects and records, the likely consequences, and the measures taken or proposed. Mailbay updates it as it learns more.
Deletion and return
During the term the Customer can export Customer Data at any time and set automatic deletion of mail after 30, 90, 180, 365 or 730 days. When the Customer deletes its workspace, Mailbay deletes all Customer Data in the workspace from the live system at once: messages, raw files and attachments, threads, inboxes, domains and DKIM keys, API keys, app passwords, webhooks and their logs, forwarding rules, invitations and the audit log. After the Terms end Mailbay deletes any remaining Customer Data within [30] days. Copies in backups are overwritten when the backups expire, after [backup retention period, 14 days by default], and are not used in the meantime except to recover from a failure. Mailbay keeps data longer only where the law requires it.
Information and audits
Mailbay makes available the information needed to demonstrate compliance with GDPR Article 28, including this DPA, Annex II and answers to reasonable security questionnaires. Where that is not enough, the Customer (or an independent auditor bound by confidentiality) may audit Mailbay once a year, on [30] days' notice, at the Customer's cost, in a way that does not expose other customers' data. Audits required by a supervisory authority are not limited in this way.
International transfers and SCCs
Customer Data is stored in Canada, which benefits from an EU adequacy decision for commercial organisations subject to PIPEDA (reaffirmed in the Commission's January 2024 review). Mailbay is established in India and administers the service remotely from there; India has no adequacy decision. To the extent Customer Data subject to the GDPR is transferred to Mailbay in India, the SCCs are incorporated into this DPA by reference and apply as follows:
- Modules
- Module 2 (controller to processor) where the Customer is a controller; Module 3 (processor to processor) where the Customer is itself a processor for its own customer.
- Data exporter
- The Customer, with the details in Annex I.
- Data importer
- Mailbay ([Legal entity name]), with the details in Annex I.
- Clause 7 (docking)
- Included. [confirm]
- Clause 9(a) (subprocessors)
- Option 2, general written authorisation. Mailbay informs the Customer of intended changes at least [30] days in advance, as in the Subprocessors section above.
- Clause 11(a) (redress)
- The optional language is not used.
- Clause 13 (supervision)
- Mailbay is not established in the EU and has appointed a representative under GDPR Article 27; the competent supervisory authority is the one of the Member State where the representative is established: [EU representative name and address], [supervisory authority of that Member State].
- Clause 17 (governing law)
- Option 1: the law of [EU Member State, for example Ireland].
- Clause 18 (forum)
- The courts of [the same Member State].
- Annexes
- Annex I.A and I.B: Annex I below. Annex I.C: Clause 13 above. Annex II and III: below.
UK and Switzerland. For transfers subject to the UK GDPR, the UK International Data Transfer Addendum to the SCCs (version B1.0) applies, with Table 1 to 3 filled in from this DPA and Table 4 allowing either party to end it. For transfers subject to the Swiss FADP, the SCCs apply with the FDPIC as supervisory authority and references to the GDPR read as references to the FADP. [confirm whether UK and Swiss customers are served]
If the SCCs conflict with this DPA, the SCCs prevail. Mailbay has carried out a transfer impact assessment for the transfer to India and will share a summary on request.
Liability, term and precedence
Each party's liability under this DPA is subject to the limits in the Terms, except where the SCCs or the law do not allow a limit. This DPA lasts as long as Mailbay processes Customer Data. If this DPA conflicts with the Terms, this DPA prevails for the processing of personal data.
Annex I: parties and processing
A. List of parties
- Data exporter
- The Customer, identified by its workspace and the account email of its owner. Contact: the workspace owner. Activities: use of Mailbay email infrastructure. Role: controller (Module 2) or processor (Module 3). Signature and date: by accepting the Terms.
- Data importer
- [Legal entity name], [Registered address], India. Contact: [Contact email for privacy]. EU representative: [EU representative name and address]. Activities: providing Mailbay. Role: processor. Signature and date: by making the Terms available.
B. Description of the processing
- Data subjects
- People who send email to or receive email from the Customer's inboxes and domains; the Customer's end users and contacts; the Customer's team members whose actions appear in the audit log.
- Categories of data
- Email content (subject, body, headers) and attachments; email addresses and display names; message metadata (Message-ID, timestamps, size, delivery and bounce status); authentication results (SPF, DKIM, DMARC, spam score) and IP addresses of connecting mail servers; IP addresses of API and dashboard requests in the audit log; webhook payloads and forwarding addresses.
- Sensitive data
- Mailbay does not ask for special category data, but email content is whatever the senders write and may contain it. The measures in Annex II apply to all mail alike.
- Frequency
- Continuous, for as long as the Customer uses the service.
- Nature and purpose
- Receiving mail for the Customer's inboxes, storing it, making it available over the API, MCP, IMAP and the dashboard, sending and forwarding mail on the Customer's instructions, delivering webhooks, spam and authentication checks, backups, support and abuse handling.
- Retention
- Until the Customer deletes the data, the automatic deletion period the Customer sets (30, 90, 180, 365 or 730 days), or the workspace is deleted; audit log entries 400 days by default (90, 180, 400 or 730 days); backups as in the Deletion section.
- Transfers to subprocessors
- As in Annex III: hosting in Canada for the whole processing; remote administration from India by the importer.
C. Competent supervisory authority
As set out for Clause 13 above.
Annex II: security measures
Technical and organisational measures, including those to ensure the security of the data. Each one describes how Mailbay works today.
| Measure | What Mailbay does |
|---|---|
| Encryption in transit | The API, dashboard and MCP server are served over HTTPS (TLS terminated by Caddy with ACME certificates). The receiving mail server offers STARTTLS; mail clients connect over IMAP with implicit TLS (port 993) or STARTTLS (143) and submit mail over SMTP with implicit TLS (465) or STARTTLS (587); sign in over SMTP or IMAP requires TLS. Outbound mail uses opportunistic TLS: encrypted whenever the receiving server supports it, without certificate checks, as is usual between mail servers. |
| Encryption of secrets at rest | DKIM private keys and webhook signing secrets are encrypted in the database with ChaCha20-Poly1305 under a 256 bit key held outside the database. Each ciphertext is bound to its row, so a copied value does not decrypt elsewhere. |
| Credentials stored as hashes | API keys, dashboard session tokens, sign in links and codes, and forwarding confirmation tokens are stored only as SHA-256 hashes of high entropy random values. App passwords for mail apps are stored as argon2id hashes. Every secret is shown once, at creation, and never logged. |
| Encryption of mail at rest | Message bodies and attachments are stored on the server's disk and in the database without application level encryption. Disk encryption: [state whether the VPS volume and backups are encrypted]. |
| Access control in the product | Every request is checked against one permission model: workspace roles (owner, admin, member, billing) and project roles (admin, developer, support, viewer), with support access limited to named inboxes. API keys are limited to one project, and can be further limited to one inbox or to sending only. An automated test matrix runs every API route against callers from other projects and workspaces and fails if any of them can read or detect data that is not theirs. |
| Sign in | No passwords for the dashboard: sign in is by a one time link or code sent by email, valid for 15 minutes and usable once, with rate limits per address and per IP. Sessions last 30 days in an httpOnly cookie and can be revoked by signing out. |
| Audit log | Changes to members, roles, projects, domains, inboxes, keys, webhooks, forwarding and app passwords are recorded with who made them, when and from which IP address. The log never stores secrets. Entries are kept for 400 days by default; the workspace owner can choose 90, 180, 400 or 730 days. |
| Retention and deletion | Mail is kept until deleted unless the workspace owner sets automatic deletion after 30, 90, 180, 365 or 730 days; an hourly job then deletes older messages with their raw files and attachments. The owner can export the whole workspace and delete it, which removes its database rows and stored files at once. |
| Backups | A nightly backup of the database, stored mail and configuration is written on the server and kept for [backup retention period, 14 days by default]. Off site copy: [off site backup location, if any]. Deleted data disappears from backups when the backups that hold it expire. |
| Abuse and spam protection | Received mail is checked for SPF, DKIM and DMARC and scored by a spam filter running on our own server. The receiving server rate limits each sending IP address. Sending is limited per plan and per workspace, and addresses that bounce or complain are suppressed. |
| Isolation of customers | All customers share one database; every row carries its workspace and project, and every query is scoped by them (see the access control test matrix above). Stored files are kept under a per workspace path. |
| Operator access | The server is administered by the operator alone, remotely from India, over SSH with key authentication [confirm: password login disabled, firewall limited to mail and web ports]. The operator does not read customer mail except where needed to keep the service running, investigate abuse, or when the customer asks. |
| No third party analytics | Neither the website nor the dashboard loads third party analytics, advertising or tracking scripts. Logs are kept on our own server for operations and security [log retention period]. |
| Incidents | We notify affected customers without undue delay, and within 48 hours of becoming aware of a personal data breach that affects their data, with what we know and what we are doing. [confirm the 48 hour commitment] |
Annex III: subprocessors
The Customer authorises the following. Changes are announced as described in the Subprocessors section; the current list is always on the subprocessors page.
| Subprocessor | Purpose | Location | Transfer basis |
|---|---|---|---|
| OVHcloudOVH Hosting Inc. (OVHcloud Canada) [confirm the contracting OVH entity on the invoice] | Virtual private server that runs every Mailbay service: the API, the mail servers (receiving, sending, IMAP), the database, stored messages and attachments, and backups on the same server. | Beauharnois, Quebec, Canada | Canada: EU adequacy decision (commercial organisations under PIPEDA) |
| [Legal entity name]the operator itself | Remote administration of the server: deployments, maintenance, support and abuse handling. Not a separate company, listed because access from India is a transfer. | India (remote access to the server in Canada) | Standard Contractual Clauses (EU 2021/914) and a transfer impact assessment. no adequacy decision |
- Mailbay does not use third party email delivery services: mail is sent and received by Mailbay's own mail servers on the server above.