What we do, and what we do not claim.

What we do not claim

• Not end-to-end encrypted. WaryMail must read your mail to index and display it. Content is encrypted in transit and the storage is protected, but we can technically access it, and so can your mail provider.
• No certification. We are not ISO 27001 certified and hold no SOC 2 report. If that changes we will publish the certificate, not the aspiration.
• No guaranteed delivery. We report what your provider accepted and what bounced. Whether a message lands in an inbox or a spam folder is not ours to promise.
• No uptime guarantee by default. Any availability commitment has to be written into a contract; see the terms.
• Tracking is approximate. Explained in full on the tracking page.

Your mailbox credentials

• Google and Microsoft mailboxes connect with OAuth. We never see the password.
• IMAP and SMTP credentials are encrypted at rest with the installation key and are never displayed again after you enter them; they are stripped from error reports and never written to logs.
• Connections require TLS, and the destination host is checked before every connection so a mailbox cannot be pointed at an internal address.
• Disconnecting an account removes its stored credentials and its cached content.

Isolation between workspaces

A workspace is the security boundary. The scope is applied automatically to every database query, background job, cache key, file path and realtime channel, and code that reaches for tenant data without a workspace context raises an error rather than returning everything. Cross-workspace access attempts are tested as part of the build, not assumed.

Signing in

• Passwords are hashed with bcrypt, with a minimum length and an optional check against known-breached password lists.
• Two-factor authentication (TOTP) with single-use recovery codes, available to every user.
• Sign-in attempts are rate limited per account and per address; you can see and revoke your active sessions.
• Sensitive actions ask for your password again even mid-session.
• The website, the app, the staff console and the API are separate hosts with separate session cookies. A session on one is not a session on another.

Reading and sending mail

• Incoming HTML is sanitised before rendering: scripts, frames and event handlers are removed.
• Remote images stay blocked until you ask for them for that conversation.
• Attachments are size- and type-checked; executable types are refused, and downloads are authorised per request rather than served from a public path.
• Message bodies are a cache with a retention window. Search keeps a plain-text copy, scoped to your workspace like everything else and removed with the mailbox.

Our staff

The people who operate WaryMail use a separate console on its own host with mandatory two-factor authentication, role-based permissions, a password re-confirmation before any change, a required reason and an audit record of who did what and when.

That console deliberately has no customer impersonation, no database browser, no SQL console, no file browser, no environment editor and no shell. Staff can suspend an account or read metadata; they cannot silently walk into your mailbox through the product.

Availability and recovery

The platform is built to be operated this way, and the procedures are written down:

• Encrypted database backups taken on a schedule and copied off the server that made them, with a written restore procedure that is rehearsed rather than assumed.
• Health checks covering the database, cache, queues, scheduler, storage and mailbox providers, exposed to monitoring and to the operations console.
• Releases are immutable directories switched by a symlink, so rolling back to the previous version is a switch rather than a rebuild.

Backup frequency, retention and recovery targets belong in a written agreement. Ask us for the current figures for your plan rather than reading a number off a marketing page.

Your data, your exit

• Export your workspace's data from settings whenever you want.
• Deleting a workspace removes its mail cache, attachments and connected accounts; see the privacy policy for retention periods.
• We do not sell data, and we do not use your mail to train models.

Reporting a vulnerability

Email hello@warymail.co.uk with enough detail to reproduce the issue. We will acknowledge within three working days and tell you what we are doing about it. Please do not run tests that degrade the service for other customers, access data that is not yours, or disclose publicly before we have had a reasonable chance to fix it. We will not pursue legal action against researchers who follow that.

Machine-readable contact details: /.well-known/security.txt.