Home/Security
Security & encryptionMost "secure email" means the provider encrypts your mailbox with a key the provider also holds. That defends against a stolen hard drive and nothing else. This page describes what inbox.my does instead, precisely enough that you can judge it.
Real security has trade-offs. A provider that lists only benefits is describing a brochure, not a system.
Your passphrase is stretched into a 256-bit master key with Argon2id — memory-hard, GPU-resistant, with parameters recorded per account so they can be raised over time. This happens in your browser. The passphrase and the master key never cross the network in any form.
The cost: we cannot reset it for you. Ever.
Each message, attachment and file is sealed with a unique AES-256-GCM data key, which is then wrapped by your master key and stored alongside the ciphertext. One compromised object cannot cascade, and GCM's authentication tag means tampering is detected rather than silently decrypted.
The cost: server-side full-text search of message bodies is impossible.
Delete an object and its wrapped data key is destroyed before the ciphertext is dropped. Even if a copy of the bytes survives somewhere — a backup, an unoverwritten block — it is mathematically unreadable. This is crypto-shredding, and it is the only form of deletion that means anything on modern storage.
The cost: there is no undelete. Deleted is deleted.
Authentication uses a verifier derived from your passphrase — enough to prove you know it, never enough to reconstruct it. Combined with per-object keys, the practical result is that a full database dump yields ciphertext, key wrappers nobody can unwrap, and timestamps.
The cost: metadata — sizes and timing — still exists. See below.
This is where most providers get vague, so here it is in three flat statements.
No provider can end-to-end encrypt a message to a recipient who has no key. If a service implies your mail to any Gmail address is E2E encrypted, it is describing a link to a web page hosted on their servers, not encrypted email. We support PGP because it is the honest version of that feature.
This is the question that catches most encrypted-mail providers out, so it is worth stating the answer directly: filtering runs before the encryption boundary, not after it.
Inbound mail is scored by Rspamd at the gateway, in memory, at the moment it arrives — DNS blocklists, SPF and DKIM results, Bayesian scoring, URL reputation. Only mail that passes is then sealed to your key and written to disk. Nothing ever scans ciphertext at rest, because nothing can.
The consequence, stated plainly: for the few hundred milliseconds a message is being scored at the gateway, it exists in memory in the clear. That is unavoidable for any provider that filters spam at all. What matters is that it is never written in the clear and never leaves that process readable.
Four things we would rather you learn here than discover later.
We necessarily know that a message arrived, roughly how large it was and when. Envelope routing data is how email works at all. Content is sealed; the fact of delivery is not.
Once a message reaches a recipient without PGP, it lives on their provider's servers under their provider's rules. Your encryption protects your copy and the wire, not their mailbox.
Encryption assumes the machine doing the decrypting is yours. Malware, a keylogger or someone with your unlocked laptop defeats every design on this page. Keep the endpoint clean.
Argon2id makes guessing expensive, not impossible. A short or reused passphrase is the weakest link in the whole system. Use a long one from a password manager, and write it down somewhere physical.
If you lose your passphrase, the mail is unreadable — to you, to us, to anyone. There is no master key and no escrow, because either one would mean we could read your mail and therefore could be compelled to. Recovery wipes the mailbox and reprovisions a fresh keyspace so you keep the address you paid for. The mail itself is gone.
TLS 1.3 for web and IMAP/SMTP, HSTS with preload, MTA-STS in enforce mode and DANE where the receiving domain publishes TLSA records. Opportunistic TLS is accepted for inbound from senders who offer nothing better, because rejecting them would just lose your mail.
Web and proxy access logs are dropped rather than written. Mail queue state exists transiently while a message is in flight, because it has to. We publish this as a posture, not a marketing absolute — no service can promise zero retention when local law can compel otherwise.
An outbound gate scores every message leaving the platform. A mailbox that starts sending bulk or phishing is suspended automatically, and a listed sending IP triggers suspension plus a delisting request — never a silent hop to a fresh IP. Acceptable use →
That the server never holds a key capable of decrypting your content. Your passphrase becomes a master key inside your browser via Argon2id and is never transmitted. Each message and file gets its own AES-256-GCM data key, wrapped by that master key. We store the sealed envelope plus a verifier that proves you know the passphrase without revealing it.
Only if you have imported that person's PGP public key. Without one it is TLS-encrypted in transit and then readable on Google's servers, because Google holds their keys. No provider can change this. Anyone claiming otherwise is describing a link to a web page on their own servers, which is a different thing.
Filtering happens before encryption, at the gateway, in memory — DNS blocklists, SPF and DKIM results, Bayesian scoring and URL reputation, all at the moment the message arrives. Only then is it sealed to your key and written to disk. Nothing scans ciphertext at rest, because nothing can.
The mail becomes permanently unreadable, including to us. No master key, no escrow, no backdoor — that is zero-knowledge followed to its conclusion. Recovery wipes the mailbox and provisions a fresh keyspace so you keep the address. Store the passphrase somewhere physical, today.
Destroys that object's wrapped data key, then drops the ciphertext. Because every object has its own key, destroying the key renders the remaining bytes unreadable even if a copy survives in a backup or on a block that has not been overwritten yet. That is crypto-shredding, and it is the only deletion that means anything on modern storage.
We would hand over what we hold, because that is what the law requires. What we hold is ciphertext, key wrappers nobody can unwrap without your passphrase, and metadata such as timestamps and message sizes. The architecture is the protection — not a promise about how we would behave under pressure, which is worth nothing.
Not yet, and we will say so until it has. Treat every unaudited security claim — ours included — with the scepticism it deserves. What we can offer today is a precise description of the design, which is what this page is, so you can evaluate it on its merits rather than on our word.
Everything on this page ships with every plan. There is no "security tier".
$99 / year or $599 for life · Crypto only · All sales final · No phone number, no KYC