We designed the service so we cannot read it.

Identity

Mailcycle has no sign-up form. Creating an account generates 128 bits of entropy from the device's CSPRNG, encodes it as a twelve-word recovery phrase using a BIP-39 construction with a 4-bit checksum, and stretches it into a 64-byte root seed with 120,000 rounds of PBKDF2-HMAC-SHA-256. Everything else is derived from that seed by domain-separated HMAC, including:

• Account id: acct_<32 hex>. Public and opaque. It is the only identifier we learn, and it carries no name, address or device.
• Sign-in keypair: an X25519 key. We store only the public half. Signing in answers a single-use challenge with it, so nothing that opens the account crosses the wire, and a database dump cannot be replayed to sign in.
• Vault key: encrypts your mail. It never leaves the device.

The account record itself is that id, that public key, a plan and a creation date. Sessions, devices, addresses and payments hang off it, and the Privacy Policy lists every one.

An optional passphrase acts as a thirteenth word. It changes which account a phrase opens, and nothing anywhere records that one was used: a stolen written phrase without it opens a different, empty account.

The 120,000 rounds run in plain JavaScript, so the first unlock on a device takes around 40 seconds. If you choose to stay signed in, the root seed is kept in the iOS Keychain or Android Keystore (browser local storage on web) so later launches are instant. The phrase itself is never stored. You can add an app lock (Face ID, fingerprint or device passcode on phones, an idle sign-out on web), and see and revoke your signed-in sessions in Settings.

Authorization model

Mailcycle has two identities, with different reach.

• Operator: your account. Authenticated by proving possession of the recovery phrase, then held as a bearer session of up to 30 days that is unrelated to the phrase, so a leaked session token cannot be turned back into an account. Can manage every device, email address and payment on the account, and send mail from its own addresses.
• Worker: one device. Authenticated with a credential minted at pairing. Can read mail for its own assigned email addresses and report that it is active. It cannot send mail, enumerate other devices, mint addresses, change assignments or reach billing.

Every device-scoped and address-scoped call is authorized against the owning account before it returns anything, so knowing an identifier is not enough. A request for a record belonging to another account returns 404 rather than 403, so the API cannot be used to probe whether an identifier exists.

Device credentials

• Minted server-side only after an authenticated Operator explicitly confirms the device.
• Scoped to one device and revocable on its own, without affecting other devices.
• Stored in the iOS Keychain or the Android Keystore via the platform secure-storage APIs. On web, which has no equivalent, the token is narrowly scoped and revocable server-side.
• Returned to the device once, at pairing. No endpoint reads it back.
• No password is ever written to a device.

Removing a device from the console revokes its credential immediately and unassigns its email addresses, which stay on your account. The device falls back to the pairing screen with no access to prior mail.

Pairing

Pairing gives authority to a device that has none, which makes it the most security-sensitive part of the product. The server enforces:

• Pairing tokens are cryptographically random and generated by the server, never by the device.
• The 8-digit code is a lookup key onto the token. It is not the secret and is not accepted as authentication.
• Sessions are consumable exactly once and can be cancelled. They do not expire while someone is pairing; a code nobody claims is deleted after 14 days.
• Claiming a session requires a valid Operator bearer token.
• Code lookups are rate limited per account and per IP address: ten wrong codes in five minutes blocks further lookups.
• The Operator sees the device platform, identifier and request time before confirming.

Encryption

• In transit: HTTPS on every connection to the site, the app and the API. Mail from other servers reaches us through Cloudflare Email Routing, and whether that hop is encrypted depends on the sending server.
• Content: mail arriving over SMTP is sealed to the address's X25519 public key, whose private half is derived from your recovery phrase on your device. Bodies and attachments are stored sealed; a single attachment over 20 MB is listed but not stored. Address labels, device names, tags and notes are sealed on your device with ChaCha20 and HMAC-SHA-256, encrypt-then-MAC. Each ciphertext is bound to the record that owns it, so two swapped blobs fail authentication instead of showing one address's mail in another.
• Per-address keys: every email address gets its own key derived from the vault key, so a key given to one device unlocks that device's mail and nothing else.
• At rest: our hosting provider's storage encryption, which also covers the routing metadata we hold in the clear.
• Secrets: Mailcycle has no passwords to store.

Key handover

At pairing, the Operator holds the keys, a new Worker device needs them, and our servers must not learn them in passing. Mailcycle uses the camera as an out-of-band channel.

1. The Worker generates a wrapping secret and keeps it locally. It appears only in the QR code on its own screen and is never sent in a request or logged.
2. The Operator's phone reads it optically while scanning.
3. The Operator seals the address keys under it and uploads the sealed blob.
4. We relay a blob we have no key for. The Worker unwraps it locally.

