Kuju Email is in private development. This overview describes the platform as it will ship, so you can evaluate it before we open. Get notified at launch or read the overview.
Kuju Email · security
What protects your mail, and what doesn't.
This page describes how the service works today, including the parts we have not built yet. If a protection is not listed here, assume we do not offer it.
Kuju Email does not use end-to-end encryption, and messages are not encrypted per mailbox. That means the service itself can read stored mail — which is what lets it filter spam, search your mailbox and serve it to any IMAP client. It also means a small number of Kaimoku operators with access to the production systems can technically read stored messages.
Kaimoku site administrators can reset the password of any account. Today there is no per-mailbox access log: neither that action nor an operator reading stored mail is recorded in an audit trail you can see.
If your organization has a domain administrator, they can reset passwords and recover accounts within your domain.
Our Acceptable Use Policy says we do not routinely read the content of your messages, and lists the circumstances in which we may review it.
Our operators open the content of a mailbox only when you ask us to as part of a support request, to investigate a security incident, or when we are legally compelled to.
Where your data lives
Production runs on Akamai (Linode) in the Washington, DC region, in the United States. Your mailbox, its metadata and your account are stored there.
Off-site backups are stored in Cloudflare R2 object storage. Cloudflare chooses the storage location; we have not pinned it to a region.
The third parties that receive customer data are described in our privacy policy.
Encryption at rest
Message bodies and attachments are stored on a Linode Block Storage volume with Linode's volume encryption turned on. Every production server's boot disk is encrypted the same way. In both cases the encryption keys are managed by Linode, not held by Kaimoku: this protects against a lost or discarded disk, not against someone with access to the running system.
Credentials you give us for other services — for example the password for a mailbox you import from — are additionally encrypted by the application with AES-256-GCM before they are stored. The encrypted values live in our database; the key that decrypts them is kept in a separate secrets store.
Our database holds account records and message metadata, including senders, recipients, subject lines and a search index of message text. We have not confirmed that the volume holding the database is encrypted at rest, so we do not claim it.
Backups are not encrypted by us before upload. They rely on Cloudflare R2's own storage encryption, which we have not configured or independently verified.
Encryption in transit
Between your devices and Kuju
IMAP (port 993, or 143 with STARTTLS) and mail submission (port 587 with STARTTLS) negotiate TLS 1.3 with a valid certificate. Ports 465 and 995 are not offered.
Webmail is served over HTTPS only, with HTTP Strict Transport Security set for one year across subdomains, so browsers refuse to fall back to an unencrypted connection. Calendar and contacts sync (CalDAV and CardDAV) also run over TLS.
Between mail servers
Our inbound mail server offers encryption (STARTTLS) to every sending server but does not require it — refusing unencrypted delivery would bounce legitimate mail from servers that cannot encrypt.
When we deliver your outgoing mail, we encrypt the connection whenever the receiving server supports it, but we do not verify that server's certificate. That protects against passive eavesdropping, not against an attacker able to impersonate the receiving server.
We do not yet publish MTA-STS, DANE or DNSSEC for our own mail domain. We do publish a strict DMARC policy (reject) so that mail forged in our name is refused by receivers that honour it.
Passwords and sign-in
Passwords are never stored in readable form: we keep only a bcrypt hash.
You can protect webmail sign-in with an authenticator-app code or a passkey. Two-factor sign-in protects the web interface only. Mail apps connecting over IMAP, POP3 or SMTP, and calendar and contacts apps, sign in with your account password alone, and we do not yet offer app-specific passwords. A strong, unique password matters for that reason.
Web sessions use a cookie that page scripts cannot read, is only sent over HTTPS and is not sent with requests from other sites. Sessions expire after 24 hours by default and can be revoked from our side. Password-reset and invitation links are stored only as hashes.
When mail content leaves our systems
AI spam and phishing scan
Incoming mail is checked by an AI model as part of spam and phishing filtering. For each message scanned, we send the sender (From), the subject, the results of the SPF, DKIM and DMARC checks, and up to the first 4,000 characters of the message text to Together.ai, which runs the model. This happens when mail arrives over SMTP; mail you import from another provider is not scanned this way.
The scan is enabled per domain, and a domain administrator can turn it off for their domain. Individual users cannot opt out on their own.
Message analysis you ask for
Where your domain has message analysis turned on and you open the analysis of a message, its headers and up to 8,000 characters of its text are sent to the configured AI provider.
When you run a link-safety check on a message, the links in it are sent to Google to be compared against its lists of known phishing and malware sites.
Spam filtering lookups
Like most mail services, our spam filter looks up the sending server's address and the domains in a message against public blocklists, using ordinary DNS queries.
Attachments are checked for viruses on our own servers as part of delivery; that scan does not send your mail anywhere.
How the platform is run
Production runs on Kubernetes with Talos Linux, an immutable operating system managed only through an API — the cluster nodes have no SSH login at all. Changes are deployed from a version-controlled configuration repository.
Servers talk to each other over a private network, and their firewalls drop all inbound traffic that is not explicitly allowed.
The site-administration interface is not reachable from the public internet — only from our private administrative network. The cluster's management interfaces accept connections only from an allowlist of administrator addresses.
Service credentials are kept in OpenBao, an open-source secrets manager, and issued to services through least-privilege Kubernetes identities — never baked into images or source code.
The mail service runs under Kubernetes' baseline Pod Security standard.
How the software is built
Every build runs secret scanning (gitleaks), static analysis (gosec), dependency vulnerability checks (govulncheck) and a filesystem vulnerability scan (Trivy). Most findings are reported for review rather than blocking the build.
A container image with a known critical vulnerability that has a fix available is not published.
Images are signed with cosign and carry a build-provenance attestation. Production does not yet verify those signatures before running an image.
Backups and deletion
The database is backed up daily, with continuous transaction logs in between, and those backups are kept for 30 days.
Stored mail is copied to off-site backup daily. We rehearsed restoring from that copy in September 2026, and the restored files matched the originals exactly.
The mail backup only adds files; it does not currently remove mail you have deleted, so copies of deleted messages can remain in it. Our privacy policy describes what is deleted when an account ends.
An expired trial account is frozen, and deleted 30 days later.
Requests from law enforcement
Kaimoku Technologies is a US company and your data is stored in the United States, so US legal process applies to it. Because mail is not end-to-end encrypted, we are technically able to produce stored messages if legally compelled. Our privacy policy says we may disclose information when required by law or legal process.
We require a search warrant before producing the content of messages. Other legal process, such as a subpoena, can reach only account information, such as account details and sign-in records.
We tell affected users about a request before we respond, unless the law or a court order forbids it.
We push back on requests that are overbroad or legally defective.
If something goes wrong
If we confirm a security breach that affects your data, we will notify the affected account owners by email within 72 hours of confirming it, saying what happened, what data was involved and what we are doing about it.
What we don't have yet
No security certification (such as SOC 2 or ISO 27001), and no external penetration test or audit.
End-to-end or zero-access encryption.
A per-mailbox log of administrator and operator access.
Two-factor protection or app passwords for mail apps.
MTA-STS, DANE or DNSSEC for our own mail domain.
Reporting a vulnerability
If you believe you have found a security issue in Kuju Email or this website, tell us with the form below. We acknowledge every report within three business days and keep you informed while we fix it. Please give us a reasonable chance to fix an issue before you disclose it publicly.
We will not pursue legal action against anyone who reports a vulnerability in good faith, stays within the scope of that research, and avoids accessing other people's data or disrupting the service.