Security
We host email, which means we hold some of the most sensitive data a business has. This page sets out what we actually do to protect it, stated precisely enough that you can hold us to it.
1. Encryption in transit
- Web and API — HTTPS only, with HTTP Strict Transport Security. Plain HTTP is redirected, never served.
- Receiving mail — opportunistic TLS on SMTP, and we publish an MTA-STS policy so senders that support it can require TLS and refuse to fall back to plaintext.
- Sending mail — TLS wherever the receiving server supports it.
- Mail clients — IMAP and POP3 over TLS, and SMTP submission over TLS. We do not offer unencrypted client connections.
Email between providers is only as private as the weakest hop. TLS protects mail in transit to and from us; it cannot guarantee how a recipient’s provider behaves after delivery.
2. Encryption at rest
Credentials and keys that we hold on your behalf are encrypted by us with AES-256-GCM before they are written to the database. That covers DKIM private keys, webhook signing secrets, and the credentials for any external mailbox or migration you connect.
Message content and attachments are stored on DigitalOcean Spaces and managed PostgreSQL, both of which encrypt data at rest at the platform level. To be precise about the boundary: we rely on that platform encryption for message bodies rather than adding an application-layer cipher of our own on top.
Passwords are hashed with bcrypt. We never store them in a form we can reverse, and staff cannot read your password.
3. Account security
- Two-factor authentication — time-based one-time codes, with recovery codes.
- Passkeys — WebAuthn sign-in, phishing-resistant by design.
- Session management — active sessions are visible and can be revoked individually.
- Sign-in protection — rate limiting and bot protection on authentication endpoints, and a login history you can review.
4. Email security
- SPF, DKIM and DMARC — generated and verified for every domain you add, so your mail authenticates properly rather than being treated as suspicious.
- MTA-STS — a published policy telling senders to require TLS.
- Spam and malware filtering — inbound mail is scored by Rspamd and scanned for malware by ClamAV before delivery.
- Deliverability monitoring — sending reputation and authentication results are monitored continuously, and domain health is surfaced in your dashboard.
5. Access and operations
Access to production systems is limited to personnel who need it, over authenticated connections. Administrative actions that touch customer data are recorded in an audit log.
We do not read customer mail. Support staff cannot open your mailbox from the admin tools, and we will not access message content except where you explicitly ask us to in order to resolve a problem, or where we are legally compelled.
6. Reporting a vulnerability
If you believe you have found a security issue, email security@justemails.app. Please include enough detail to reproduce it. We aim to acknowledge within 2 business days and to keep you updated until it is resolved.
We ask that you give us a reasonable opportunity to fix an issue before disclosing it publicly, that you do not access, modify or delete data belonging to anyone else, and that you do not run testing that degrades the Service for other customers — no denial-of-service, no spam, no social engineering of our staff or customers.
We will not pursue legal action against researchers who follow those rules and report in good faith. We do not currently run a paid bug bounty, and we will say so plainly rather than imply otherwise.
7. Incident notification
If a breach affects your personal data we notify you without undue delay, and within 72 hours of becoming aware where our Data Processing Addendum requires it. Notification includes what happened, what data was involved, and what we are doing about it.