MAILRAFT / PRODUCT
Security
This page describes the controls MailRaft actually enforces today, with no overstated claims. For acceptable-use boundaries see Acceptable Use. For data handling see Privacy.
Multi-tenant RLSApprovals-bound sendsSSRF-safe outboundSigned webhooksEncrypted secrets
Isolation
- MailRaft is multi-tenant.
- Tenant membership and suspension are checked server-side on every request.
- Row-level security rules are enforced in the database.
- Service-role access is not an excuse to skip tenant authorization; worker code uses the same policy layer as the API and MCP surfaces.
Authentication
- Google Sign-In through Supabase Auth with openid, email and profile only. Signing in does not grant Gmail access.
- Sessions use Secure, HttpOnly, host-only cookies on app.mailraft.com. No wildcard domain cookies.
- API keys are issued as high-entropy tokens with scopes; the raw value is shown exactly once at creation. Revocation is immediate.
- CSRF tokens are required for browser mutation on the dashboard.
Approvals
- Every outbound operation requires a server-held approval record bound to the exact sender, recipient, subject, body, attachments and thread.
- Any edit to the bound content invalidates the approval and forces a new review.
- The AI never self-approves. The server holds the approval snapshot and decision record; live application-to-provider acceptance remains gated.
- Unknown transport outcomes are reconciled on provider Message-ID. They are never blindly retried and never silently failed over.
Mail authentication
- SPF, DKIM and DMARC are published for the MailRaft sending identity at notify.mailraft.com.
- A custom MAIL FROM subdomain bounce.notify.mailraft.com aligns bounces to a MailRaft-controlled address and MX.
- DKIM selectors are published verbatim from the AWS SES console with no local invention.
- DMARC quarantine or reject promotion follows a documented aggregate-report review cycle.
Integration safety
- Provider credentials are encrypted at rest with per-tenant keys.
- Outbound HTTP requests go through an SSRF-safe gateway: validated DNS, blocked private, link-local and metadata ranges, pinned connections, bounded response sizes, bounded redirects, cross-origin credentials stripped, every redirect revalidated.
- Scopes are enforced server-side; API-key scopes do not override integration action scopes.
- Disconnect clears local credentials before attempting provider revocation; a remote outage does not resurrect a disconnected integration.
Secret handling
- No secret appears in a browser bundle, a URL, a log line, a screenshot or a chat message.
- Operational selectors (private host coordinates, container IDs, Vault item names) stay in the private operator inventory, not public documentation.
- Rotation is explicit and audited; it does not happen automatically on an outage.
Supply chain
- Dependencies are pinned at commit and lock file.
- Audit tooling (pnpm audit, npm audit) runs on every release with a high severity gate.
- Build artifacts carry an immutable release SHA used in deploy evidence.
Independent evidence
- Each release records sanitized evidence under the Evidence Envelope v1 schema (scope, timestamp, release SHA, environment, fixtures, external side effects, unverified gaps).
- Status page reports current endpoint reachability without claiming an uptime SLA; a healthy HTTP endpoint is never evidence of delivery.
- The marketing site runs the same pnpm verify:live boundary gate (health, marketing pages, images, licenses, denied paths, Google callback) on every release.
Reporting a vulnerability
- Email contact@mailraft.com with a focused description.
- Please avoid public disclosure before we have had a reasonable chance to respond.
- Include no passwords, session cookies or private message bodies in an initial report.
Threat model and standards
- Source reviews cover tenant isolation, approval integrity, input validation, secrets and provider boundaries. A passing scoped review does not guarantee freedom from compromise.
- No formal certification is claimed at this time; independent attestations will be published when complete.
Last updated
2026-10-01