The Real Cost of Free Email Apps
The cliche is a cliche because it is true
"If you are not paying for the product, you are the product." Everyone has heard it. Most people nod and continue using the free product. I want to make the economics specific enough that the tradeoff becomes concrete, not abstract.
Running an email service costs money. Servers, bandwidth, storage, engineering salaries, security infrastructure, compliance: these are real costs that someone is paying. If the user is not paying, someone else is. Understanding who that someone is, and what they get in return, is the first step to making an informed choice.
Business model 1: Advertising (Gmail)
Gmail is the dominant free email product in the world. It is funded by Google's advertising business. Google processes your email content to build an interest profile, which informs the ads you see across Google's properties.
Google officially stopped scanning email content for ad targeting in 2017. They now rely on other signals (search history, YouTube behavior, location data) to target ads. But your email is still processed by Google's systems for spam filtering, smart features (Smart Reply, Smart Compose, nudges), and integration with other Google services.
The practical cost: Google has an extremely detailed model of your purchasing behavior, travel patterns, financial commitments, and communication patterns, all derived from your email. Whether they use this directly for ad targeting or indirectly through their broader profile is a distinction that matters less than the fact that the data exists, on their servers, under their control.
Business model 2: Data monetisation (free third-party clients)
Several free email clients have been caught or credibly accused of monetising user email data. Edison Mail scanned user email to generate "market intelligence" reports sold to investment firms and brands. The data was anonymised, but the source was your inbox.
This is not an edge case. It is a business model. A free email client with no visible revenue source and VC-backed growth targets needs to monetise something. If the product is free and the company is growing, look at the privacy policy carefully. Check what data they collect, how they process it, and who they share it with.
The privacy policy is the product specification. If it permits something, assume it will eventually happen.
Business model 3: Team upsell (Spark, Notion Mail)
Some email clients offer a free tier for individual users and charge for team features. Spark's free tier is a full-featured email client. The paid tier adds team collaboration: shared inboxes, comments, assignments, shared drafts.
This model is more transparent than advertising or data monetisation. You get a usable free product, and the company monetises team adoption. The tradeoff is that the free tier still processes your email through the company's servers, since Spark's collaboration and AI features require server-side email processing regardless of your plan tier.
The cost is not financial. It is architectural. Your email passes through infrastructure you do not control, under a privacy policy that can change. See Spark Mail Privacy for the specific details.
Business model 4: Ecosystem lock-in (Apple Mail)
Apple Mail is free if you own Apple hardware. Apple does not monetise your email data directly. Their business model is hardware sales and services subscriptions.
The cost is ecosystem lock-in. Apple Mail works well with iCloud accounts on Apple devices. It works less well with non-Apple accounts, on non-Apple platforms, or when your inbox grows beyond what Apple's indexing model handles efficiently. The "free" client incentivises staying inside the Apple ecosystem, buying more Apple hardware, and using iCloud as your email provider.
This is the most benign of the four models from a privacy perspective. But it is still a model with a cost: you are trading flexibility and cross-platform capability for the appearance of "free."
What email actually costs to run
Building and running an email client is expensive. The major cost centres:
- IMAP sync infrastructure: maintaining persistent connections to mail servers, handling reconnection, processing updates. This scales linearly with active users.
- Storage: syncing and indexing email locally requires server-side infrastructure for coordination. Hosting costs are proportional to data volume.
- Engineering: email is one of the most complex software domains. Provider-specific edge cases, protocol compliance, sync reliability, cross-platform development. The engineering surface area is vast.
- Security and compliance: storing or processing email data requires serious security infrastructure. Google OAuth verification for email scopes alone requires an expensive third-party security audit.
A sustainable email client needs to cover these costs without monetising your data. The math is simple: charge users directly. At $4/month per user, Marco covers infrastructure costs, engineering costs, and grows sustainably without needing ad revenue, data sales, or enterprise upsell.
The $4/month question
Marco costs $4/month or $40/year. That is less than two months of Superhuman, less than half the annual cost of Hey, and less than most people spend on coffee in a week.
The question is not "is $4/month a lot?" It is "what does free actually cost me?" If the answer is your email content being processed for ad targeting, data monetisation, or server-side analysis, then $4/month is the cost of not paying in a different currency.
For a direct comparison of what you get for that $4/month versus free options, see Marco vs Gmail. For the broader market landscape, see 7 Best Gmail Alternatives.
How to evaluate any email client's cost
- If it is free, find the revenue model. Check the privacy policy, not the marketing page.
- If it processes email server-side for features (AI, smart sorting, collaboration), your email content is being analysed externally.
- If the privacy policy says "we may share anonymised data with partners," that means they do or will.
- If the company has VC funding and a free product with no visible revenue, the revenue is you.
For the philosophical case that email itself is not the problem, read Email Is Not Broken. For the protocol-level context on how email clients handle your data, read How IMAP Actually Works.
Author
Isaac Hinman, Co-founder, Marco
Isaac Hinman co-founded Marco and works directly on sync architecture, IMAP integrations, and offline reliability across providers.