Rootshell is a newly launched email service that markets itself as end-to-end encrypted and hosted in Iceland. That framing drew immediate scrutiny because normal email is only truly end-to-end encrypted when both sender and recipient use a compatible encryption scheme such as PGP or GPG. If a Gmail user sends mail to a Rootshell inbox, Rootshell receives that message in plaintext unless something extra happens above standard email. Several people tested the product and came away thinking the E2EE claim is at best incomplete and at worst wrong. One person says the app returns decrypted mail from the server, which would mean the server can read message contents. Others pointed out that new-user setup was already failing with errors like “key bundle missing,” which is the kind of friction that kills trust before a security product even gets to its security claims.
If you sell security infrastructure, vague crypto marketing and rough onboarding will get dissected immediately, and trust will hinge more on architecture clarity and operational maturity than on jurisdiction or branding.
Strongly skeptical. People were turned off by the mismatch between the E2EE marketing and how email actually works, plus early signs of weak implementation, broken signup flow, unclear operator identity, and missing operational safeguards expected from any serious mail provider.
01 Security audits are only useful if the scope was brutal enough to test the actual trust boundary.
A recognizable firm name is not a seal of approval, and for an email service claiming end-to-end encryption the work needed to verify the architecture is extremely expensive. That shifts the bar from “did someone audit it” to “what exactly was reviewed, by whom, and how deep did they go.”
Audit branding is weak evidence. Scope and reviewer quality are what count, especially for crypto products.
02 Letting users register addresses like abuse@ on the service’s own domain is a serious operational mistake.
Those mailboxes are expected by RFCs, abuse workflows, and certificate-validation systems. Blocking a short denylist helps, but the cleaner pattern is to separate official service communication onto a different domain so user addresses cannot collide with trusted administrative roles.
Mail providers need mailbox policy, not just mailbox creation. Trusted role accounts should never be user-claimable on the primary service domain.
03 Rootshell did one thing right by blocking common email tracking behavior through a strict Content Security Policy, but the rest of the mail stack showed rough edges fast.
HSTS preload was misconfigured, DANE was reported broken, MX TLS allowed anonymous ciphers, and even image loading behaved oddly under the site’s own restrictions. That combination reads like a project that knows some web security basics but is not yet operating at email-infrastructure grade.
Security features do not add up automatically. A few good headers cannot compensate for weak mail transport and DNS hygiene.
04 The signup flow already undermines the core promise.
Errors like “key bundle missing” and repeated registration failures are not minor UX polish issues in a security product. When the user cannot tell whether the failure is expected, recoverable, or dangerous, they stop trusting both the software and the cryptography behind it.
In security products, bad onboarding is a trust failure. Users read opaque errors as evidence the system itself may be unsound.
01 A few people were simply happy to see a small independent email provider launch at all.
The appeal is less the specific crypto claim and more the existence of alternatives outside large corporate mail platforms.
There is still demand for non-Big Tech email, even before the product is fully mature.
02 The criticism of Iceland as a hosting location was called out as backward.
A jurisdiction that tolerates controversial customers can also be read as one that is less eager to remove or police hosted services on demand.
Loose enforcement is not automatically a bug. For some users, it is part of the value proposition.