Security at Mailaki
Security is foundational to Mailaki — not an afterthought. This page describes the controls, practices, and processes we use to protect your data and the integrity of the platform.
Infrastructure Security
Encryption in transit. All traffic between clients and Mailaki services is encrypted with TLS 1.2 or higher. TLS 1.3 is preferred. Weak cipher suites are disabled. SMTP submission on port 587 requires STARTTLS.
Encryption at rest. All persistent data — databases, object storage, and backups — is encrypted at rest using AES-256. Encryption keys are managed via a dedicated key management service with automatic rotation.
Network isolation. Services run in a private network. Only the API (port 8080) and SMTP submission (port 587) are exposed to the internet. Internal services communicate over private, non-routable addresses. Firewalls enforce least-privilege ingress and egress rules.
Availability. The API and ingest services are deployed across multiple availability zones. We target 99.9% monthly uptime. Database replicas and automated backups provide point-in-time recovery.
Application Security
Memory safety. Mailaki is written in Rust, which eliminates entire classes of vulnerabilities — buffer overflows, use-after-free, data races — at compile time. We do not use C or C++ in the hot path.
Authentication. Passwords are hashed with Argon2id with per-user salts. Session tokens are cryptographically random. API keys are stored as hashed values — we never store or log the plaintext key after initial generation.
Authorization. Every API endpoint enforces tenant isolation. Data access is scoped to the authenticated tenant at the database query level — not just application logic. There is no way to access another tenant's data via the API.
Input validation. All input is validated and sanitised before processing. SQL queries are parameterised (via sqlx). Email content is parsed with a hardened parser and never executed.
Rate limiting. All API endpoints are rate-limited per tenant. SMTP submission is rate-limited per IP and per sender domain. Repeated authentication failures trigger temporary lockout.
Dependency management. Dependencies are pinned and reviewed. We run automated vulnerability scanning against our dependency tree in CI. Critical vulnerabilities trigger an immediate patch cycle.
API Key Security
API keys are the primary credential for sending email. Follow these practices to keep them safe:
- Store keys in environment variables or a secrets manager — never in source code
- Do not commit keys to version control (public or private)
- Use the minimum scope required (e.g. send-only keys for sending, no admin access)
- Enable IP allowlisting to restrict which IPs can use a key
- Rotate keys regularly and immediately if you suspect compromise
- Delete unused keys from the dashboard
If you believe a key has been leaked, revoke it immediately in the dashboard and email [email protected].
Email Authentication
DKIM. Every domain you add to Mailaki is provisioned with a DKIM signing key (RSA-2048 or Ed25519). All outbound mail is DKIM-signed. Keys are rotated on request or automatically on a schedule.
SPF. We publish SPF records for all sending infrastructure. When you add your domain, we guide you through adding the Mailaki include to your SPF record.
DMARC. We encourage all customers to publish a DMARC policy. The dashboard surfaces DMARC alignment status per domain and generates aggregate reports.
MTA-STS. We support MTA-STS for inbound mail to prevent downgrade attacks on SMTP TLS.
Access Controls
Mailaki employee access to production systems follows the principle of least privilege. Access is granted on a need-to-know basis, reviewed quarterly, and revoked immediately upon role change or departure. Production database access requires a time-limited approval process with audit logging. We do not access customer email content without explicit permission except as required by law.
Logging and Monitoring
Security-relevant events — authentications, API key operations, permission changes, and anomalous request patterns — are logged to an immutable audit log. We run automated anomaly detection over these logs. Alerts are routed to an on-call security engineer 24/7.
Incident Response
We maintain a documented incident response plan. In the event of a confirmed breach affecting customer data, we will:
- Contain the incident and prevent further exposure
- Notify affected customers within 72 hours of confirmation (or sooner as required by GDPR)
- Provide a clear description of what happened, what data was affected, and what we are doing about it
- Conduct a post-mortem and publish a summary where appropriate
Responsible Disclosure
We welcome reports from the security community. If you discover a vulnerability in Mailaki, please report it responsibly:
- Email [email protected] with a description of the issue
- Include steps to reproduce, potential impact, and any proof-of-concept if available
- We will acknowledge your report within 2 business days
- We will keep you informed of our remediation progress
- We will not take legal action against researchers acting in good faith
Please do not access, modify, or delete data that is not yours. Do not perform denial-of-service testing or send spam through the platform.
We do not currently operate a formal bug bounty programme, but we recognise significant findings publicly (with your permission) and may offer rewards at our discretion.
Compliance
Mailaki is designed to help customers comply with email regulations including CAN-SPAM, CASL, and GDPR. We provide suppression list management, unsubscribe handling, List-Unsubscribe headers, and bounce processing to support compliant sending. We are working toward SOC 2 Type II certification — contact [email protected] for our current compliance documentation.
Contact
Security questions or concerns: [email protected]
For PGP-encrypted reports, email us first to request our public key.
See also: Privacy Policy · Terms of Service