Email is not secure.

It never was.

The problem is not that people don’t know this. The problem is that companies pretend it isn’t true.

Privacy is becoming mainstream, which is good in my opinion. But like anything that can be monetized, it gets turned into a product.

I keep seeing the same message:

• This email service is more secure.
• That one is not safe enough.

Different branding, same idea.

Most “privacy-focused” email services rely on a simple model:

• Convince the user they are at risk
• Sell them a subscription as the solution

Not control. Not actual security. Just fear, packaged neatly.

Fear that your data is exposed. Fear that your messages are being read. Fear that you are not safe unless you pay.

To be clear, some services are better than others. But better does not mean secure.

The real problem is that these solutions don’t fix the core issue, because they can’t.

Email was never built for security.

It was built-in 1982 to move messages between academic institutions. Security wasn’t ignored—it simply wasn’t a concern as, there was no threat model nor the expectation of privacy.

The core protocol, SMTP (Simple Mail Transfer Protocol, Note: The S stands for Simple not Secure), does one thing: deliver mail.

Everything people now call “security” was added later:

• TLS for transport
• PGP for content

None of this is enforced.

Email prioritizes compatibility over security.

If encryption is supported on both the senders and the receivers servers, it might be used. If it isn’t, the system quietly falls back.

Your message still gets delivered. Just without the promised protection.

Sometimes, that means it is sent in plaintext across the network.

This is a limitation of the protocol itself, not the provider.

You can look up the following terms if you want to dig deeper or, if you want to verify what I said:

• RFC 821 / SMTP
• RFC 5321 (updated SMTP)
• How TLS works in email (STARTTLS)
• OpenPGP overview

---

Email is not a direct conversation. It is a relay:

You → your server → their server → them.

The message has to be readable at every step. That is how email works.

TLS only protects the transport. It does not protect the content. Once the message reaches a server, it is decrypted and handled in plain form.

From there, it can be stored, scanned, logged, or exposed. You do not get a vote.

People say, “I sent an email to someone.” What they really did was trust a chain of servers with their message.

Without PGP, that is exactly what you are doing.

If you don’t control the encryption, you don’t control who can read it.

---

The Limits of “Secure Email” Providers

Most of what these companies sell isn’t security. It’s positioning.

They lean hard on buzzwords:

• Zero-knowledge, zero-access, end-to-end
• Client-side encryption, perfect forward secrecy
• “Zero-trust,” secure enclaves
• Encrypted at rest / in transit
• No logs, anonymous sign up, “privacy-friendly jurisdiction”

It sounds airtight right?. It isn’t. Fool! Because people blur important differences:

• Zero-knowledge ≠ end-to-end encryption
• “Encrypted email” ≠ encrypted for everyone (external mail often downgrades)

What Actually Improves

To be fair, they do make things better:

• Stronger defaults (TLS, storage encryption)
• Less tracking, cleaner policies

But these are incremental fixes inside a broken model.

Email still works the same:

• Messages pass through servers
• Metadata (who, when, who to) stays exposed
• Compatibility forces fallbacks
• Providers still handle your data

And without real end-to-end encryption: they can still read your mail.

Where Marketing Slips In

The pitch:

“Switch to us and your email is secure.”

Reality:

“Switch to us and some risks shrink.”

That gap matters.

The half Measures

Even the “better” setups are partial:

• Full encryption only inside their ecosystem
• Advanced security behind paid layers or workarounds
• Control traded for convenience

So you get:

• Better defaults
• Better optics

Same system underneath.

The Bottom Line

These services aren’t useless. They’re just not what they imply.

They improve the environment. They don’t change the model.

If your security depends on the provider, it’s still their system—not yours.

---

Why Mail Clients Matter

Mail clients feel outdated.

People assume they exist for the same reason fax machines do—because some people never moved on. Why install anything when you can just open a browser and check your email from anywhere?

Convenience won. Control quietly disappeared.

The Problem with Web Mail

When you use web mail, you are not just reading email. You are running someone else’s code.

Every time you open your inbox, your provider sends JavaScript to your browser. That code decides:

• How your emails are displayed
• When they are decrypted
• What gets sent back to the server

And it can change at any time.

If the service is compromised—or just decides to push an update to screw you up—you have no visibility into what that code is doing.

It only takes one malicious script to:

• Read your messages after decryption
• Capture credentials
• Intercept outgoing mail

All before you notice anything.

What Changes with a Mail Client

A mail client flips this model.

Tools like:

• Thunderbird (Don’t use it before fully opting out of the spyware. See: Spyware Watchdog)
• Neomutt
• Claws Mail

Run locally on your machine.

That means:

• Your interface is not changing every time you refresh a page
• You are not executing untrusted JavaScript from a remote server
• Your emails can be downloaded and stored locally

You can even remove messages from the server entirely.

Now your inbox isn’t something you access. It’s something you have.

Local Storage Changes the Risk

With web mail:

Your entire history sits on someone else’s server

With a mail client:

Your data lives with you

That alone removes a huge amount of risk:

• Server breaches matter less
• Account lockouts matter less
• Provider policy changes matter less

You are no longer fully dependent on a single service.

Where PGP Actually Becomes Practical

Mail clients also make proper encryption usable.

Instead of trusting the provider:

• Keys are generated locally
• Encryption happens before sending
• Decryption happens on your machine

The provider only ever sees encrypted data.

This is fundamentally different from “we encrypt your email” claims.

---

Why the Provider Doesn’t Matter as Much as You Think

People obsess over which email service to use.

That’s the wrong question.

Most of the real problems with email are not solved at the provider level.

So instead of asking:

“Which email service is the most secure?”

Ask, youself:

“What control do I actually have?”

What Actually Matters

If you’re choosing an email provider, these matter far more:

1. Mail Client Support

If you can’t use your own client, you don’t control your email.

You are forced into:

• Their interface
• Their limitations
• Their security model

That alone should be a deal breaker.

2. A Clear Privacy Policy

Not “we respect your privacy”.

Actual clarity:

• What they log
• What they store
• What they can access

If you need marketing language to understand it, it’s probably not honest.

3. A Track Record of Not Lying

This is the most important one.

Has the provider:

• Misled users before?
• Walked back claims?
• Hidden important details?

Once trust is broken, No amount of encryption claims can fix the stains.

Why I Choose Cock.Li?

I didn’t choose cock.li because it’s perfect.

I chose it because it aligns with how I think about email:

• Assume it’s not private
• Don’t trust marketing
• Keep control where possible

If another provider meets those conditions better for you, use that instead.

In future I’ll probably just rent my own server and host my own email on it, at least then I get let go of all the worries about email. At least on my side.

The Problem Isn’t Which Email Service You Use

You are not choosing a secure email service.
You are choosing who you trust with your data.

Email itself was never private.

Once you accept that,
Everything else is obvious.