Security

1. Certification status

What follows is what we actually do. It is verifiable in the sense that it is specific: if a control below is not in place, that is a defect you can hold us to, not marketing.

2. Data residency

Message content, metadata and application data stay in the European Union.

• Application, database, queues and cache run on a Lithuanian host (Hostinger), on infrastructure inside the EU
• Email sending, event delivery and object storage run in AWS eu-west-1 (Ireland)
• Attachments and raw inbound mail are stored in S3 buckets in the same region, with public access blocked at the bucket level

Vendors are listed individually, with their locations, on the Subprocessors page.

3. Encryption

• In transit to us — HTTPS only, with certificates issued and renewed automatically by Let's Encrypt. The domain is on the HSTS preload list, so browsers refuse plaintext to it before a request is even made.
• In transit to recipients — opportunistic TLS on outbound SMTP, which is what the receiving server allows us to negotiate.
• At rest — object storage uses server-side encryption (SSE-S3). Sensitive database columns are encrypted at the application layer, above whatever the disk does.

4. Secrets and credentials

5. Authentication and access

• Sign-in is by emailed one-time code. We do not store user passwords because we do not have any.
• API access is by bearer key, scoped to a single team, revocable individually.
• Agent access over MCP goes through an OAuth authorisation code flow with scoped, expiring tokens rather than a shared long-lived key.
• Every team's data is isolated by team at the query layer; there is no cross-team read path in the API.
• Account-affecting actions are written to an append-only audit log.

6. Sender authentication

No account can send from a domain until it has proved control of it by publishing DNS records we generate and passing an automated check. We generate and publish a DKIM key pair per domain, an SPF record and a DMARC policy, and verify all of them before enabling sending.

Accounts without a verified domain are limited to a handful of messages, addressed only to the account owner's own registered address. There is no configuration in which an unverified account can mail a stranger.

7. Message and event integrity

• Inbound provider notifications are signature-verified against the provider's published certificate before being processed. An unsigned or badly signed callback is discarded, and a forged subscription confirmation cannot subscribe us to anything.
• Outbound webhooks are signed with HMAC-SHA256 following the Standard Webhooks scheme, with a timestamp inside the signed payload so a captured delivery cannot be replayed later. Secret rotation is supported by accepting multiple signature versions during the overlap.
• Callback endpoints sit behind unguessable path tokens, so an unauthenticated scanner does not find them at all.

8. Abuse controls

• Hard bounces and complaints permanently suppress the recipient, per account, and the suppression list is consulted before every send
• Accounts exceeding a 5% bounce rate or 0.1% complaint rate are suspended automatically
• Per-account API rate limiting, and per-account send rate throttling against the provider's quota
• A monitored [email protected] address, with confirmed abuse acted on immediately

9. Data minimisation

Message bodies, attachments and raw inbound mail are deleted after 30 days. Metadata follows after 365 days. Application logs record events, not message contents.

Short retention is a security control, not a storage saving. The most reliable protection for a message body is not holding one.

10. Infrastructure

• Services run in containers on a private network; the database, cache and queue have no public listener
• TLS terminates at a reverse proxy; the application is not directly exposed
• Deployments are built from source in CI and pulled by digest — nothing is built or edited on the production host
• Cloud credentials are scoped to the specific actions and buckets the platform needs, not to broad managed policies

11. What we have not done

The honest list. Read this next to section 1.

• No external audit. No SOC 2, no ISO 27001, no third-party attestation of any kind.
• No independent penetration test. The system has not been tested by anyone outside the team.
• No bug bounty programme. We accept reports and will credit you, but there is no funded reward.
• No contractual uptime commitment. There is no SLA and no service credit scheme.
• Application-layer encryption uses a key held on the host, not a hardware security module or managed KMS. An attacker with the application server has the key.
• No formal disaster recovery test. Backups exist; a full restore has not been rehearsed end to end.
• Small team. Separation of duties is limited by headcount, and pretending otherwise would be silly.

If any of these is disqualifying for you, it is better that you learn it here than after migrating.

12. Roadmap

In priority order, and only items we intend to actually do:

1. Move application-layer encryption keys to a managed KMS, so the host no longer holds them
2. Independent penetration test, with the summary published on this page
3. Rehearsed restore from backup, documented
4. SOC 2 Type II readiness, targeting [TARGET WINDOW]

This section changes as items land. Items are removed by being done, not by quietly expiring.

13. Reporting a vulnerability