Somewhere in your Slack workspace there is a direct message you’d rather your employer never read. Maybe it’s a complaint about a manager, maybe it’s a job you were half-considering, maybe it’s nothing worse than a joke that reads badly out of context. You typed it into a little box labeled Direct Message, and the word “direct” did a lot of quiet work convincing you it was private.
It wasn’t. On Slack’s Enterprise Grid tier, an organization owner can run an export — through Slack’s Discovery API or a corporate export — that pulls every message from every public channel, every private channel, and every direct message across the whole organization. It includes edits. It includes deletions. The thing you thought better of and took back is sitting in an export archive, because the export sees the audit trail, not the tidied-up version you left behind in the client. Slack sells this as a compliance feature, which it is. It is also a plain description of who can read your “private” messages: not just you and the person you sent them to, but anyone with the org-owner keys and a reason.
I bring this up because the reflexive ranking is exactly backwards. Ask a room of engineers which is more secure, email or Slack, and most will pick Slack without thinking. Slack is new. Slack has a padlock in the marketing. Email is the creaky thing that spam comes in on. But “more secure” is a question about a threat model, and once you actually name the threat, the ranking flips for the threats that tend to matter most.
What email is genuinely terrible at
Let me concede everything up front, because I’ve written before about how email is unfixable at the protocol level and I’m not going to pretend otherwise.
Email’s transport security is a monument to good intentions bolted onto a protocol from 1982. The From: line is a suggestion, not a fact — spoofing it is specified behavior, not an exploit. Encryption between mail servers is opportunistic: STARTTLS upgrades a connection to TLS if it can, and silently falls back to cleartext if a network attacker simply strips the offer. Your provider — Google, Microsoft, whoever — reads your mail to index it, filter it, and increasingly to feed it to features you didn’t ask for. As a system for stopping a determined attacker from reading a message in flight, default email is a screen door.
So if your threat model is “a stranger on the wire intercepts one message,” Slack, which runs everything over TLS to a single well-run backend, genuinely wins. I’m not going to argue that away.
But that’s a narrow threat, and it’s not the one most people are actually exposed to.
The threat is custody, not the wire
The interesting question is not who can grab a message in transit. It’s who holds your messages at rest, who can read them, who can hand them over, and whether you can ever get away from them. Call it custody. On custody, the two systems aren’t close.
Slack is a silo with exactly one landlord. Every message lives on infrastructure owned by Slack, which is owned by Salesforce. By default, Slack holds your content in a form it can read — it has to, to search it, render link previews, run its AI features. Your workspace’s retention policy is set by your admins, not you; if they keep everything forever, everything is kept forever, and if they delete it, you can’t stop that either. There is one company to subpoena, one company to breach, one company whose internal access controls stand between a curious employee and your DMs. Slack offers Enterprise Key Management so a customer can bring their own encryption keys — but that’s an enterprise add-on that puts the keys in the hands of your organization, not you, and Slack still processes your messages in plaintext to make the product work. EKM changes who can lock you out. It does not make your DMs unreadable to your own org. Nothing in Slack does.
Now hold email up against that same set of questions, and notice how different the answers are — not because email is well-designed, but because it’s decentralized.
There is no single landlord. Email is federated: RFC 5321 describes a system where any server can hand a message to any other server, and the address you@yourdomain.com can be served by Google today and your own machine in a rack tomorrow, with the same address, because the address belongs to a domain you control rather than to a platform. If you don’t trust your provider, you can leave, and take your identity with you. Try changing which company hosts your Slack.
You can self-host it. Running your own mail server is a genuine pain — I won’t pretend otherwise — but it is possible, and millions of domains do it. The messages then sit on hardware you own, under your own access controls, subpoenable only through you. There is no equivalent for Slack. You cannot run your own Slack. The custody of your conversations is not a setting; it’s the whole business model.
And email has a real ceiling that Slack lacks: true end-to-end encryption exists for it, as an open standard, that even your provider cannot read. S/MIME (RFC 8551) and OpenPGP (RFC 9580, the 2024 refresh of the old PGP standard) let the sender encrypt a message to the recipient’s public key so that only the recipient’s private key can open it. Your mail provider stores and forwards ciphertext it cannot decrypt. Nobody has to add a feature for this; it’s been part of the email ecosystem for thirty years. The ceiling on email’s confidentiality is yours to raise, without asking anyone’s permission.
Why the headline is provocative and still true
The honest version of my claim is not “email is a fortress.” It’s this: email’s security ceiling is high and it belongs to you, while Slack’s ceiling is set for you by a vendor, and Slack’s floor — for the specific threat of your own organization or a single legal demand reading your private messages — is basically the ground.
The caveats are real and I’ll say them plainly. Almost nobody turns on S/MIME or PGP, because the key management is miserable and it only works when both sides bother. Even when you do encrypt the body, the headers — who you mailed, when, about what subject — travel in the clear; the standards bodies are still trying to close that gap (RFC 9788 is the latest attempt to protect email headers). E2E email is opt-in, clumsy, and rare, and the median email account at a big provider is scanned and profiled to a degree that should bother you more than it does.
But look at what those caveats are: they’re about adoption and default settings. They describe a capability that exists and mostly goes unused. Slack’s problem is not a default you can change or a feature you can enable. It’s structural. There is no configuration of Slack in which your direct messages become unreadable to the company that hosts them and the org that pays for them, because a hosted, searchable, admin-exportable silo is the product you’re buying. You cannot opt into sovereignty you weren’t sold.
The part that matters for how you think about “secure”
I build tools that pull apart the security posture of domains and servers, and the thing that job teaches you fastest is that secure is not a property of a technology. It’s a relationship between a system and a specific adversary. Against a spammer forging a sender, email is hopeless and any modern messenger wins. Against your own employer, a legal discovery order, an acquiring company inheriting your archives, or an insider with export rights, the federated system you can walk away from and encrypt end-to-end beats the elegant silo you can’t leave and can’t lock.
We reach for the newer, glossier system and assume the security came bundled with the design. Often it didn’t. Often what got designed in was the opposite — a central point of collection, retention, and lawful access, wrapped in an interface smooth enough that nobody asks where the messages actually live or who can read them. The old, ugly, federated protocol never promised you a smooth interface. What it accidentally gave you instead was a copy of your own conversations that nobody else has to be trusted to protect.
That’s not nothing. On the threat that’s most likely to actually reach you, it might be everything.