Last updated
Security
What Runearc does to protect your mail, keys and accounts today, and what it does not do yet. Runearc is built and run by one person, so this page says what is true and nothing more.
Contents (6)
In short
- Credentials are never stored in a usable form: API keys, sessions and sign in codes are stored as hashes, and every secret is shown once.
- DKIM private keys and webhook signing secrets are encrypted in the database. Mail itself is not encrypted at rest at the application level (see below).
- Every request goes through one permission model, and an automated test runs every API route as callers from other workspaces to prove they cannot see your data.
- Changes to members, keys, domains, inboxes and webhooks, and sign ins, are written to an audit log you can read and export.
- Two-factor authentication with an authenticator app is available to every user.
- 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.
- Runearc holds no SOC 2, ISO 27001 or HIPAA attestation today. See compliance status.
What we do today
This table is the security annex of our data processing agreement, so it is a commitment, not marketing. Each row describes something that exists in the code today.
| Area | What Runearc 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. |
What we do not have yet
Buyers ask about these, so here they are before you ask. Each is either planned or a decision we have not made yet. We will move an item off this list only when it is shipped.
- Single sign on, SAML and passkeys. Two-factor authentication uses an authenticator app (TOTP) and recovery codes. There is no SSO, SAML or passkey sign in, and a workspace cannot require two-factor for all its members yet.
- Encryption of stored mail at rest. Message bodies and attachments sit on the server's disk and in the database without application level encryption, and the disk is not encrypted by the host. Off site backups are encrypted before upload.
- Required TLS for incoming mail. Our receiving server offers STARTTLS but accepts mail from servers that do not use it, as every public mail server must. We do not publish an MTA-STS policy yet.
- An EU data region. Customer data is stored in Quebec, Canada, with the subprocessors listed on the subprocessors page.
- A penetration test report and a bug bounty.
- A service level agreement.
Compliance status
| Standard | Status |
|---|---|
| GDPR | We act as a processor and offer a data processing agreement with the Standard Contractual Clauses. See GDPR. |
| SOC 2 | Not certified, and no audit has started. We will publish the report status here only when it exists. |
| ISO 27001 | Not certified. |
| HIPAA | Not supported. We do not sign business associate agreements, so do not send protected health information. |
Live checks of the API, database, mail receiving and sending hand-off are on the status page.
If your security review needs more than this page, write to security@mailbay.dev. We answer security questionnaires in writing, and we will tell you plainly when the honest answer is "not yet".
Report a vulnerability
Found a weakness? Write to security@mailbay.dev. Our disclosure policy explains what is in scope, what we promise and the safe harbour for good faith research. A machine readable version is at /.well-known/security.txt.
Questions
Where is my data? Quebec, Canada, on a virtual server at OVHcloud, with the other subprocessors listed on the subprocessors page.
Who can read my mail? Only the founder has operational access to the server. Mail is read only to keep the service running, to investigate abuse, or when you ask.
What happens if there is a breach? We tell affected customers without undue delay and within 48 hours of becoming aware, with what we know and what we are doing.
Can you sign our security addendum or DPA? Our DPA applies automatically, and a signed copy is available on request from privacy@mailbay.dev. For anything else, write to legal@mailbay.dev.