Spark Mail Privacy: What Actually Happens to Your Email

I want to be upfront: I run a competing product. Take everything here with that context. But the facts in this post are sourced from Spark's own documentation, privacy policy, and public statements. I am not speculating about what they do; I am reading what they say they do.

How Spark processes your email

Spark's collaboration features (shared drafts, email comments, team assignments, shared inboxes) require server-side processing. When you use Spark, your email passes through Readdle's servers. This is not a bug or a secret. It is a technical requirement of real-time collaboration. You cannot enable multiple people to comment on the same email thread without a central server coordinating that state.

Beyond collaboration, Spark's AI features (Smart Inbox categorisation, email summaries, writing assistance) also process your email content server-side. AI inference at this level cannot run locally on a phone or browser. Your email content is sent to external infrastructure for processing.

Spark's Smart Inbox, which automatically sorts your email into categories like Personal, Notifications, and Newsletters, requires Readdle's servers to read and classify your incoming messages. This classification happens before you see the email. It is not optional if you use the Smart Inbox feature.

What their privacy policy permits

Readdle's privacy policy states that they collect and process email metadata (sender, recipient, subject, timestamps) and email content as needed to provide their services. The policy covers data retention, third-party sharing for service operation, and analytics.

Privacy policies can change. Readdle has updated theirs in the past, and any future update could expand the scope of data processing. When you use a service that processes your email server-side, you are trusting not just the current policy but every future version of it.

This is not unique to Spark. Any email client that offers server-side features (AI, collaboration, smart sorting) faces the same structural reality. The question is whether you need those features enough to accept the data processing they require.

The history of concerns

Spark has faced public criticism over privacy practices before. Early versions of the app were criticised for storing user email credentials on Readdle's servers, which is necessary for background sync and push notifications but alarmed security-conscious users. The company has responded to these concerns over time and tightened their practices, but the fundamental architecture (email routed through third-party servers) has not changed because it cannot change without removing the features that define the product.

In fairness, Spark is transparent about this. They explain the architecture in their documentation. The concern is not that they are hiding something. The concern is that many users do not read the documentation and do not realise that their email is being processed server-side when they install what appears to be a simple email client.

What the alternatives look like

Not every email client processes your email on third-party servers. There are broadly three architectures:

1. Server-dependent clients: your email is processed on the client company's servers for features like AI, collaboration, or smart sorting. Spark, Superhuman, and Edison Mail fall into this category.
2. Infrastructure-only backends: your email passes through the client's servers for sync, indexing, and push notifications, but is not scanned for AI features, ad targeting, or smart sorting. Marco uses this approach. Thunderbird goes further and has no backend at all.
3. Provider-native clients: you use the client built by your email provider (Gmail web, Apple Mail, Outlook). Your email stays within the provider's infrastructure but does not pass through additional third parties.

Each approach has tradeoffs. Server-dependent clients can offer richer features. Local-first clients offer stronger privacy guarantees. Provider-native clients avoid third parties but lock you into one ecosystem.

What to consider before choosing

• Do you use Spark's team features? If yes, the server-side processing is the cost of those features. Evaluate whether the collaboration value outweighs the privacy cost.
• Do you use Smart Inbox? If you rely on automatic categorisation, your email content is being classified server-side. Decide if that tradeoff is acceptable.
• Do you use Spark's AI features? If yes, your email content is sent to AI infrastructure for processing. The same applies to any AI-powered email feature in any client.
• Are you a solo user who just wants a fast, clean email client? If so, you may be paying a privacy cost for team features you do not use.

Where Marco differs

Marco's backend handles IMAP sync, search indexing, and push notifications. Your email passes through our servers for these infrastructure purposes, but we do not scan it for AI features, ad targeting, smart sorting, or anything beyond making the product work. There is no AI categorisation, no smart inbox, no content monetisation.

The tradeoff is that Marco does not offer the collaboration features that Spark does. If you need shared inboxes and team comments, Marco is not the right tool. If you want a fast, private, individual email client, it is.

For a full feature comparison, see Marco vs Spark. For a broader look at what free email costs, read The Real Cost of Free Email Apps. For protocol-level context, read Email Is Not Broken.