“My email” is a phrase that hides a lot of geography. A single message you sent last week might exist, right now, in four or five different places at once: your provider's servers, your Mac's local cache, your phone's local cache, a backup somewhere, and possibly a recipient's own server copy. This post walks through where mail actually lives, provider by provider, and where STAMP's local index fits into that picture.
The source of truth: your provider's servers
For almost every email account, the authoritative copy of your mail lives on your provider's servers, not on any device. This is true whether you use Gmail, Outlook, iCloud Mail, Fastmail, or a smaller IMAP host.
Gmail and Google Workspace. Your mail lives in Google's data centers, replicated across multiple locations for durability. Gmail is accessed through Google's own API rather than raw IMAP in most modern clients, but the underlying model is the same: the server is authoritative, and every client (web, mobile, desktop) is a synced window into it.
Outlook and Microsoft 365. Same pattern, on Microsoft's infrastructure, accessed via Microsoft Graph or Exchange protocols. Enterprise 365 accounts may also be subject to organizational retention and eDiscovery policies set by an employer's admin, which is worth knowing if you use a work account for anything personal.
iCloud Mail. Apple hosts the authoritative copy on its servers. iCloud Mail supports IMAP for third-party clients, with OAuth-style app-specific passwords standing in for full OAuth support today.
Fastmail and other IMAP providers. Same model: the provider's server is the source of truth, accessed over standard IMAP and SMTP, the two protocols we cover in detail in IMAP, SMTP, OAuth, explained.
Proton Mail (via Proton Bridge). Proton stores mail encrypted on its servers, decryptable only with your key. Proton Bridge runs locally on your Mac and translates Proton's encrypted format into standard IMAP and SMTP that a normal client, including STAMP, can talk to. This is the one case in this list where the provider itself cannot read your mail content, by design.
The second copy: your device's local cache
Every email client you have ever used, going back to Outlook Express in the 1990s, keeps a local cache. This is not optional; it is how a client shows you your inbox instantly instead of re-downloading every message from the server each time you open the app.
That local cache typically includes:
- Message headers (sender, subject, date) for fast list rendering.
- Full message bodies for messages you have opened, sometimes for everything depending on the client's sync settings.
- Attachments, either cached fully or fetched on demand.
- A local index for search, so you are not sending every search query to the server.
This cache lives on your Mac's disk, inside the client's application support folder, and it is a real copy of your mail content, not just a pointer to it. If your Mac's disk is unencrypted and the machine is lost or stolen, that cache is exposed. FileVault (macOS's built-in full-disk encryption, in System Settings > Privacy & Security) closes that gap, and we recommend it regardless of which email client you use.
Where STAMP's local index fits
STAMP keeps a local SQLite database on your Mac, the same category of local cache every email client needs to function. It holds synced message data, your classification tags, and your triage state (what you have marked urgent, VIP, archived).
Two things distinguish it from a client that also runs a server-side copy: first, there is no server-side mirror of this data on STAMP's infrastructure, so the SQLite file on your disk is the only STAMP-controlled copy that exists anywhere. Second, the classification that populates those tags runs against that local database, on-device, which we cover in full in on-device email classification, explained. The provider's server (Gmail, iCloud, whichever you connected) remains the authoritative copy, exactly as it would with any client. STAMP does not add a second cloud copy on top of that.
What "deleted" actually means, across all these copies
Delete a message in your client and it is rarely gone everywhere at once:
- Your client marks it deleted locally and tells the server via IMAP or the provider's API.
- The provider moves it to a trash folder, not permanent deletion, typically for 30 days (Gmail, iCloud) before actual purge.
- Your other devices sync the deletion on their next check, updating their own local caches.
- Backups, if your provider or a backup tool keeps them, may retain the message past its trash-folder expiry, sometimes for a defined retention window, sometimes indefinitely depending on the backup product.
- If you sent the message, the recipient's own copy on their server and their devices is entirely unaffected by anything you do on your end.
That last point trips people up more than any other. Deleting a sent email removes your copies. It does nothing to the recipient's.
The practical takeaway
Your email is not stored in one place, no matter what client you use. It exists on your provider's servers as the source of truth, in a local cache on every device you have ever synced it to, and briefly in trash and backup layers even after you think you deleted it. A privacy-conscious client can control what it adds to that picture (a local index instead of a second cloud copy, no training pipeline reading that index) but it cannot change where the provider itself stores the authoritative copy. That part is between you and Gmail, Microsoft, Apple, or whichever provider you chose.
Where to go from here
For the protocol layer behind provider sync, IMAP, SMTP, OAuth, explained. For what runs against that local copy and why, on-device email classification, explained.
One local copy. No server-side mirror. hello@stamp.email