Security Overview

Authentication

Sendvery uses magic-link authentication only. We never store passwords — not as hashes, not in any form. When you sign in, we email you a short-lived single-use link. Clicking it establishes a session. No password to leak, no password to phish, no password reuse from other breached sites.

Sessions are server-side and bound to a session cookie marked HttpOnly; Secure; SameSite=Lax. You can sign out from any device at any time.

Encryption at rest

Sensitive credentials (IMAP/POP3 passwords, OAuth2 refresh tokens) are encrypted at rest using paragonie/halite, which is an audited PHP library built on top of libsodium. The underlying primitive is XChaCha20-Poly1305 authenticated encryption with a unique nonce per record.

The encryption key is loaded from an environment variable at boot. It is never stored in the database, never committed to source control, and is rotated independently of the application code. We do not use AES-256-GCM — when you read elsewhere that "data is AES-256-GCM encrypted", that claim was historically inaccurate and has been corrected.

The PostgreSQL database itself lives on encrypted block storage at the hosting provider level (LUKS on Hetzner). Backups are encrypted before they leave the host.

Encryption in transit

All HTTP traffic is served over TLS 1.3 with HSTS enabled. We do not accept plaintext HTTP. Outbound IMAP / POP3 connections are TLS-only — if your provider does not support TLS we will refuse to connect and surface a clear error rather than silently downgrade.

Stripe webhook calls are verified using Stripe's signing-secret HMAC; we reject any webhook whose signature does not match. Sentry error reports are sent over HTTPS to the Sentry EU endpoint where possible.

Data location

Application data lives on Hetzner infrastructure in the European Union. The only data that leaves the EU is the anonymised DMARC summary sent to Anthropic when you have AI Insights enabled — and that summary contains no email addresses, no message contents, and no account identifiers. The full data-sharing scope is disclosed in our Privacy Policy.

Audit trail

State changes inside the application emit domain events (the EntityWithEvents pattern). Events that touch billing or credentials are persisted alongside the entity write so that we have a tamper-evident chain. Stripe webhook payloads are stored verbatim for replay and reconciliation. Application logs are retained for 30 days.

Responsible disclosure

If you believe you have found a security issue, please email security@sendvery.com. We aim to acknowledge reports within 48 hours and to ship a fix for issues we classify as critical within 14 days. We are happy to credit researchers publicly once a fix has shipped (or earlier with your consent).

Please do not run automated scanners against the hosted instance — they generate noise without finding anything we don't already catch in our own scans. Test against a self-hosted instance instead and share the reproduction steps with us.

Self-hosting

Sendvery is open source under AGPL-3.0. If your organisation cannot share IMAP credentials with a third party, you can run the whole application on your own infrastructure for free, forever. The Open Source page has the quickstart.

Certifications

We are honest about where we are: Sendvery is pre-SOC2 and pre-ISO27001. Both are on the roadmap as customer demand justifies the audit cost. If your procurement process requires one of those certifications as a hard prerequisite today, the AGPL self-host path is the right answer until we ship them.