Your account credentials and OAuth tokens, encrypted at rest on our servers. That's what lets one login carry every account to any device. Skybox decrypts them server-side to connect to your providers, and to put them in an account export you ask for. Your Skybox password is kept only as a salted hash.

Message bodies and attachments are never stored on our side. What does get stored is what makes your lists fast: for every message, our database keeps its date, flags, size, whether it has attachments and hashed threading ids, along with your folder names and counts, for as long as the account is connected. Subjects, names and addresses sit in a cache that expires after 24 hours and is written to disk. When a mail carries a one-time code, a model we run ourselves reads the message to find it, and the code is kept for 15 minutes. You can switch that off. A file you send as a download link stays on our server until the link expires.

Your apps also keep the messages you've opened, bodies and attachments included, in a cache on your device. Signing out or clearing the cache removes it.

It protects your credentials in a leaked database dump or backup. It does not protect against a compromise of the running server, an insider with key access, or a legal request, because the relay has to be able to decrypt credentials to use them. The key is one key for all accounts, kept on the same server as the database rather than in a separate key vault, so whoever takes over that machine has both. The metadata and the cache above aren't encrypted this way at all. Skybox is not a zero-knowledge system, and we won't pretend otherwise.

Because zero-knowledge and “one login, everything on every device” are mutually exclusive. If nothing server-side can open a connection while you're logged out, there is no push, no scheduled sending, and a forgotten password becomes total, unrecoverable account loss.

In a web app the guarantee is weak anyway: the server ships the decryption code on every load, so a compromised server defeats it regardless. For a web-first, multi-device client, server-held keys are the coherent design. We chose this tradeoff deliberately.

Skybox is a relay: your mail passes through it on the way to your browser or app, and the relay can read it while it does. It also stays connected to your mail server while you're signed out, which is what makes push and scheduled sending work. That's inherent to the architecture, not a flaw.

Not every hop is encrypted the same way, so here they are. Your device to Skybox runs over TLS, and so does Skybox to your mail server over IMAP. Sending uses TLS on port 465, and on other ports Skybox demands STARTTLS and fails the send rather than putting your mail and your password on the wire in the clear. Calendar and contact servers have to be reached over https; an account still stored with an http address stops working and says why. Inside our own setup, services talk to each other without TLS.

If your threat model requires local-only handling, a local client is the better tool. We'd rather tell you that than have you discover it.

Product analytics and session replay stay off until you turn on “Help Improve Skybox” in Settings, and the desktop app sends none either way. In the browser, and in the iPhone and Android apps once they're out, turning it on sends screen views by route pattern, errors and logs with the addresses, links and credentials filtered out of them, and performance timings to PostHog on European servers, tied to your user id but not your email address. A browser replay shows every text as dots unless we marked it as our own chrome, and the message body isn't recorded at all. A phone replay is about one screenshot a second, with the screens showing mail, contacts, calendars and settings blacked out whole. Two Android sheets stay readable, because the recorder's masking doesn't reach them: the actions sheet for a message or a contact, and the folder picker. Masking is code, not a promise, so we say that plainly. The browser stores nothing on your device for it except your answer; the phone apps store an analytics id. Separately, our server sends its own error reports and logs, filtered the same way, and a few usage events, like “a mail was sent” with counts only, to the same place. This marketing site runs none of it.

And mobile push, once the iPhone and Android apps are out: a notification about new mail goes through Google's push service, on iPhone onward to Apple's, and carries the sender's name and address, the address it was sent to, the subject line, the folder, a one-time code if there is one, and your unread count. Never the body or attachments. You can turn notifications off on the device, per account, or for quiet hours. The browser and desktop apps use neither; they get their events straight from us.