Security

Your email is sent by Amazon SES in an AWS account dedicated to you, which we vend and operate inside our AWS Organization. The credentials are short-lived role assumptions locked by a per-account ExternalId — no access keys exist anywhere in the system; the message content passes through our API to construct the MIME body and is handed straight to SES in your account. No shared IP pool, no mingled reputation.

We are the AWS account holder of record: we pay Amazon, request production access, and answer AWS's reviews. The account is transferable to you on request, as a documented runbook — same account ID, identities, DKIM keys, and reputation.

We store message metadata — sender, recipients, subject, status, and the delivery events SES reports. We do not store message bodies or attachments after the send completes.

Cross-account IAM role assumption with an ExternalId. We hold no long-lived AWS credentials belonging to you — there is no access key column in our database, encrypted or otherwise.

The role is created by a CloudFormation template you can read before running. It grants Amazon SES operations and the ability to manage SNS topics prefixed mycompany-email- for event delivery. It grants nothing else.

After you deploy it, we attempt to assume the role without the ExternalId. If that succeeds, your trust policy is missing its condition and we refuse to store the connection.

Deleting the CloudFormation stack revokes our access immediately and completely, without contacting us.

PostgreSQL row-level security keyed on the organization, with the application connecting as a role that is not the table owner — Postgres never applies RLS to an owner, so this distinction is what makes the policies real rather than decorative.

Every API request runs inside a transaction scoped to a single organization. Application-level filters exist as well; the database policy is what still holds if one is ever forgotten.

Two operations run before the tenant is known — authenticating an API key, and attributing an incoming SES event to a tenant. Each goes through a single narrow database function that takes one opaque value and returns one row.

API keys are stored as a SHA-256 digest with a display prefix and last four characters. The plaintext is shown once at creation and cannot be recovered — not by you and not by us.

Keys carry scopes and can be pinned to a single brand, so a key issued for one client cannot send as another.

The list is deliberately short, and it is short because the architecture keeps each client's mail inside a dedicated AWS account.

• Contabo GmbH (Germany) — application and database hosting
• Amazon Web Services — the sending processor: a dedicated account we operate for you inside our AWS Organization (the shared warm-up pool on the Free plan), plus our own SQS queue for event ingestion (us-east-1)
• Cloudflare, Inc. — DNS for our own domain, and DNS record publishing on your behalf where you have asked for it

We will give thirty days' notice before adding a subprocessor that processes customer data.

Worth stating plainly, because it is the question a security reviewer is actually asking. An attacker with our database would obtain: your organization and brand structure, sending domains, message metadata including recipient addresses and subjects, delivery events, and suppression lists. They would not obtain message bodies or attachments, and no access keys exist to steal — there is no key column in the schema.

The deeper scenario is our AWS Organization itself: an attacker who fully compromised it could send as the accounts we operate. We answer that structurally, not with adjectives — accounts carry no root credentials at all, are restricted by organization policy to email-related services, are reachable only through ExternalId-locked role assumption, and hang off a workload-free management account behind hardware MFA. A database breach alone does not cross that boundary: role assumption requires live AWS credentials our database does not contain.

No SOC 2 report. No penetration test by a third party. No formal incident response retainer. We are early, and pretending otherwise during a security review would be both dishonest and quickly discovered.

If your procurement requires those, tell us where the bar is and we will tell you honestly whether and when we can meet it.