Security you can verify.

At rest

Content is sealed before it is stored

What lands in the database is ciphertext, not a copy of your customers' mail.

• Every message body (HTML and text) and every attachment is sealed with envelope encryption: a per-message data key encrypts the content and is itself wrapped by the instance key.
• The wrapping key lives outside the database — the environment master key, or AWS KMS when a KMS key is configured, and both can run side by side while older rows keep opening.
• A sealed row is bound to its own id, so a ciphertext moved to another row fails to open instead of leaking.
• Passwords are hashed with scrypt, and API keys are shown once and stored only as a SHA-256 hash plus a short identifying prefix, compared in constant time.

In transit

Every hop is encrypted, including the relay

The panel, the API, the SMTP relay and the hand-off to the inbox all run over encrypted connections.

• The panel and the API are served over HTTPS, with HSTS (one year, subdomains included), a strict Content-Security-Policy, X-Frame-Options DENY, nosniff and a restricted Permissions-Policy.
• The SMTP relay requires TLS: STARTTLS is offered with our certificate, and the relay refuses to start without a keypair unless the operator explicitly opts in for a trusted private network.
• Mail leaves through Amazon SES over TLS, authenticated on your domain by DKIM and SPF.

Recovery

Backups that are verified, not assumed

A daily dump is not a backup until the file has been read back and trusted.

• The nightly dump (pg_dump, custom format) is validated with pg_restore --list and a checksum before it is trusted.
• A copy is pushed to off-site object storage, and the uploaded object is re-read and required to match byte for byte.
• Dumps older than 14 days are pruned, and a dump can be encrypted with an age key before it leaves the host.

Encryption in transit

Everything between you and MepMail travels over an encrypted connection.

• The panel and the API are served over HTTPS, with HSTS (one year, subdomains included), a strict Content-Security-Policy, X-Frame-Options DENY, nosniff and a restricted Permissions-Policy.
• The SMTP relay requires TLS: STARTTLS is offered with our certificate, and the relay refuses to start without a keypair unless the operator explicitly opts in for a trusted private network.
• Mail leaves through Amazon SES over TLS, authenticated for your domain by DKIM and SPF.

Passwords and API keys

Credentials are stored in forms that cannot be replayed.

• Account passwords are hashed with scrypt (Node's crypto.scrypt); no plain-text password is stored or sent to the browser.
• API keys are shown once and stored only as a SHA-256 hash plus a short prefix for identification, and a presented key is compared in constant time.
• A team can hold at most 25 active keys, so a leaked key cannot fan out into an unbounded set of credentials.
• Sign-in, sign-up, password reset and verification resend are rate-limited per window and IP.

Team isolation

The team is the boundary: a credential only ever reaches the team it is bound to.

• Contacts, broadcasts, sending domains, templates, suppressions, API keys, audit entries and API requests all carry the team that owns them.
• An API grant is bound to a team, and membership is re-checked as tokens are issued or refreshed — removing a member stops new tokens.
• Deleting an account is refused while it is the only owner of a team, so a team is never left with nobody able to administer it.

Abuse limits

Limits keep one compromised key or one runaway script from burning a domain's reputation.

• Every plan carries an included volume and a daily send ceiling; sends past the daily ceiling are held instead of running all day.
• Bounces and complaints are recorded per team, and the instance's deliverability health can pause a team's sending.
• Sign-up is closed by default on a reachable instance — only the first account may register — and a beta can be capped by seat count.
• A Cloudflare Turnstile challenge can be turned on for sign-in, sign-up, password reset and the verification resend.

Suppressions

A do-not-contact record beats any future send, on every surface.

• Hard bounces, spam complaints, manual blocks and one-click unsubscribes are stored per team against a hash of the recipient address.
• The list is checked on every send path — API, SMTP relay and scheduled broadcasts alike — while transactional mail still reaches a recipient who only unsubscribed from marketing.
• Suppressions outlive erasure: account data is removed, the hash stays as the do-not-contact record.

Monitoring

The service and the deploy path are watched, not just the happy path.

• The API exposes a health endpoint that reports the service status and the deployed revision.
• Containers run health checks that gate startup and restarts.
• A boot check verifies the application containers and the SMTP relay port and alerts the operator, and each deploy verifies the public site and its security headers before it is called done.

Backups

The database is dumped on a daily schedule and the copy is verified.

• The nightly dump (pg_dump, custom format) is validated with pg_restore --list and a checksum before it is trusted.
• A copy is pushed to off-site object storage, and the uploaded object is re-read and required to match byte for byte.
• Dumps older than 14 days are pruned, and a dump can be encrypted with an age key before it leaves the host.

DKIM, SPF and DMARC

Authentication is configured per sending domain, not globally.

• Connecting a domain returns the exact DNS records to publish: the DKIM record and the MAIL FROM record (SPF).
• Those two gate sending — a domain whose records stop resolving has its sends refused until they are back — and a background worker re-checks each domain's DNS on a schedule.
• DMARC is recommended rather than required, and MepMail reads the policy, including one inherited from the parent domain.