How MailZyro Encryption Works

Last updated: March 8, 2026

MailZyro's goal is simple: nobody except you and your intended recipients can read your email. We achieve this through two complementary encryption modes — end-to-end encryption (E2EE) for messages between MailZyro users, and zero-access encryption for emails received from external senders.

This document is the technical reference for how MailZyro protects your data. It covers our encryption architecture, key management, email lifecycle, confidential mode, external encrypted sharing, encrypted search, and honest threat model.

1. Two-Layer Encryption Overview

MailZyro uses two encryption modes depending on where the email originates:

In both modes, the stored email content is OpenPGP ciphertext that only you can decrypt with your private key.

2. End-to-End Encryption (E2EE)

Applies to: emails sent between MailZyro users.

When you compose an email to another MailZyro user, encryption happens entirely in your browser:

1. Your client fetches the recipient's public key from the MailZyro key directory.
2. The email body is encrypted with the recipient's public key using OpenPGP.
3. The message is signed with your private key, proving authenticity.
4. Only the ciphertext and a placeholder body are sent to the server — the plaintext never leaves your device.

The server stores the encrypted message in the encrypted_emails table. A copy encrypted to your own public key is also stored so you can read your sent messages.

Because encryption happens before the data reaches the server, MailZyro operators cannot read E2EE messages — even with full database access.

3. Zero-Access Encryption

Applies to: emails received from external senders (Gmail, Outlook, corporate mail servers, etc.).

External email arrives via SMTP — a protocol that does not support end-to-end encryption between different providers. MailZyro encrypts these emails as soon as they arrive:

1. The email is delivered via SMTP to our mail server (Stalwart).
2. A webhook fires immediately on delivery.
3. The server fetches the email body via JMAP and encrypts it with your public key using OpenPGP.
4. The encrypted ciphertext is stored. The original plaintext is discarded.

Honest Disclosure

During step 3, the email body exists briefly in server memory as plaintext while it is being encrypted. This processing window is measured in milliseconds, but we believe in transparency: zero-access encryption requires a brief trust-the-server moment for inbound external mail. This is the same model used by ProtonMail and Tutanota for external email.

After encryption, MailZyro cannot decrypt the stored content — only you can, with your private key.

4. Key Generation & Storage

4.1 PGP Key Pair

When you create a MailZyro account, a PGP key pair is generated in your browser:

• Algorithm: Curve25519 (EdDSA for signing, ECDH for encryption)
• Library: OpenPGP.js v6
• Format: Armored OpenPGP keys
• Your public key is uploaded to MailZyro so others can encrypt emails to you.
• Your private key is encrypted before being stored (see below).

4.2 Password-Based Key Protection (Legacy)

For users who registered with a mailbox password, the private key is encrypted using:

• Key derivation: Argon2id with 3 iterations, 64 MB memory, parallelism 1
• Salt: Random 16-byte salt, unique per user
• Cipher: AES-256 (via OpenPGP.js S2K)

Your password never leaves your browser. MailZyro cannot recover your private key if you forget your password.

4.3 SSO Key Derivation

For users who sign in via Maluki Auth (SSO), no passphrase is needed. Instead, a 32-byte encryption key is derived deterministically:

• Algorithm: HMAC-SHA256
• Input: HMAC-SHA256(server_secret, identity_id + ':mailbox-key')
• Output: 32-byte key used to encrypt/decrypt the private PGP key

The SSO-derived key is computed on the server during authentication and provided to the client over TLS. It is never stored persistently on the server — it exists only in the authenticated session response. The same identity always produces the same key, providing seamless encryption without a passphrase.

5. Address Key Architecture

MailZyro uses a ProtonMail-style address key system to support multiple email addresses per account:

• Each email address has its own address-level PGP key pair.
• A random token is generated and encrypted to the user's primary public key.
• This token encrypts the address private key, creating a chain: user key → token → address key.
• To decrypt an email, the client first unlocks the user key, then uses it to decrypt the token, then uses the token to decrypt the address key.

This architecture enables multi-address support (e.g., aliases, custom domains) without requiring separate passwords per address.

6. Multi-Mailbox Key Management

MailZyro supports multiple mailboxes (up to 10) under a single Maluki Auth identity:

• All mailboxes linked to the same identity share the same SSO-derived key (since the key is derived from the identity, not the mailbox).
• Each mailbox has its own independent PGP key pair — mailbox A cannot decrypt mailbox B's emails.
• A single SSO login unlocks all linked mailboxes seamlessly.

