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 Arin Prajapati, trading as Mailbay (sole proprietor), Mumbai, Maharashtra, 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 signed copy is available on request from privacy@mailbay.dev.
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 founder alone: no staff or contractors have access. Anyone added later will be bound in writing before getting 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 deleted when the backups expire, after 14 days (up to 21 days for the database's point in time archive, which is built on weekly full backups), 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
Mailbay's primary Customer Data storage is in Canada, which benefits from an EU adequacy decision for commercial organisations subject to PIPEDA (reaffirmed in the Commission's January 2024 review). Outbound Customer Data is also processed by Amazon Web Services in Northern Virginia, United States (us-east-1) for SES delivery and delivery events, under the SCCs in the AWS data processing addendum. Mailbay is established in India and administers the Canadian 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 (Arin Prajapati, trading as Mailbay (sole proprietor)), with the details in Annex I.
- Clause 7 (docking)
- Included.
- 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)
- Where the Customer is established in an EU Member State, the supervisory authority of that Member State. Otherwise, Ireland's Data Protection Commission. Mailbay has not appointed a representative in the EU under GDPR Article 27.
- Clause 17 (governing law)
- Option 1: the law of Ireland.
- Clause 18 (forum)
- The courts of Ireland.
- 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.
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
- Arin Prajapati, trading as Mailbay (sole proprietor), Mumbai, Maharashtra, India. Contact: privacy@mailbay.dev. EU representative: none appointed yet. 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: primary storage and the Mailbay control plane in Canada; outbound message delivery and delivery-event processing by Amazon Web Services in us-east-1; the dashboard front end on Vercel, through which dashboard pages pass in transit; 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. Mailbay submits outbound mail to Amazon SES over its TLS API; SES manages the final SMTP delivery hop. |
| 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. A domain's DKIM private key is provided to Amazon SES when Mailbay registers that BYODKIM identity so SES can sign outbound mail. |
| 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, and the server's disk is not encrypted at rest by the hosting provider. Off site backups are encrypted on the server before they are uploaded (see Backups). |
| 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, or by GitHub or Google with a verified email address. Any user can add two-factor authentication with an authenticator app (TOTP): the secret is stored encrypted, a code cannot be used twice, a sign in with a second factor opens no session until the code is entered, and 10 single use recovery codes are stored only as hashes. Sessions last 30 days in an httpOnly cookie and can be revoked by signing out, or on every device at once. |
| Audit log | Changes to members, roles, projects, domains, inboxes, keys, webhooks, forwarding and app passwords, and sign ins, sign outs, failed sign ins for existing accounts (at most one entry per account every 10 minutes) and two-factor changes, 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, and owners and admins can export the log as CSV or JSON (each export is itself logged). |
| 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. Every user can export their own account data and delete their account (a user who owns a workspace must delete or transfer it first); their sessions, app passwords and linked sign in accounts are removed and their name is replaced by "Deleted user" in the audit log. |
| Backups | Every night the database, stored mail and the server configuration are backed up on the server, and the database is also archived continuously for point in time recovery. Backups are kept for 14 days; the point in time archive is built on weekly full backups, so it can hold data for up to 21 days. When an off site store is configured, the database backups (pgBackRest, AES-256) and the stored mail and configuration (restic, AES-256) are also copied, encrypted on the server before upload, to an S3 compatible object store with the same retention; its provider is listed as a subprocessor before it is used. 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, and the API limits each client IP before it checks any credential (30 failed authentications and 300 requests without credentials per minute). Sending is limited per plan and per workspace, addresses that bounce or complain are suppressed, and a workspace whose bounce or complaint rate gets too high stops sending automatically (see the terms). |
| 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 | Only the founder has operational access to the server, and administers it remotely from India over SSH with key authentication. The install script turns on a firewall that refuses every incoming connection except SSH (port 22), mail (25, 465, 587, 143 and 993) and web traffic (80 and 443). The founder does not read customer mail except where needed to keep the service running, investigate abuse, or when the customer asks. |
| Public website analytics; logs | The public website uses Vercel Web Analytics when hosted on Vercel and self-hosted Umami when configured. The dashboard and API have no visitor analytics. Mailbay's server and mail logs are kept on our server for operations and security, and deleted after 30 days. Amazon SES delivery events are processed through SNS and encrypted SQS in us-east-1. |
| 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. |
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 |
|---|---|---|---|
| OVHcloud | Virtual private server for Mailbay's API and control plane, inbound SMTP, SMTP submission, IMAP, database, stored messages and attachments, and the backups kept on the server. Production outbound delivery is handled by Amazon SES. | Beauharnois, Quebec, Canada | Canada: EU adequacy decision (commercial organisations under PIPEDA) |
| VercelVercel Inc. | Hosting of the website and the dashboard front end. Dashboard pages pass through Vercel on their way between your browser and the Mailbay API, so request data and the content shown on those pages are processed transiently. The API and the mail servers do not run on Vercel. | United States (functions in Washington, D.C.) and edge locations worldwide | Standard Contractual Clauses in Vercel's data processing addendum |
| Amazon Web ServicesAmazon Web Services, Inc. | Amazon Simple Email Service (SES) processes outbound messages for the final delivery hop, including managed retries and DKIM signing. SNS and SQS carry delivery, bounce and complaint events back to Mailbay. | Northern Virginia, United States (us-east-1) | Standard Contractual Clauses in the AWS data processing addendum |
| HetznerHetzner Online GmbH | Server for our own, self hosted website analytics (Umami). It counts visits to the public website and docs without cookies. Visitor data only: no customer mail, and nothing from the dashboard or the API. | Helsinki, Finland | None: inside the EU |
| MailbayArin Prajapati, trading as Mailbay (sole proprietor), 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 |