Security

How Mailtruss handles your data.

The controls that exist today, described plainly.

Passwords need at least 10 characters. You can add two-factor sign-in with an authenticator app and backup codes. Sign-in, sign-up and password-reset attempts are rate limited, you can see and end your active sessions, and changing your email needs approval from the current address.

API keys

Keys are shown once at creation and stored only as a one-way hash. Sending-only keys can’t read data or manage resources. Revocation takes effect on the next request.

Tenant isolation

Every query is scoped to the organization of the session or API key. Roles (owner, admin, developer, viewer, billing) are enforced on the server, not only hidden in the interface.

Webhooks

Each endpoint has its own signing secret, shown once. Payloads carry an HMAC-SHA256 signature over the event ID, timestamp and body, so you can verify origin and reject replays. Secrets can be rotated with an overlap window.

Logs and redaction

API logs store request and response bodies with secrets removed and large bodies truncated. API keys are never written to logs.

Delivery events

Delivery, bounce and complaint notifications arrive as cryptographically signed messages, and their signatures and origin are verified before they change any message’s state.

Sending reputation

Hard bounces and complaints add the address to a suppression list automatically, and quotas stop sending at the plan limit.

What we don’t claim

Mailtruss is in developer preview. It has no third-party security audit or compliance certification (such as SOC 2 or ISO 27001), no uptime commitment, and no public bug bounty yet. This page will change when that does.