Skip to main content
Brand My Inbox
Get started

Email security

Your organisation's email: what is stored, who can reach it, and who holds the keys

Mail we forward to your existing inbox passes through and is not stored. Mail you receive or send in our inbox is stored encrypted, with a separate key per message, for a period you choose. An organisation that needs full control installs the mail layer on its own servers, and then the keys, the logs and the backups stay with it too.

Talk to the people who build itWhat is stored, and where

Written from what the code does, including what it does not do yet.

What do we store, for how long, and how is it protected?

Four kinds of data pass through the mail layer. Each has its own rule, and the inbox retention is yours to set.

DataStoredProtectionKept for
Mail forwarded to your inboxNoPasses through onlyNot kept
Mail in our inboxYes, if you open a receiving addressAES-256-GCM, a key per message7 to 365 days, your choice within your plan
Mail sent from the appYes, in SentThe same encryption30 days
SMTP passwordsHash onlyscrypt, constant-time comparisonUntil you rotate them

The keys are held by our servers, so this is not end-to-end encryption. In an on-premise installation the keys are secrets on your servers.

How does your organisation run its own email security?

Two-factor, enforced by you

Owners and admins can require a second factor for the whole workspace. Passkeys and authenticator apps both work.

Support that cannot read mail

Read-only settings view, a written reason, one hour, logged. Message content is never part of it.

A log nobody can edit

Changes to the mail server's configuration go into a log that a database trigger makes append-only.

Who may send as you

SPF, DKIM and DMARC in your DNS, DMARC reports received and parsed, and the verdict shown on every incoming message.

Encrypted at rest, per message

Every stored message has its own AES-256-GCM key. Retention is a setting, and deletion follows it.

Keys you hold, when you need to

In an on-premise installation the encryption keys, the database and the logs live in your network.

Why control matters more than a checklist

Email security in an organisation starts with a plain question: who may send in your domain's name. SPF, DKIM and DMARC records live in your DNS, and the DMARC reports mailbox providers send back are received and parsed, so you see who tried to send as you and whether it passed. Every incoming message shows its SPF, DKIM and DMARC verdict, and links that look like impersonation are marked with a warning.

Access stays in your hands. Owners and admins decide who joins, in which role, and whether two-factor authentication is mandatory. Changes to the mail server's configuration are written to a log that the database refuses to edit or delete. Our own support team sees settings, never message content, and only with a stated reason, for an hour, on the record.

When policy says email may not be kept by an outside party at all, the mail layer is installed on your servers. The database, the inboxes, the encryption keys and the audit logs then sit in your network, are backed up under your procedure, and are held by nobody but your security team. That is described on the data sovereignty page, and the installation itself on the on-premise page.

What we do not have yet

A security page that hides its gaps is a risk in itself. These are the questions security teams ask that we cannot answer with a yes today.

ISO 27001 or SOC 2

We do not hold either certification. We have internal penetration tests, written security reviews, secret scanning in CI, and container images scanned and signed before release, and we walk you through them.

SAML single sign-on

Sign-in today is a password with two-factor authentication. Connecting your own identity provider is written as part of an on-premise project.

Audit export to your SIEM

Audit logs are read on screen and through the API. Automatic forwarding to a monitoring system does not exist yet; an installation project writes it for your tool.

Related: data sovereignty · on-premise installation · what we don't do

Clear answers

Email security: questions from security teams

Review the security of your organisation's email

A conversation with the people who build the platform, the written security documents, and a direct answer on what is still missing.

Book a call