Privacy claims in software are mostly marketing. The honest claims are short, specific, and verifiable. The dishonest claims are long, full of qualifiers, and impossible to disprove.
Here is a working framework for evaluating an email client's privacy posture in 2026.
The five questions
Ask any vendor:
- Where is email content processed? On-device, on the vendor's server, on a third-party AI server?
- What is retained, and for how long? Specifically about your inputs, not just “outputs.”
- Who has access? Engineers, support, abuse monitoring, law enforcement under what process?
- Has it been audited? By whom, when, what scope, and where is the report?
- What is the breach disclosure policy? Public, timed, no exceptions?
If a vendor cannot answer any of those clearly in writing, treat it as a yellow flag.
The five red flags
Things that should make you pause:
The privacy page is full of weasel words. “We may use your data to improve our services” means “we will use your data to improve our services.”
The vendor uses a third-party AI service but will not name it. “Industry-leading AI partners” is a deflection. Name them.
Authentication is password-based, not OAuth. In 2026, this is a regression for any major provider.
Tokens are stored outside the OS keychain. Plain text on disk, even “encrypted,” is fragile.
There is no public security contact. No security@vendor.com, no responsible-disclosure page. Hard pass.
What a good privacy page looks like
A good privacy page is short. It says specifically:
- What data is collected.
- Where it is processed.
- What is retained, and for how long.
- Who it is shared with, and why.
- How to revoke access.
- How to file a privacy complaint.
It does not need legalese. It does not need 14 pages of qualifiers. The clearer it is, the more confident the vendor is in the posture.
The transparency report question
Mature vendors publish a transparency report once a year. The report covers:
- Number of law enforcement requests received and complied with.
- Number of breaches in the period (zero, hopefully).
- Any architectural changes that affect privacy.
Most early-stage vendors do not have one yet. Ask when they plan to. We are committed to publishing ours in 2027 H1.
A vendor without a transparency report is fine. A vendor without a plan to publish one is a flag.
What about Gmail and Microsoft 365
Most users connect their email client to Gmail or Microsoft 365. The vendor of your email client is one trust party; your provider is the other.
Both Google and Microsoft have published their privacy postures in detail. Both index your mail to provide their service. Both have transparency reports. Both have law-enforcement processes.
If you are not comfortable with that, your fix is at the provider level (move to Fastmail, Proton, or a self-hosted IMAP), not at the client level.
This is sometimes a useful thing to clarify with users. The most you can ask of an email client is that it not make your provider's privacy posture worse. The client cannot make it dramatically better, because the data is on the provider's servers either way.
STAMP's own scorecard
Honest answers to our own five questions.
Where is email content processed? On your Mac, in memory. We do not run servers that touch email content for routine use.
What is retained? No email content on our infrastructure. Locally, the on-device model has a small adapter that records your tag corrections. That adapter is yours and never leaves your machine.
Who has access? Nobody at STAMP. Nobody at any subprocessor. We have no production system that holds user email.
Has it been audited? Not yet. Independent audit scheduled for 2026 H2 by a firm we will name when we have signed.
Breach policy? Public disclosure within 72 hours, no exceptions, posted on our blog and emailed to every affected user.
If any of those answers stops being true, we will publish a release note in 18-point bold and an email to every user before the change ships.
What we will not promise
To stay honest:
- We cannot promise zero bugs. We will promise fast disclosure when we find them.
- We cannot promise the model never makes a mistake on classification. We will promise the mistake stays on your machine.
- We cannot promise we will exist forever. We will promise that if we shut down, we will publish a clear data-export and account-disconnect path 90 days before.
These caveats are not boilerplate. They are the actual ones.
What you can do today
Three concrete actions to improve your email privacy this week, regardless of which client you use:
- Audit your connected apps. myaccount.google.com/permissions for Gmail, similar pages for Outlook and iCloud. Revoke anything you do not actively use.
- Move to OAuth-only auth. If your client still uses passwords for any account, switch to OAuth or app-specific passwords.
- Read your client's privacy page. All of it. If you cannot tell what they do with your email, ask.
Where to go from here
For the technical side, on-device email classification, explained and IMAP, SMTP, OAuth — what actually happens. For the philosophy, why your email client should not read your email.
Privacy by architecture, not promise. hello@stamp.email