How Ṣọ Mail Actually Protects You: Inside Our Privacy-First Architecture
This post was updated on April 29, 2026 to more precisely describe the Ṣọ architecture. An earlier version overstated certain technical specifics. The corrected version below is what actually ships in the product today.
What Does Privacy-First Email Security Actually Mean?
Most email security tools protect your inbox by reading every message you receive, storing those messages on their servers indefinitely, training models on the content, and licensing aggregated threat intelligence derived from that data. That is the tradeoff the industry has taught people to accept: protection in exchange for surveillance.
Ṣọ Mail is built on a different premise. Email is sent to our servers for analysis, processed in seconds, and immediately deleted. No logs of email content or headers are kept. No human at Ṣọ has a tool to read customer email. The verdict comes back to your device, the email itself goes nowhere else, and your messages are never used to train our models.
This post walks through what that architecture actually looks like in practice, what it does and does not guarantee, and how it compares to the gateway model used by most legacy vendors.
What Is the Difference Between a Policy and an Architectural Commitment?
The phrase privacy-first gets used loosely across the security industry. We try to be precise about which guarantees are policy and which are architectural.
Policy-level commitments are promises a company makes in its terms of service. They can change. They depend on employee behavior. They are reversible with a single internal decision.
Architecture-level commitments are technical constraints built into the product. They cannot be changed without rebuilding the product. They do not depend on any individual employee. They are enforced by code or by the absence of code, not by trust.
Most of Ṣọ's privacy story is architectural. A few elements are policy. Where we make a commitment, we try to be explicit about which kind it is.
How Does Email Get from Your Inbox to Ṣọ?
When you install the Ṣọ browser extension or open the desktop or mobile app, the extension reads the email you are looking at, in your browser, on your machine. The full email content (headers, body, and attachments) is then sent to Ṣọ-owned infrastructure over HTTPS/TLS for analysis.
This is the part of the architecture that has been described inaccurately in some past materials. We want to correct that here. Email content does leave your device. It goes to Ṣọ servers. The privacy story is not that your email never leaves your device. The privacy story is what happens to the email once it arrives.
What Happens to Your Email on Ṣọ Servers?
Three things, in order, on a timescale measured in seconds.
Step 1: The email is received and analyzed. Ṣọ's detection models parse the headers (SPF, DKIM, DMARC), inspect the body for BEC indicators and known phishing patterns, expand and check links against threat intelligence, and scan attachments for embedded scripts and macro flags. This analysis runs in seconds.
Step 2: A verdict is returned to your device. The result is one of clean, suspicious, phishing, BEC attempt, lookalike domain, or similar classifications. The verdict is what your extension displays in your inbox.
Step 3: The email is deleted. Once the verdict is returned, the email content is removed from Ṣọ infrastructure. No logs are written that contain email content or headers. No analysis records are persisted. No copy of the email exists on Ṣọ servers after processing completes.
This is what we call Zero Server Retention. It is a real architectural commitment. The email exists on our infrastructure for the duration of analysis, which is measured in seconds, and then it is gone.
Who at Ṣọ Can Read Your Email?
No one. There are no admin tools, debugging interfaces, or operational workflows that surface customer email content to a Ṣọ employee. There is no internal portal that shows recent emails. There is no escalation path where suspicious emails get queued for human review. There are no contractors or third parties with access.
The one place a hashed reference exists: when a user submits feedback on a verdict (a false positive or false negative report), the email content gets hashed before storage. The hash is irreversible. No one at Ṣọ, including the founder, can read the original email from the hash. The hash exists so that the same problematic email can be matched against future submissions and improve the detection patterns; it does not let anyone reconstruct what the email said.
This is what we call No Human Access. It is enforced by the absence of tools, not by a policy promise. A future founder at Ṣọ would have to deliberately build access tools to undo this guarantee.
How Is Email Protected in Transit?
Email is sent from your device to Ṣọ servers over HTTPS/TLS. This is the same encryption standard used by online banking, e-commerce, and almost every modern web service. It protects the email from interception by third parties between your device and Ṣọ infrastructure.
We have additional encryption details that are still being documented for public release, and we will update this post when those details are finalized. For now, the verifiable claim is HTTPS/TLS in transit.
What About Account Data?
Ṣọ does not persist customer data on our servers. There is no customer email database, no threat history database tied to your account, and no analytics database with identifiable user records. Your settings are stored in your local browser or app, not on Ṣọ infrastructure.
Subscription billing is handled through standard payment processors. Authentication tokens for your subscription exist on Ṣọ infrastructure as long as your subscription is active.
A user-initiated deletion feature is on the product roadmap and will ship in a future release. Until that ships, customers who want to end their use of Ṣọ can uninstall the extension and apps, which removes Ṣọ from their devices. We will update this section when the deletion feature is live and document exactly what gets removed and on what timeline.
How Does Ṣọ Make Money?
Subscriptions. That is the entire revenue model.
Freelancer plans, nonprofit plans, and small business plans all charge a monthly or annual fee. There are no ads. We do not sell aggregated or anonymized data. We do not license threat intelligence derived from customer email. We do not have data broker relationships. We do not train foundation models on customer content. Customer emails are not used to train our detection models in any form, anonymized or otherwise.
This is the pillar that makes the others economically durable.
A lot of privacy-first products start out with good architecture and then pivot when revenue pressure kicks in. The classic pattern is a free tier that scales users fast, then monetization via data licensing or advertising once the user base is big enough to matter. The architecture stays the same on paper, but the incentives shift.
Ṣọ's subscription model aligns our revenue with the architecture we built. We make more money when more people pay for the product. We do not make more money when we learn more about our customers. That alignment is why the other commitments are credible. Changing them would hurt the product without helping the business.
How Does This Compare to Legacy Email Security?
Legacy email security vendors (Proofpoint, Mimecast, Abnormal, Barracuda) operate at the mail gateway. Your organization changes its MX records so that inbound email goes to the vendor's servers first. The vendor's infrastructure receives the email, scans it, and forwards it on to your mailbox. In most configurations, they also retain copies for retrospective analysis and model training.
Both Ṣọ and legacy vendors process email on vendor-owned infrastructure. The differences are in what happens after processing.
Legacy vendors typically:
- Retain email content for extended retention windows (often days to years)
- Have analyst teams or incident-response operators who can read customer email
- Train detection models on customer email data
- License aggregated threat intelligence derived from customer email
- Maintain audit logs that contain email metadata or content
Ṣọ:
- Retains email for seconds during processing, then deletes it
- Has no human-access tools for customer email
- Does not train models on customer email
- Does not license derived intelligence
- Does not log email content or headers
These are real architectural differences, not marketing fluff. They matter especially if your inbox contains client work, donor records, legal drafts, health information, or anything else where a vendor's analyst team reading it would be a compliance problem.
What Are the Honest Tradeoffs?
Three tradeoffs are worth naming.
Cold-start detection on novel threats is slower. Server-side vendors that train on customer email have a faster feedback loop on emerging patterns. Ṣọ's models are trained on public data, synthesized data, and our own controlled test environments. We accept slightly slower adaptation to bleeding-edge threats in exchange for not training on customer mail.
No human escalation path on uncertain verdicts. Vendors with analyst teams can escalate ambiguous emails to human reviewers. Ṣọ has no equivalent because the architectural commitment to no human access prevents it. When our models are uncertain, the email gets flagged as uncertain and handed back to the user.
You pay more than free options. Privacy-first products that rely on subscriptions have to charge for the product because they cannot subsidize with data revenue. Ṣọ is not the cheapest option. The cheapest options are free because you are the product. We are explicit about this.
Frequently Asked Questions About Ṣọ's Privacy Architecture
Does Ṣọ work with Gmail, Outlook, and other providers?
Yes. Ṣọ is provider-agnostic. It works with Gmail, Outlook, iCloud, and any IMAP-compatible mail service. The browser extension reads the email through your existing authenticated session and sends it to Ṣọ for analysis.
Can I verify what gets sent to Ṣọ servers?
Yes. Open your browser's developer tools and watch the network tab while Ṣọ is running. You will see HTTPS calls to Ṣọ infrastructure containing email content for analysis, and you will see the verdict come back. We previously published a claim that you would not see email content going out, which was inaccurate. The corrected statement is that you will see email content go out, you will see the verdict come back, and our architectural commitment is that the content is deleted from our servers within seconds of analysis completing.
Does Ṣọ protect against BEC and invoice fraud?
Yes, and it is one of the areas where the architecture performs well. The detection runs against sender patterns, lookalike domains, payment-change language, and out-of-pattern requests. Document comparison features cross-check invoice details against historical patterns within an analysis session, then discard the data.
What happens if Ṣọ's servers get breached?
A breach during the seconds of active analysis would expose the emails being processed at that moment. Because nothing persists, the historical exposure is zero. There is no archive of customer email to steal because no archive exists. This is structurally different from breaches at vendors who retain email for analysis and training.
What happens if law enforcement subpoenas Ṣọ for customer email?
We can produce nothing because we retain nothing. Subpoenas for current customer email content would arrive at Ṣọ during the seconds of processing only, and our infrastructure is not configured to intercept that processing. This is different from vendors who maintain customer email archives and can produce full mailbox histories under subpoena.
Are customer emails used to train Ṣọ's models?
No. Our models are trained on public corpora, synthesized data, and our own controlled test environments. Customer email content is never used for training, anonymized or otherwise.
Will my data be deleted if I stop using Ṣọ?
The deletion feature is on our product roadmap and not yet live in the app. Today, customers who stop using Ṣọ can uninstall the extension and apps. Subscription and authentication records exist on Ṣọ infrastructure as long as the subscription is active. We will update our documentation when the user-initiated deletion feature ships.
Executive Summary: TL;DR
Ṣọ Mail processes email on Ṣọ-owned servers, in seconds, and never writes the content to persistent storage. No logs of email content or headers exist on Ṣọ infrastructure. No human at Ṣọ has a tool to read customer email. Customer emails are never used to train Ṣọ models. Revenue is subscription-only. Email is encrypted in transit using HTTPS/TLS.
This architecture is structurally different from legacy email security vendors who retain customer email for extended periods, employ analyst teams with access to customer mail, train models on customer data, and license derived threat intelligence. The Ṣọ tradeoff is slightly slower adaptation to novel threats and no human escalation path, in exchange for zero retention, no human access, and no commercial relationship between your email content and the tool that protects it.
The 5 commitments that shape every product decision are: Encrypted Server Processing, Zero Server Retention, No Human Access, Minimal Account Footprint, and No Data Monetization. Each one addresses a specific failure mode that email security vendors have historically hit.
If your inbox contains client work, donor records, legal drafts, health information, or anything else where you would be uncomfortable with a vendor retaining or training on it, those five commitments are why Ṣọ exists.
Sources: Verizon 2024 Data Breach Investigations Report; FBI Internet Crime Complaint Center 2024 Annual Report; CISA Account Compromise Advisory 2026; NIST Special Publication 800-63B; Proofpoint Q1 2026 Threat Landscape Review.
iOS: apps.apple.com/us/app/so-mail/id6756896070 Android: play.google.com/store/apps/details?id=com.app.somail
Built for your privacy. Ṣọ never retains your email.