posted by VaelMail · 11 October 2026
what private email protects, and what it doesn’t.
fewer signup details, encrypted storage and careful message handling each do a different job. here are vaelmail’s limits in plain language.
“private email” can mean several different things. it might describe the details needed to open an account, how messages are stored, what loads when you read them, or who can see a message in transit.
those are separate questions. a useful choice starts with the thing you want to protect, rather than treating the word private as a promise about everything.
the details you give at signup.
vael doesn’t ask for a name, recovery email, phone number or identity documents to create an account. you choose an address and sign in with a secret 16-digit account number.
that reduces the personal details required to register. it also means a lost account number cannot be recovered through a reset email. a passkey, authenticator app or recovery code does not replace it. our signup guide explains how to prepare a safe copy.
mail stored on the server.
vael’s mail-storage volumes and rolling backups are encrypted. this helps protect stored data in the circumstances those layers cover.
the running server and its operator can read ordinary mail and metadata. keys are server-managed. this is not end-to-end or zero-access encryption, and encrypted storage does not prevent access by someone who controls the running server.
if you need content that an email provider cannot read, vael’s ordinary mailbox alone does not provide that property. using another encryption tool would require a separate setup and agreement with the people receiving your mail.
connections and other providers.
website and authenticated mail-app connections require tls. server-to-server mail uses tls when the other provider supports it. encrypted connections and encrypted storage solve different parts of the problem; neither changes what the recipient can do with the delivered message.
cloudflare proxies the regular website and terminates website tls. native imap and smtp connections go directly to vael’s server. tor and i2p mirrors use their networks rather than the cloudflare website proxy. infrastructure and payment providers have their own roles, described in the privacy policy.
reading a message.
message-body remote images stay blocked until you allow them. approved pictures load through vael, but their host can still observe the fetch and a unique image address can identify a recipient’s copy.
links and attachments have separate risks. blocking a tracking pixel doesn’t remove a tracking identifier from a link or stop a file from being handled by another program. see email tracking and remote images for the practical settings.
addresses and people you write to.
aliases let you give different services different receiving addresses. that can help you manage unwanted mail without sharing one address everywhere. it does not hide a purchase, a browser session or personal details you include in a message.
aliases and custom domains are receive-only. sending uses your main address and requires plus. recipients can keep, forward or quote what they receive, regardless of how carefully you connected to vael.
choose with the limits visible.
keep your account number private, add a second factor, choose addresses deliberately and decide when remote content is worth loading. those are concrete steps you can control.
for the technical record behind this overview, read what we store and how the system works. the point is to know which protection you’re using and where its job ends.