How Rasket protects your mail and your account
Every team's data is fenced twice, by our code and by the database itself. Keys are hashed, secrets are encrypted, and every webhook is signed. Here is how, and what we do not claim.
Security at a glance. What protects your data today, one line each.
Isolation, enforced twice
Our code filters every query by team, and Postgres row-level security checks the same team on every row.
API keys stored as hashes
A key is shown once. We keep its SHA-256 hash and a short prefix, never the key itself.
Secrets encrypted
Signing secrets, DKIM keys, two-factor and SSO secrets are encrypted with AES-256-GCM, one data key per row.
Signed webhooks
Every delivery carries an HMAC-SHA256 signature and a timestamp, so it cannot be forged or replayed.
Two-factor and SSO
Any member can turn on two-factor. A team can require single sign-on over OpenID Connect.
Audit log and quiet logs
Every change to a key, domain, webhook, team or plan is audited. Logs leave out credentials and bodies.
Data retention by plan
Email data is kept 30 days on self-serve plans, then deleted by a nightly job, not hidden.
Hosted in the United States
The application and database run in the US, over TLS, with the database encrypted at rest.
How your data is separated. A team is the boundary, and two independent checks keep every row inside it.
- 1
The request resolves to one team
An API key belongs to exactly one team, and no API parameter can name another. A dashboard request takes its team from the address bar, checked against your membership first.
- 2
The transaction names that team
Every transaction opens by declaring the one team it may touch. The declaration dies with the transaction, so it cannot leak into the next request over a pooled connection.
- 3
The database denies the rest
Each table of customer data carries a policy comparing the row's team with the declared one. No team declared means no rows at all, so a forgotten check fails closed.
A team you are not a member of answers 404, not 403, so the dashboard never confirms which teams exist. An API key sent to an endpoint its permission does not cover is refused with a named error. Our own mail goes through the same sending pipeline from a team of our own, so there is no privileged path around any of it.
How secrets are stored. The one you paste into your server is the one we cannot read back.
- API keys are hashed, and shown once.
- We store the SHA-256 hash of the whole key plus its first few characters, so you can tell keys apart. Nothing we hold turns back into your key. A key is full access or sending access, and a sending key can be pinned to one domain.
- Every other secret is encrypted.
- Webhook signing secrets, DKIM private keys, two-factor secrets and SSO client secrets use AES-256-GCM, each row under its own data key. The master key lives outside the database and never reaches a backup, and a ciphertext is bound to its row, so a copied row will not decrypt.
- Every event we post is signed.
- A delivery carries an id, a timestamp and an HMAC-SHA256 signature over the exact bytes we sent. Refuse a timestamp more than five minutes either side of now and a captured request cannot be replayed at you.
- Logs leave the secrets out.
- Authorization headers, cookies, anything named like a token, password or key, and message bodies are redacted. An attachment is logged as its name, size and checksum.
import { Webhook } from "svix";
const wh = new Webhook(process.env.RASKET_WEBHOOK_SECRET);
export async function POST(request: Request) { const rawBody = await request.text(); const event = wh.verify( rawBody, Object.fromEntries(request.headers), ); // throws on a bad signature or a replay await handle(event); return new Response(null, { status: 200 });}The verifier has no dependencies. The full scheme is in events and webhooks.
Access and accounts. Who can get in, how they prove it, and what is written down when they do.
Two-factor authentication
Any member can turn on a time-based code from an authenticator app, with ten single-use recovery codes. The secret is encrypted and the recovery codes are stored as hashes.
Passwords and sessions
Passwords are hashed with Argon2id and checked against a breached-password list. A reset signs every session out, and a session lasts 30 days at most, 7 without use.
Single sign-on
Connect your identity provider over OpenID Connect and prove each email domain with a DNS record. Turn enforcement on and the team is reachable only through your provider; an exempt member needs two-factor.
- Scale: SSO with add-on
- Custom: Single Sign-On included
Roles
Admins do everything. Members do the day-to-day work but cannot manage people, billing or single sign-on. Viewers can read everything and change nothing. A team always keeps at least one admin.
OAuth for other apps
Another app can act for a team without anyone pasting a key into it: authorization code with PKCE, no client secret to lose, and only the scopes a person approved. No scope reaches keys, members or billing.
Audit log and support access
Every change to a key, domain, webhook, team or plan is written to the audit log in the same transaction as the change. If Rasket support views your account or opens a message, Settings → Security tells you.
What we keep, and for how long. Retention is part of your plan, and a nightly job deletes the rows.
An admin can download a copy of the team's data, or delete the team, from Settings → Data. Deleting stops sending at once and erases the data 30 days later.
You can erase a contact from the dashboard or the API; only a hashed consent record stays, as evidence the unsubscribe was honoured. Deleting your own account is on request.
The privacy policy lists every class of data and its window.
| Data | Kept for |
|---|---|
| Emails, attachments, events, request logs, webhook deliveries | 30 days on self-serve plans; agreed on Enterprise |
| Mail in your mailboxes | Until you delete it; 30 days after a mailbox closes |
| Suppressions, contacts, templates, domains | Until you delete them |
| Audit log and billing records | 7 years |
| A data export | Downloadable for 7 days |
| A deleted team | Erased after 30 days, cancellable until then |
| Database backups | Up to 90 days |
What we do not claim. A security page that overstates is worse than none.
No paid bug bounty. We would rather say so than let a page imply one.
No SAML. Single sign-on is OpenID Connect only.
No self-serve account deletion yet. Deleting a team is a button; deleting your own account is a request to us.
Need a security review before you buy? Write to sales@rasket.com and we will answer your questionnaire.
Reporting a vulnerability. Tell us, and we will tell you what we find.
Write to info@rasket.com with the word Security at the front of the subject line. Include the request you sent, the response you got and what you expected instead.
Test only against your own team and domains, do not run automated scans against the API, and do not touch data that is not yours. Give us a reasonable chance to fix the problem before you publish. We will confirm your report arrived, tell you what we found, and tell you when it is fixed.
Frequently asked questions. What reviewers ask before they trust us.
Where is my data stored, and is it encrypted?
In a managed database and an object store in the United States, both encrypted at rest and reached only over TLS. Secrets such as webhook signing secrets, DKIM private keys, two-factor secrets and single sign-on client secrets are encrypted a second time with AES-256-GCM, each under its own data key.
Can anyone at Rasket read my email content?
Message bodies are never written to our logs, and the logs redact credentials and cookies as well. A small number of operators can reach tenant data through an internal console to investigate an incident or an abuse report. That console needs a second factor on every sign-in, every action there is written to the audit log, and Settings → Security tells your team when support viewed your account or opened a message.
What should I do if an API key leaks?
Revoke it in the dashboard and create a new one. Revocation takes effect on the next request, and the request logs show what the key called and when, so you can see whether it was used.
Do you support single sign-on, and which providers?
Yes, over OpenID Connect. Okta, Microsoft Entra ID and Google Workspace all speak it; SAML does not work. Single sign-on is an add-on on the Scale plan and included on Enterprise, and a team can require it once its email domains are proved by a DNS record.
How do I check that a webhook really came from Rasket?
Recompute the signature over the raw bytes with your endpoint's signing secret, compare it in constant time, and refuse a timestamp more than five minutes either side of now. Our verification package does all three in one call, and depends on nothing but the standard library.