Security at StackSender.

StackSender is a transactional email API built on AWS SES. Customers verify a sending domain, mint an API key, and POST messages to our REST endpoint; we handle delivery, bounce and complaint processing, suppression, webhooks, and reporting.

Our security model follows from that shape. The three things that matter most are: credentials cannot be recovered from our database, one tenant cannot reach another's data, and abusive sending is detected and stopped before it damages the shared sending reputation everyone depends on.

In transit

• The marketing site, the dashboard, and the API are served over HTTPS only. Plain HTTP requests are redirected by the edge network.
• Connections from the application to Postgres, to Redis, and to every third-party API are TLS-encrypted.
• Outbound mail is handed to Amazon SES over TLS. SES negotiates opportunistic TLS with the receiving mail server; whether the final hop is encrypted is ultimately decided by the recipient's provider, not by us.
• Customer webhook endpoints must be HTTPS URLs.

At rest

• The primary database is managed Postgres on Supabase, running on AWS with storage-level encryption provided by the platform. Backups inherit the same encryption.
• Inbound email held for forwarding is stored in Amazon S3 with server-side encryption, and is removed once forwarding completes.
• On top of the platform's disk encryption we apply application-level encryption to the highest-value secrets — see the next section. That means a database dump alone does not yield usable credentials.

API keys

• Keys are generated from a cryptographically random alphabet and take the shape re_<prefix>_<secret>.
• We store two things: the 8-character public prefix, used to look the key up in constant time, and an argon2 hash of the full token. The plaintext is displayed exactly once, at creation. It is not recoverable afterwards — not by you, not by support, not by anyone with database access.
• Every API request is authenticated by prefix lookup followed by an argon2 verification of the presented token. Any failure — unknown prefix, revoked key, hash mismatch — returns an identical 401.
• Keys can be scoped to sending_only instead of full access, and optionally bound to a single domain. Keys are revocable at any time, and each key records a last-used timestamp so stale credentials are easy to spot.
• Separate sandbox keys can be minted per branch. Sends made with them are isolated from production analytics and maintain their own suppression list.

Webhook signing secrets

