How MailVora protects your mail and your data
This page describes the controls built into the platform. It is maintained alongside the software and reflects how it actually works.
Accounts and access
- Passwords are hashed with Argon2id (OWASP parameters). We never store or display a password in readable form.
- Optional two-factor authentication (TOTP) for every console user; required for platform operators in production.
- Repeated failed sign-ins lock the account for 15 minutes. Session cookies are HttpOnly, Secure and SameSite, and every state-changing request carries a CSRF token.
- Roles limit what each person can do. ICT support staff can send activation or reset links to an employee's own personal address and unlock sign-ins, but cannot set, read or receive a password.
- Employees activate their mailbox through a single-use link and choose their own password; nobody at their institution ever knows it.
Tenant isolation
Every request is bound to one organization derived from the signed-in user or the API key — never from a value the client sends. Automated tests try to read, change and delete other tenants' data and must fail.
API keys
- Keys contain about 238 bits of randomness and are shown once. Only a SHA-256 digest is stored.
- Keys carry explicit scopes and can be limited to IP ranges and to specific sending domains. Rotation issues a new key and revokes the old one in a single step.
Email authentication and transport
- Each domain has its own 2048-bit DKIM key, stored encrypted (AES-256-GCM). The console guides you through SPF, DKIM, DMARC and MX records and checks them.
- Mail apps connect only over TLS: IMAP with implicit TLS and submission with TLS (port 465, RFC 8314) or STARTTLS (port 587). Plaintext connections are not offered.
- The setup guide never asks employees to accept certificate warnings or turn encryption off.
Content safety
- HTML email is sanitized. Received messages are displayed in a sandbox with scripts disabled and remote images blocked by default.
- Executable attachment types are refused. Template variables are escaped and header injection is rejected.
- Webhook URLs must be public HTTPS addresses; private and internal networks are blocked (SSRF protection). Payloads are signed with HMAC-SHA256.
Abuse prevention
Per-plan rate limits and daily and monthly quotas, suppression of bounced and complaining addresses, one-click unsubscribe for bulk mail, and an emergency suspension switch that immediately stops sending, API keys and mailbox access for an organization.
Accountability
Security-relevant actions are written to an audit log with the actor, time and IP address. Organization administrators can review and export it. Passwords, keys, tokens and message bodies are never logged.
Data retention
Message content is purged after a configurable retention period while delivery history is kept for reporting. Mail-app setup analytics contain no message content or device identifiers and are deleted after 13 months.
Reporting a vulnerability
Please report security issues privately to support@techcoreexperts.org. Include steps to reproduce and do not access other users' data.