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.
The first unlock on a new 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 a six-digit Mailcycle passcode on phones, an idle sign-out on web), and see and revoke your signed-in sessions in Settings.
What this costs you. There is no account recovery. We hold nothing to reset and no address to send a link to. Lose the phrase and the mail is unrecoverable. Every screen that shows a phrase says so before you can move past it.
Authorization model
Mailcycle has two identities, with different reach. An AI agent is a Worker, with limits of its own.
- 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, star, move and delete mail at its own assigned email addresses, with the keys it was handed for those, and report that it is active. On Personal and above it can send from those addresses, and no others, up to 20 messages an hour (more on Fleet and Enterprise). It cannot 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. An AI agent keeps it in a file only your user can read.
- 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. A device that is open hears of it at once over its live connection, and one that is closed finds out when it next opens. Either way it 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, and repeated wrong codes block 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, with HSTS and TLS 1.2 or later. Whether mail from other servers is encrypted on its way to us 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. 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.
The limit. Inbound mail reaches our servers readable; that is how email works. Every part of it is sealed before it is stored, and the readable copy is never saved. Mail is encrypted at rest under a key only you hold; it is not end-to-end encrypted from the sender. Sending has the same limit in the other direction; see Mail handling.
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.
- 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.
- The Operator's phone reads it optically while scanning.
- The Operator seals the address keys under it and uploads the sealed blob.
- We relay a blob we have no key for. The Worker unwraps it locally.
An AI agent has no screen to show a QR code, so it prints the same secret as part of a line you paste into the app. That is the same out-of-band channel through your clipboard instead of a camera. A pasted line without the secret is refused rather than falling back to the weaker path below.
The manual code path is weaker, and the app says so. Typing an 8-digit code by hand gives no optical channel. Instead the device publishes a public key with its pairing session, and your app seals a fresh wrapping secret to it. We cannot read that by watching, but we relay the device's public key, so a server that swapped in its own key during pairing could read the keys that follow. The QR path has no such step. Our servers record which path each device used. Scan the QR code whenever you can.
AI agents
An agent is a Worker run by mailcycle-mcp, an MCP server on your machine. It holds keys only for the addresses you give it and decrypts there. What changes is who reads the mail: the agent passes it to a model, and mail from strangers can carry instructions aimed at that model. The limits below are enforced by our servers, not by the agent.
- Reply only by default. A new agent can only answer whoever wrote a message it received. A reply names that message, and its recipient has to match an address the message could be answered at: the envelope sender, From or Reply-To. You can let an agent send to anyone, or not at all.
- Only a signed-in session widens it. Changing an agent's send mode needs you signed in to the app. An API key cannot do it, so a leaked key cannot turn a reply-only agent into a sender.
- Its own limit. Each agent sends at most 20 messages an hour (more on Fleet and Enterprise) on top of the account's limit, and only from the addresses you assigned to it.
- Mail is labelled as data. The MCP server hands message bodies to the model marked as the sender's words. That helps; it does not make a model immune to what it reads.
- The key file is the agent. The agent's credential and key live in a file on its machine, readable only by your user. Anyone with that file can read the agent's mail. Disabling or removing the agent in the app revokes it at once.
The limit. The model provider your agent uses sees whatever the agent reads. That provider is your choice and is not our subprocessor. Our encryption protects the mail up to the agent; what happens after is between you and your provider.
What we can still see
What our servers can see:
- Email addresses, because a mail server must read the envelope to deliver. Rolled names are two words from our word lists, like maya.holt, and say nothing about you. On plans with custom addresses you can type the whole name, and it says whatever you chose.
- Message timestamps, sizes, counts, read state, folder and star. 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 our sending provider and not logged by us. The copy kept in the address's Sent folder is sealed to that address's key before it is stored, like received mail. We record whether it was sent from the app, an API key, a device or an agent.
- Reply fingerprints for AI agents. For mail to an address an agent holds, a one-way fingerprint of each address the message can be answered at, deleted with the message. It can confirm a guess about who wrote, but it is not a list of senders.
- Which paired Workers are AI agents, and what each agent may send, because our servers enforce it.
- That a device or agent was active, to five minutes. Our servers stamp the time on its requests, so the console can show which devices are online.
- Which devices are connected, while they are. An open device holds a connection so it hears at once when it is removed, or an address is assigned to it or taken off it. The connection carries event names and ids, never mail, and nothing about it is stored.
- Support requests: which account wrote, when, and whether the request is open. The subject and messages are sealed on your device to our support key and to your own, so only you and our support team can read them.
- Push notifications, if you turn them on. They go through our push provider 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 hosting provider sees 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
- Sending from a paired device needs Personal or above, and sending from an API key or an AI agent needs Scale or above. A device or agent sends only from the addresses assigned to it, at most 20 messages an hour (more on Fleet and Enterprise), so a compromised one cannot send from the rest of your addresses. Removing it stops it at once.
- Sending is rate limited, and each plan has a daily sending limit. Reaching it pauses sending until midnight UTC. Free receives mail only. Receiving is never paused.
- 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. Messages over 25 MB are refused. A message with more than 50 attachments keeps the first 50; the rest are listed but not stored, and the app says so.
- Mail you send can carry up to 10 files, 3.5 MB between them. Program and script files, like .exe or .js, are refused.
Domain vetting
Every shared domain is vetted before we add it, so your addresses don't start out distrusted by the services you sign up to or the people you write to. For each one we:
- Check its reputation with Spamhaus.
- Review its past use on the Wayback Machine, and pass on any domain that hosted spam, scams or abuse.
- Search the name, to avoid well-known companies' names and anything with a bad record.
- Choose only reputable domain endings, and names that don't read as throwaway mail.
Our servers refuse a shared domain unless each check has been confirmed. Shared domains are grouped by plan, and an account gets addresses on its own plan's group and the groups below it. Paid plans have a shared domain free accounts never reach, so what a free account does cannot touch its reputation; paid plans can use the free one too. A shared address still carries the reputation of everyone on its domain. Bring your own domain from Scale if you would rather not share one. Domains you bring yourself are yours to choose and are not vetted by us.
Internal access
Administrative access needs its own key, and every administrative change is written to a tamper-evident audit log. Our admin tools show metadata: account ids, plans, addresses, device counts, message counts and billing records. They have no way to open mail. The only thing they can decrypt is support requests you send us.
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 it is then deleted from our servers, attachments included. Nothing is archived or soft-deleted.
- 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 and every paired device immediately, with no grace period. A card subscription is cancelled at the same moment, and if that fails we stop it at its next charge and refund it. Cancel an App Store or Google Play subscription in the store first. Billing records required for tax and accounting are kept, and they contain no mail. See how to delete your account.
- Deleted records can stay in our backups for up to 30 days. Message bodies and attachments are not backed up.
The full detail lives in the Privacy Policy.
Infrastructure
- Our hosting provider's data centres are independently audited.
- The app's cryptography is tested against published test vectors. It has 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 terms for international transfers, and give advance notice of subprocessor changes. Customers can ask us for the current list of subprocessors.
Certification status. Mailcycle does not currently hold a SOC 2 Type II or ISO 27001 certification. If your procurement process requires one, talk to us about timelines before you commit.
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 aim to acknowledge reports within two business days and to give you a remediation timeline within ten.
In scope: mailcycle.email, app.mailcycle.email, api.mailcycle.email, the iOS and Android apps once they are in the stores, the mailcycle-mcp package, and the SDKs: mailcycle-sdk on npm, mailcycle on PyPI, mailcycle.email/go and mailcycle on crates.io. Each carries the same client-side encryption the apps use.
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.