• Each webhook endpoint gets its own signing secret, encrypted with AES-256-GCM(Node's native crypto) before it is written to the database. The ciphertext, initialisation vector, and authentication tag are stored in separate columns; the encryption key lives only in the runtime environment, never in the database or the repository.
• GCM is authenticated encryption, so tampering with a stored ciphertext is detected on decryption rather than silently accepted.

Account passwords

• Dashboard authentication is handled by Supabase Auth. Password hashing, session issuance, and rotation happen there — StackSender never receives, logs, or stores a plaintext password.
• Sessions are carried in HTTP-only cookies and refreshed by edge middleware on every navigation.

• Every tenant-owned table carries a team_id foreign key, and every read and write in the application is scoped by it. There is no code path that queries email logs, contacts, domains, or suppressions without a team filter.
• Row-level security is enabled on the public tables in Postgres as a second layer, so a mistake in application code does not automatically become cross-tenant data exposure.
• API keys resolve to exactly one team. A key cannot address another team's resources even if it guesses a valid resource ID — unknown-to-you IDs return 404, not someone else's data.
• Deleting a team cascades to every dependent record: domains, keys, email logs, contacts, audiences, broadcasts, webhooks, suppressions, and audit entries.

• Delivery, bounce, and complaint events arrive from Amazon SNS. Every payload has its signature verified against an AWS signing certificate before it is parsed.
• A valid Amazon signature only proves that some AWS account published the message, so each handler additionally pins the topic ARN to our own. If the expected ARN is not configured, the handler fails closed and rejects the event — a missing environment variable must never widen the trust boundary.
• Subscription-confirmation requests are validated against the AWS-hosted confirm endpoint in our own region so the handler cannot be used as a blind SSRF primitive.
• Inbound provider events are deduplicated through a shared inbox table keyed on the provider event ID, so replayed notifications are processed once.
• Outbound webhooks to your endpoints are signed with your per-endpoint secret, and every attempt is logged with its HTTP status, duration, and error so you can audit what we sent.
• Click-tracking redirects are cryptographically signed. An attacker cannot craft a tracking URL on our domain that forwards to an arbitrary destination, and unsubscribe links carry signed tokens rather than guessable identifiers.
• Stripe billing webhooks are verified against Stripe's signing secret and pass through the same deduplication inbox.

Sending infrastructure is shared, so platform abuse is a security problem as much as a business one. The controls in place today:

• Automatic suppression. Hard bounces and spam complaints are written to a per-team suppression list, and subsequent sends to those addresses are blocked before they ever reach the mail transport.
• Per-team rate limits. A sliding-window limit caps burst send rate, and free-tier accounts are additionally capped daily.
• Bounce-rate review. An hourly job flags any team whose combined bounce-and-complaint rate exceeds 5% over a rolling 24-hour window on meaningful volume, for throttling or suspension.
• Sender verification. Domains must pass DKIM/SPF/DMARC verification before they can send. Signup IP and user-agent are recorded for abuse attribution, and known-abusive email addresses and IP ranges are blocked at registration.
• Idempotency. The send endpoint honours an idempotency key with a unique constraint per team, so a retried request cannot double-send.
• Spend caps. Teams can set a monthly cost cap that auto-pauses sending — which also limits the blast radius of a compromised key.

We run a deliberately small vendor surface. All processing takes place in the United States, with us-east-1 as the primary sending region.

Each provider maintains its own security programme and certifications. Ours are described honestly in section 10.

• Secrets management. All credentials live in environment variables managed by the hosting platform. They are validated at startup by a schema that fails the build if a required secret is missing or malformed, and no secret is committed to the repository.
• Least privilege. Production access is limited to the operator of the service. Application credentials are scoped to the minimum permissions each integration requires.
• Audit trail. Security-relevant actions — API key creation and revocation, domain verification, billing changes, broadcast sends, suppression edits — are recorded in an immutable per-team audit log with actor, resource, IP address, and user-agent.
• Error hygiene. API responses use a uniform error envelope. Raw database, SES, and infrastructure errors are logged server-side and never returned to callers, so connection strings, region hints, and internal identifiers do not leak through error messages.
• Dependencies. Dependencies are pinned via a committed lockfile and updated deliberately rather than automatically.
• Backups. The database is backed up by the managed Postgres provider with point-in-time recovery available on its platform tier.

Email log retention is bounded by plan: 7 days on Free, 30 on Starter, 90 on Pro, 180 on Scale, and 365 on Volume. Audit logs are retained for 90 days. Inbound messages are kept only long enough to forward them. Suppression entries persist for the life of the account, because forgetting a hard bounce or a spam complaint would defeat the purpose of recording it.

Full detail, including how to request deletion, is in the Privacy Policy.

What to include

• A description of the issue and the impact you believe it has.
• Clear reproduction steps, with the exact request or URL involved.
• Any accounts, API keys, or domains you used during testing, so we can scope the investigation.

Ground rules

• Test only against your own account and your own domains. Do not access, modify, or exfiltrate another customer's data — if you find a way to, stop and report it rather than proving it at scale.
• No denial-of-service, no load testing against production, no social engineering of our team or our providers, and no spamming real recipients as a proof of concept.
• Give us a reasonable window to fix the issue before publishing. We will keep you updated and are happy to credit you.

What to expect

• Acknowledgement within 3 business days.
• An initial assessment and severity triage within 7 business days.
• A fix timeline proportionate to severity, and notification when the fix ships.
• We do not currently run a paid bug bounty. Reports are handled on goodwill and credited with your permission.

Plenty of vendors imply certifications they do not hold. Here is our actual position:

If your procurement process requires a completed security questionnaire, we will answer it directly and truthfully — including the questions where the answer is “not yet”.

Being candid about gaps is more useful than a badge wall. Known items on our security roadmap, in rough priority order:

• An independent third-party penetration test of the API and dashboard.
• Formal, documented incident-response and breach-notification runbooks.
• A structured audit-readiness programme, as a prerequisite for pursuing SOC 2 when the business supports it.
• Customer-facing security features: SSO and enforced two-factor authentication.

Vulnerability reports: security@stacksender.com

Security questionnaires, DPAs, and everything else: support@stacksender.com

Related reading: the Privacy Policy and the Terms of Service.