Encrypted in transit
TLS protects connections between your browser or mail app and Zmail, and is requested for server-to-server delivery. Email delivery still depends on the receiving or sending server supporting secure transport.
SECURITY
Security you can understand.
Layered defences for your mailbox, honest boundaries for encryption, and controls that stay out of the way.
TLS
Authenticated mail
SPF, DKIM and DMARC help receiving systems verify legitimate Zmail messages and reject domain impersonation.
Personal-use sending controls
Zmail prohibits marketing, newsletters, bulk and cold outreach. Authenticated sending is capped at 10 recipients per message, 20 sends per hour and 75 per day, with a 6-per-hour repeated-recipient cap and bounded outbound queues. Limits reduce abuse; no control can guarantee that all spam is stopped.
Protected operations
Administrative access is separate from mailbox access. Sensitive portal actions require server-verified sessions, anti-forgery checks and human verification.
Choice-aware ZMath Mail
For ready Zmail-to-Zmail recipients, webmail can encrypt the body with independent inner and outer AES-256-GCM keys, wrap the keys into opaque per-device slots with ephemeral ECDH/HKDF, and sign the envelope with the sender device. Auto, Require and Standard modes make fallback behaviour explicit.
Recoverable ZNotes at rest
ZNotes encrypts the complete note document with one AES-256-GCM key and encrypts that authenticated envelope again with a separate AES-256-GCM key before SQLite storage. The signed-in service can decrypt notes for use and version recovery, so this is encrypted at rest rather than end-to-end encryption.
Standards-based calendar and contacts
Calendar and contact data remains server-readable behind account controls and TLS. That boundary lets CalDAV and CardDAV clients synchronise, and lets the server process scheduling and deliver reminders while the browser is closed.
Private-by-choice AI Assist
Each user may add an OpenAI or Groq API key. The key is AES-256-GCM encrypted at rest and used only after an explicit AI Assist click. Only submitted compose content goes to that provider; there is no background mailbox scan and no automatic send.
Optional extra protection
ZMath Shield: two inputs, two authenticated layers.
A passphrase creates an inner AES-256-GCM layer. A separate visual pattern creates the outer layer. Each input gets its own random salt, key and 600,000-round PBKDF2-HMAC-SHA-256 derivation in your browser.
- Protect a private note, a file up to 8 MB, or both
- Export and import one portable encrypted .zmath file
- Tampering is detected before protected content opens
- No plaintext, input or derived key is sent to Zmail
••••••••••••PassphraseInner-layer input
＋
Visual patternOuter-layer input
↓
◆
AES-256-GCM × 2Independent inner and outer layers
The honest boundary
Different data. Different promises.
ZMath Mail applies only to eligible message bodies sent between ready Zmail webmail devices—not subjects, standard addressing metadata, drafts, attachments or external-provider messages. The operator receives ciphertext for those eligible protected bodies, but normal email remains server-readable and an authorised root operator could technically access it for service, security, abuse or legal operations. ZNotes uses two automatic server-side layers at rest and remains recoverable. Calendar and contacts remain server-readable. AI Assist sends only content a user explicitly submits to their selected provider.
What we protect
Portal sessions, sign-up flows, mail transport, account operations, encrypted-at-rest ZNotes and supported ZMath payloads.
What you control
Your Google account security, mail password, recovery material, connected devices and the links you open.
What no filter guarantees
No anti-spam or malware system catches every harmful message. Treat unexpected requests and attachments cautiously.
START SMALL. OWN MORE.
Explore Zmail Workspace Security without theatre.
See exactly how Mail, ZNotes and Calendar use different protection models.