Security

Built like your test mail matters.

Test emails carry real-looking names, reset links and tokens. This is how Mailtarn keeps them contained, from the moment your app sends to the moment they're deleted.

Mailtarn is in development. This page describes how it's being built, and we'll update it as each part ships.

Nothing leaves the sandbox

Mail comes in. It never goes out to real people.

Untrusted HTML stays isolated

Templates render on a separate domain with no cookies and no access to your account.

Least access by default

Per-inbox credentials, per-organization data, and staff access that you can see.

How a message moves through Mailtarn

Five steps, each with its own safeguard.

  1. 01Your app sendsOver SMTP with TLS on 587 or 465, using that inbox's own credentials.
  2. 02Stored, then confirmedMailtarn replies OK only after the message is safely written to disk and recorded.
  3. 03Parsed in isolationA separate worker process parses the message. Files go to storage under your organization's prefix.
  4. 04Viewed in a sandboxHTML loads from mailtarn-content.co.in in a sandboxed frame, through a link that expires.
  5. 05Deleted on scheduleMessages are removed automatically when the project's retention period ends.

The details

Sandboxed rendering

  • Email HTML is served from a separate domain, mailtarn-content.co.in, never from the app's own domain.
  • It loads in a sandboxed frame, with scripts and forms disabled, through a signed link that expires after five minutes.
  • That domain sets no cookies, so a hostile template has nothing to steal.
  • Remote images and fonts stay blocked until you choose to load them, so opening a message doesn't tell a tracker you looked.

Inbox credentials

  • Every inbox has its own SMTP username and password. One leaked password exposes one inbox, not your account.
  • Passwords are stored only as Argon2id hashes. We can't read them back.
  • Passwords are accepted only over TLS. A login attempted before encryption starts is refused.
  • Rotate a password any time. The old one keeps working for 24 hours so you can update your config without dropped mail.

Separation between organizations

  • Every record and every stored file is scoped to your organization.
  • Row-level security in the database is a second, independent check: each request runs as a restricted role that can only see your organization's rows.
  • API tokens can be limited further, to one project or one inbox, and are stored only as hashes.

Your account

  • Two-factor sign-in with an authenticator app is required on every account.
  • Sessions are stored only as hashes, and every change request is protected against cross-site request forgery.

Staff access

  • Our admin console will be reachable only from approved networks and require a passkey or authenticator code. Planned
  • Every admin action will be written to an audit log. Planned
  • If support needs to look at your inbox, access will be read-only, time-limited, need a reason and a ticket, and appear in your organization's audit log. Planned

Nothing is ever delivered

  • Mailtarn only accepts mail. Captured messages are never sent on to the real recipient.
  • Account emails such as invitations and password resets will come from a separate sending service, kept apart from captured mail. Planned

Report a vulnerability

If you think you've found a security issue, email us. We'll confirm we received it and keep you updated while we fix it.

security@mailtarn.com

Please:

  • include steps to reproduce and what you expected to happen
  • test only against accounts you own
  • don't access other people's data or disrupt the service
  • give us reasonable time to fix it before you share details

See also our privacy policy.