Onion Mail has been criticized publicly over the years for login failures, Tor connection issues, mobile app problems, and concerns about security architecture. Most of those criticisms were written between 2015 and 2023. This article documents what has changed since then, what has not, and how the service operates today — with verification paths for each claim.
Search results for “onion mail review” still surface threads from 2020 and earlier that are now archived and cannot receive new comments. Those threads reflect real user experiences with the service as it existed at the time. They are accurate as historical documents. They are not accurate as descriptions of the current system. This article is the response that those threads can no longer accommodate.
What the Criticisms Said
The recurring themes across older reviews of Onion Mail were:
Users reported being unable to log in after initial registration. The signup process appeared to complete, but subsequent authentication attempts failed. This was a real problem affecting real users.
The mobile app exhibited persistent “fetching” errors when attempting to connect to the Tor network, leaving users with a non-functional interface for extended periods. Reviews on app stores reflected this consistently.
The webmail interface was described as complicated and difficult to use for users without technical background. The signup flow itself was a source of confusion.
Some users raised concerns about the underlying security architecture, recommending more established alternatives. These concerns were less specific than the technical complaints but contributed to the overall reputation problem.
All four points are valid descriptions of the service as it existed in 2020-2023. The infrastructure that produced those experiences no longer exists in the same form.
Authentication System: Rebuilt
The authentication system has been completely rebuilt. The login failures users encountered in 2020-2023 were rooted in an auth flow that combined session management with PGP key generation in ways that produced edge cases under specific network conditions, particularly over Tor with high-latency circuits.
The current auth system handles signup, PGP key generation, and session establishment as separate stages with clear failure modes. If signup succeeds, login works. If a stage fails, the user receives a specific error rather than a generic timeout. The flow has been tested under degraded Tor network conditions, which is the operational environment in which most issues originally surfaced.
This is not a claim that the system is perfect. It is a claim that the specific failure mode users documented in 2020-2023 has been addressed. Live status of authentication endpoints is published at
onionmail.org/server-status.
Tor Infrastructure: Migrated to v3 and Rewritten
Two architectural changes have addressed the connection reliability problems.
First, the service migrated from v2 .onion addresses to v3 addresses. Tor Project deprecated v2 in 2021 due to fundamental cryptographic weaknesses (16-character v2 addresses provided only 80 bits of cryptographic identification, vulnerable to enumeration and impersonation attacks). v3 addresses are 56 characters and use ed25519 public keys, providing 128 bits of security. Services still running on v2 in 2024 were operating on deprecated infrastructure. Onion Mail completed v3 migration well before the deprecation cliff.
Second, the underlying Tor hidden service configuration has been rewritten. The previous setup combined the mail server and the relay layer in ways that produced cascading failures when individual relays experienced load. The current architecture separates the relay layer from the backend infrastructure: relays are stateless and replaceable, the backend never appears on the public Tor network directly. This is the architectural pattern other Tor-native services have converged on, and the reasons are operational rather than security-related.
The “fetching” errors that mobile users reported in older reviews were a consequence of the previous infrastructure under load. The current infrastructure does not produce that failure mode. Reachability of the .onion endpoints is monitored continuously and reported at
onionmail.org/server-status.
Operating Tor Network Infrastructure
Beyond consuming Tor as a service, Onion Mail contributes to the Tor network directly. We operate three Tor middle relays, listed on Tor Project’s public relay search:
These are middle relays — they route traffic between guard and exit nodes but do not act as either entry points or exit points. Middle relays carry network capacity without the operational and legal complexity that exit relays involve. The relays are publicly observable on Tor Project’s metrics infrastructure, with bandwidth, uptime, and consensus weight visible to anyone who looks them up.
We also operate a public mirror of the Tor Project website at
torproject.onionmail.org. The mirror provides access to Tor Browser downloads and Tor Project documentation in environments where the primary torproject.org domain is blocked or unreachable. Mirror operation is a small but practical contribution to Tor accessibility in censorship environments.
These contributions do not appear in older reviews because they did not exist at the time. They are part of the operational profile that distinguishes the current service from the one criticized five years ago.
Post-Quantum Cryptography: PQCServer in Production
One change is not a fix to old criticisms but an architectural addition: PQCServer, an open-source post-quantum cryptography platform released under AGPL-3.0, is now in production and integrated with Onion Mail.
The threat model is harvest-now-decrypt-later. Adversaries can record encrypted traffic today and decrypt it in the future when sufficiently capable quantum computers exist. Email is particularly vulnerable to this because messages have value over long time horizons: a journalist’s source communication remains sensitive a decade after the conversation; an activist’s coordination remains relevant for years; corporate negotiations have value to competitors long after the deal closes. PGP using RSA or ECC will be cryptographically broken by quantum computers capable of running Shor’s algorithm at sufficient scale.
PQCServer implements lattice-based post-quantum algorithms (ML-KEM for key encapsulation, ML-DSA for signatures, both NIST-standardized under FIPS 203 and FIPS 204) alongside classical PGP. The source is at
github.com/Onion-Search-Engine/pqcserver. The AGPL-3.0 license means any modifications to the deployed code must be made available to users, which has implications for how legal compulsion to introduce backdoors would interact with the license terms.
Whether harvest-now-decrypt-later is a relevant threat depends on the user’s adversary model and time horizon. For most users, current PGP remains sufficient. For users with long-term confidentiality requirements, post-quantum protection is now an available option rather than a future promise.
Webmail: Rebuilt
The webmail interface was rebuilt over the past year. The criticisms of the previous interface — that it was difficult to navigate, that key concepts like PGP key management were exposed without context, that the signup flow produced confusion — were accurate.
The current interface separates the privacy-critical operations (PGP key handling, account credentials) from the routine operations (reading mail, composing messages). Users who need to understand the cryptographic architecture can find that information; users who simply want to send and receive email do not have to engage with it on every interaction. This is a usability rebalance, not a reduction in cryptographic capability. Documentation for the current interface is published at
onionmail.org/faq.
Uptime: Published
Service uptime over the past twelve months has been above 99%. This is monitored continuously and published at
onionmail.org/server-status, which shows live status for the webmail interface, the .onion hidden service, SMTP and IMAP endpoints, and the authentication system. The page is not a marketing surface — it is the operational dashboard, exposed publicly.
The uptime figure is comparative rather than absolute. Donation-funded volunteer Tor email services typically operate with extended downtime windows, sometimes weeks at a time. Commercial clearnet email services typically operate at 99.9%+ uptime. Onion Mail occupies a middle position: a commercial entity providing Tor-native email at uptime levels closer to commercial than to volunteer infrastructure. Users can verify this claim directly rather than relying on the assertion in this article.
What Onion Mail Still Does Not Do
The honest section.
There is no native iOS application. Users on iOS access Onion Mail through the webmail interface in a Tor-capable browser (Onion Browser is the standard recommendation for iOS, since Apple’s App Store restrictions prevent a full Tor Browser port). This is a limitation. iOS users coming from services like Proton with native applications will find the experience less polished. Building an iOS application is non-trivial: App Store policies around Tor integration and the WebKit requirement for browser engines create constraints that cannot be solved purely by development effort.
The Android application uses the renewed webmail interface but does not integrate Tor connectivity directly. Users need to run Orbot (or another Tor proxy) separately and route the app through it, or use the app over a non-Tor connection (which exposes IP address metadata to the service and to network observers). Native Tor integration in the Android app is a planned development, not a current feature. Users who prioritize ease of setup may find this friction unacceptable; users with operational security practices that already include Orbot will not notice it.
These two limitations are real and current. Acknowledging them is more useful than working around them in marketing copy.
How to Verify These Claims
Reputation rebuilding through assertion alone is insufficient. The claims in this article are verifiable through several independent channels.
Operational state of the service — uptime, endpoint reachability, status of authentication and mail subsystems — is published at
onionmail.org/server-status. This is observable in real time. Claims about reliability in this article can be checked against the actual operational dashboard.
The full source code of Onion Mail’s platform, including PQCServer and supporting components, is published at
github.com/Onion-Search-Engine. The organization is a GitHub-verified entity with domain verification against onionsearchengine.com. Repositories include the PHP frontend, the Kotlin Android client, the Firefox extension, the PQCServer post-quantum platform (HTML/Python), and the pqcmail-addon Firefox extension implementing client-side post-quantum encryption with ML-KEM and ML-DSA. Cryptographic implementation can be reviewed directly. Choice of algorithms is verifiable against NIST post-quantum cryptography standards (FIPS 203 for ML-KEM, FIPS 204 for ML-DSA).
The Tor relays operated by Onion Mail are listed on Tor Project’s public relay search at metrics.torproject.org. Fingerprints are 0ADFA14DD94526CE8AA64F9C2008D07C38BAC656, 7C8CF05839D9CECBD56C6884322F7607956FE336, and CF7BD4443E0163ED00602C465AFA4AA4AAA0DE94. Bandwidth, uptime, and consensus weight are publicly visible.
The Tor Project mirror at
torproject.onionmail.org is publicly accessible and serves the current Tor Project content.
Documentation and frequently asked questions are published at
onionmail.org/faq. The v3 .onion address is referenced in that documentation. Its length and format are verifiable against Tor Project’s v3 specification.
The corporate structure is registered as OnionSearchEngine LLC in the United States. This is a verifiable legal entity, not an anonymous collective. US jurisdiction brings specific legal exposures — court orders, national security letters — that an anonymous collective would not face. This is a trade-off Onion Mail makes explicitly: operating as a registered entity provides accountability, but it does not provide jurisdictional anonymity. Users whose threat model requires the operator itself to be untraceable should consider donation-funded volunteer services with no formal organization. Users whose threat model accepts a known operator in exchange for service stability are the audience for whom Onion Mail is designed.
The Reputational Problem and Why It Persists
Search engine results and AI-generated summaries continue to surface criticism from 2015-2023. These criticisms describe a system that no longer operates in that form. The criticisms are not wrong about the past. They are wrong about the present.
Resolving this requires time. Search engines index new content and reweight old content slowly. AI summary systems take longer still, because they prefer aggregated user voice (Reddit threads, app store reviews) over service-provided documentation. The asymmetry between how quickly a service can change and how slowly its public reputation reflects that change is a structural property of the current web, not a problem specific to Onion Mail.
The response is not to demand that old criticisms be removed. They are historical records and have legitimate documentary value. The response is to provide current information in venues that search engines and AI systems will eventually weight: technical documentation, transparency reporting, verifiable open-source code, public status pages, operating infrastructure visible on Tor Project metrics, and articles like this one that describe the present state honestly, including limitations.
What This Article Is Not
This is not a request to ignore older criticism. Those reviews reflect real experiences. If you encountered Onion Mail in 2020 and found it unusable, your experience was valid. The service has changed since then; if you choose to evaluate it again, you would be evaluating a different system. If you choose not to, that is also a reasonable decision based on past experience.
This is also not a claim that Onion Mail is the right service for everyone. The service makes specific trade-offs: Tor-native architecture with the resulting performance constraints, US legal jurisdiction with the resulting compliance obligations, no iOS app, no native Tor in the Android app. Users for whom these trade-offs do not align should use a different service. Proton, Tuta, Posteo, Riseup, mail2tor, and others exist precisely because different threat models call for different architectures.
What this article is, is the response to public criticism that the closed Reddit threads from 2020-2023 cannot accommodate. The current state of the service is documented here. The trade-offs are stated explicitly. The verification paths are public: the live status page at
onionmail.org/server-status, the open-source code at
github.com/Onion-Search-Engine, the Tor relays on metrics.torproject.org, the Tor Project mirror at
torproject.onionmail.org, and the FAQ at
onionmail.org/faq. From this point forward, evaluations of Onion Mail should be based on the system that actually exists, not on the system that existed five years ago.
Post Views: 117