7. Email Lifecycle

7.1 Sending E2EE (All Recipients on MailZyro)

1. You compose an email in the MailZyro web client.
2. The client fetches each recipient's public key.
3. The email body is encrypted to each recipient's public key and signed with your private key.
4. The ciphertext is sent to the server alongside a placeholder body.
5. The server stores a per-recipient encrypted copy in the encrypted_emails table.
6. A copy encrypted to your own public key is stored for your Sent folder.

7.2 Sending to External Recipients

1. You compose an email to a non-MailZyro address (e.g., Gmail).
2. The email is sent as standard SMTP (external providers don't support MailZyro's encryption).
3. Your sender copy is encrypted with your public key so you can read it later.
4. Transport security: STARTTLS is enforced for server-to-server delivery where supported.

7.3 Receiving from External Senders

1. An external sender sends you an email via SMTP.
2. Our mail server (Stalwart) receives and stores the message.
3. A webhook fires, triggering the zero-access encryption flow (see Section 3).
4. The email body is encrypted with your public key and stored as ciphertext.

7.4 Reading Email

1. You open the MailZyro web client and authenticate.
2. SSO users: the mailbox key is derived automatically — no password prompt.
3. Legacy users: you enter your mailbox password to unlock your private key.
4. The client fetches the encrypted email and decrypts it locally in your browser.
5. You read the plaintext. It is never sent back to the server.

8. What We Can and Cannot Access

9. Threat Model & Limitations

We believe in honest security claims. Here is what our encryption protects against — and what it does not.

9.1 Database Breach

If an attacker gains access to our database, they obtain only ciphertext. Email content is encrypted with your public key; your private key is encrypted with your passphrase or SSO-derived key. Without your private key, the ciphertext is unreadable.

9.2 Full Server Compromise

If an attacker gains full control of the MailZyro server (including environment variables), they could theoretically derive SSO keys using the server secret and intercept new inbound emails before encryption. This is the same trust model used by ProtonMail and other zero-access email providers — a full server compromise allows a sophisticated attacker to access future emails but not already-encrypted stored content.

9.3 Known Limitations

• Some metadata is not encrypted: sender, recipient, and timestamps are visible to the server. Subject lines are encrypted for E2E emails but remain plaintext for external emails (an inherent SMTP limitation).
• Subject lines (non-E2EE): for emails received from or sent to external providers, the subject line travels as a plaintext SMTP header. E2EE emails between MailZyro users have encrypted subjects — the server stores only a placeholder.
• Brief plaintext window: inbound external emails exist in server memory as plaintext for milliseconds during the zero-access encryption step.
• External recipients: emails sent to non-MailZyro addresses leave our system as standard SMTP — we cannot encrypt what the recipient's provider stores.
• IMAP clients: if you access your mailbox via a third-party IMAP client, that client communicates with the Stalwart mail server directly and may see the pre-encryption copy.

10. Cryptographic Specifications

11. What's Encrypted

MailZyro encrypts different components of your email with different strategies. Here is a precise breakdown of what is protected:

Email Body

The email body is always encrypted before storage. For emails between MailZyro users, the body is encrypted client-side (E2EE) — the server never sees the plaintext. For emails from external senders, the body is encrypted with your public key on receipt (zero-access). In both cases, only you can decrypt the stored content.

Email Subject

For E2EE emails between MailZyro users, the subject line is encrypted alongside the body. The mail server stores only a placeholder subject. For non-E2EE emails (from external senders), the subject remains plaintext because the SMTP protocol requires it for delivery.

Attachments

Attachments are encrypted with per-file keys before being stored. E2EE attachments are encrypted in your browser before upload. Zero-access attachments are encrypted on receipt alongside the email body.

Search Index

Your local search index is encrypted client-side using AES-256-GCM before being synced to the server. The server stores only an opaque encrypted blob — it cannot read or search your index. See Section 15 for details.

12. What's Metadata (Not Encrypted)

Some data is inherently unencrypted because the email protocol (SMTP) requires it for delivery and routing. We are transparent about what we can see:

• Timestamp — when the email was sent or received.
• Sender email address — required for delivery and reply functionality.
• Recipient email address(es) — required for routing the email.
• IP address of sender — recorded by the mail server during SMTP delivery.
• Message-ID header — a unique identifier assigned per RFC 5322, used for threading and deduplication.
• Subject line (non-E2EE emails) — SMTP requires plaintext headers for external delivery. E2EE emails between MailZyro users have encrypted subjects.