What we can still see

What our servers can see:

• Email addresses, because a mail server must read the envelope to deliver. Generated addresses are a random token with an optional prefix you pick. On plans with custom addresses you choose the whole name, and it says whatever you chose.
• Message timestamps, sizes, counts and read state. Stored sizes are exact, so a size could match a message someone already knows was sent.
• Mail you send. A message to an ordinary address has to leave as plain text, so our servers see it while sending. It is handed to Cloudflare Email Sending and not stored or logged. Your own copy is sealed on your device first.
• That a device was active, to the hour. Precise last-seen times would show when a person wakes up.
• Push notifications, if you turn them on. They go through Expo and then Apple or Google, with fixed text such as “You have new mail.” and a link to the address it arrived at. No subject, sender or content.
• Custom domains you add, because we route their mail.
• Your retention window and your plan, because our servers enforce the first and bill the second.
• Network-level facts: connections come from IP addresses, and our edge and DDoS providers see them transiently. We do not join them to accounts or retain them as account history.
• Payment identity, if you pay by card or through an app store. That provider learns who you are, and the link to your account exists in their systems, not ours. It is the largest gap in an otherwise anonymous account.

Mail handling

• Devices cannot send. Only the account can, over the API, from addresses it owns, and sending is rate limited. A compromised device cannot be used to send mail from your domain.
• Sending is limited per account and per IP address, on top of limits at the edge.
• Remote content in messages is never loaded. Your device strips tracking pixels and remote images when it opens a message, and the app lists what was removed. Opening a message tells the sender nothing.
• Attachments are sealed and stored separately from messages, and downloaded only through the authenticated API. A single attachment over 20 MB is not stored, and the app says so. Messages over 25 MB are refused.

Internal access

Mailcycle has one administrator. The admin console is a separate build that is not published anywhere and opens only with its own recovery phrase. Every administrative change is written to a hash-chained audit log in the same transaction as the change. The console shows metadata: account ids, plans, addresses, device counts, message counts and billing records. It has no way to open mail.

There is no internal viewer, break-glass procedure or escrowed master key. Anyone with full production access sees the same ciphertext an attacker would.

Retention & deletion

• Every email address has a retention window you choose: 24 hours, 7 days, 30 days or 90 days, defaulting to 7. Mail past it can no longer be read from that moment, and an hourly server-side sweep deletes it, attachments included. Nothing is archived or soft-deleted.
• Ninety days is the longest window available.
• Unassigning an address detaches it from a device, but it stays on your account and still counts toward your plan. Deleting an address deletes its mail, frees its place on your plan, and retires the address so it is never reissued to anyone.
• Deleting your account erases the account record, every email address, every message, every paired device and the subscription immediately, with no grace period. Billing records required for tax and accounting are kept, and they contain no mail.
• Our database provider keeps a point-in-time restore window of up to 30 days, so deleted records can be restorable for that long. Message bodies and attachments live in object storage, which is not backed up.

The full detail lives in the Privacy Policy.

Infrastructure

• Hosted on Cloudflare, whose data centres are independently audited. Current vendors are listed in our subprocessor list.
• The API, database, object storage and mail routing all run on Cloudflare Workers, D1, R2 and Email Routing. There are no other servers.
• Rate limits apply at Cloudflare's edge and, more strictly, as per-account and per-IP quotas in the database. The edge limits absorb floods; they are not exact.
• Nothing here has had an independent security audit. The app's cryptography is hand-written with no third-party libraries, tested against published test vectors, and has known limits: no forward secrecy, so anyone who gets your recovery phrase can read all mail still stored.

Compliance

Mailcycle processes personal data as a processor on your behalf. We offer a Data Processing Agreement including the EU Standard Contractual Clauses for international transfers, and we maintain a published subprocessor list with advance notice of changes.

Report a vulnerability

If you believe you have found a security issue in Mailcycle, please tell us before you tell anyone else. We will not pursue legal action against researchers who act in good faith under this policy.

Email hello@mailcycle.email. Include what you found, how to reproduce it and what you think the impact is. We acknowledge reports within two business days and aim to give you a remediation timeline within ten.

In scope: mailcycle.email, app.mailcycle.email, api.mailcycle.email, and the official iOS and Android apps.

Please do not: run denial-of-service tests, send bulk or spam mail through the service, social-engineer us or our customers, or access, modify or retain data belonging to anyone but yourself. If you encounter someone else's data, stop and tell us.