Metadata retention is necessary for email delivery and is standard across all email providers. MailZyro retains metadata for the minimum period required for service operation and legal compliance.

13. Confidential Mode

Confidential mode allows you to send emails that self-destruct after a specified period or number of views. This provides an additional layer of control over sensitive communications.

Destruction Triggers

A confidential email is destroyed when either condition is met:

• Expiration date/time: the email is automatically destroyed after the specified date, regardless of whether it has been read.
• Maximum view count: the email is destroyed after being opened the specified number of times.

What Happens on Destruction

When a confidential email is destroyed:

• The encrypted email body is permanently deleted from the database.
• The JMAP message in Stalwart is replaced with a tombstone placeholder indicating the message was destroyed.
• Envelope metadata (timestamp, sender, recipient, IP address) is retained for legal compliance — this is standard practice and required by law in most jurisdictions.
• Destruction is irreversible. Once destroyed, the encrypted content cannot be recovered by anyone — including MailZyro.

Viewing Protections

While a confidential email is being viewed, the following deterrents are applied:

• Text selection and copying are disabled.
• Printing is blocked.
• A watermark with the recipient's email address is overlaid on the content.
• The content is blurred when the browser tab loses focus.

Honest limitation: these are deterrents, not guarantees. Screen photography cannot be prevented. We apply these protections to raise the bar, but we do not claim they are unbreakable.

14. External Encrypted Sharing

MailZyro allows you to send encrypted emails to recipients who do not have a MailZyro account. The recipient opens a secure link in their browser and enters a password you have shared with them separately.

Password-Based Encryption

When you send an externally encrypted email:

1. The email body is encrypted in your browser using a key derived from the password you choose.
2. The password is never stored on the server. Only a bcrypt hash is stored for verification when the recipient enters the password.
3. The recipient receives a link to a secure viewing page.

Client-Side Decryption

When the recipient opens the link and enters the password:

1. The password is used to derive an encryption key via PBKDF2 (100,000 iterations, SHA-256).
2. The derived key decrypts the email body using AES-256-GCM — entirely in the recipient's browser.
3. The server never has access to the plaintext or the password. It serves only the encrypted blob.

The same destruction policies available for confidential emails (expiration date, view count) can be applied to externally encrypted emails. Once destroyed, the encrypted content is permanently deleted.

15. Server-Synced Encrypted Search

MailZyro provides instant, private email search through a server-synced encrypted search index. This approach provides the convenience of cloud sync with the privacy of local-only search.

How It Works

1. The search index is built client-side using MiniSearch, a lightweight full-text search library that runs in your browser.
2. Before syncing to the server, the entire index is encrypted with AES-256-GCM using a key derived from your mailbox encryption key.
3. The encrypted index is uploaded to the server as an opaque blob. The server cannot read, search, or inspect its contents.
4. When you sign in on a new device, the encrypted index is downloaded and decrypted locally — giving you instant search without re-indexing your entire mailbox.

Privacy Advantage

Unlike some providers that require building a search index locally on each device (which can take hours for large mailboxes), MailZyro syncs your encrypted index across devices. The server stores only ciphertext — it cannot determine what you searched for, what your emails contain, or even how many emails are indexed.

16. Legal Compliance & Data Disclosure

MailZyro is transparent about what we can and cannot provide in response to lawful requests.

What We Can Provide

Envelope metadata — including timestamps, sender and recipient addresses, and IP addresses — is retained and can be provided in response to valid court orders issued under Kosovo law. Subject lines are only available for non-E2E emails; E2E email subjects are encrypted and inaccessible to the server.

What We Cannot Provide

Email body content and E2EE subject lines are encrypted with the user's public key. MailZyro does not possess the private key and cannot decrypt stored email content. This is a technical limitation, not a policy choice — even under compulsion, we cannot provide what we do not have.

Destroyed Content

When a confidential or externally encrypted email is destroyed, the encrypted content is permanently deleted. After destruction, the content cannot be recovered by anyone. Envelope metadata is retained per our standard retention policy.

MailZyro is operated by Dotnet SH.P.K., incorporated in the Republic of Kosovo. All data requests must comply with Kosovo law. We challenge requests that are overly broad or legally deficient.

Questions?

If you have questions about our encryption model or want to report a security issue, contact [email protected]. For privacy inquiries, email [email protected].

You can also review our Security and Privacy Policy pages for additional context.