Platform Security Overview

TrekMail secures your account and email data with standard platform safeguards. Use this overview to understand the controls you can see in the product.

Security controls you manage

• Email verification — new accounts must verify their email address via a signed link. Unverified accounts have a 7-day grace period; after that, outbound sending is blocked until verification is completed. Google OAuth accounts are auto-verified. Changing your account email resets verification and sends a new link.
• Two-factor authentication (TOTP) for account login.
• Role-based access through account ownership and admin permissions where available.
• Password policies and password management flows for accounts and mailboxes (including the mailbox password change portal).
• API tokens with configurable scopes, domain constraints, and expiration dates. Tokens are hashed (SHA-256) at rest — the plaintext is shown once at creation.
• Drive device passwords (sync) — separate, scope-limited credentials for desktop sync clients (rclone, Finder, Cyberduck, DAVx⁵, etc.) generated from /drive/devices in the dashboard or from the Sync devices button inside webmail Drive. Each device gets its own password, with a name, an optional expiry, and a permission set capped at what the issuing surface allows (admins can issue account-wide passwords; mailbox users can only issue mailbox-scoped ones from webmail). Revoking a single device leaves the rest connected. The plaintext password is shown once at creation; only the SHA-256 hash is stored. Account admins see every device across both surfaces and can revoke any of them — useful for offboarding. See Sync devices for the full lifecycle.
• API audit log records every API action with the token used, resource affected, IP address, and timestamp.

Data encryption

• Encryption at rest — sensitive data (mailbox passwords, SMTP credentials, Cloudflare API tokens, 2FA secrets, recovery codes, tax document PII) is encrypted with AES-256-CBC.
• Encryption key rotation — we support zero-downtime key rotation. Old data is decrypted transparently during the transition period, and stored ciphertext is re-encrypted with the new key.
• Audit trails survive deletion — billing and admin logs are preserved when accounts are deleted, so financial records remain traceable for compliance.
• Password hashing — user and mailbox passwords are hashed with bcrypt (12 rounds). Mail-server authentication checks the same hash directly — there is no second copy of your password anywhere.

Operational practices

• TLS is required for IMAP and SMTP connections as shown in the mailbox Connection tab. Plaintext authentication is rejected on every supported port — connections that haven't negotiated TLS first get refused.
• All connections use TLSv1.2+ with modern cipher suites (TLSv1.3 / AES-256-GCM preferred).
• DNS authentication (SPF, DKIM, DMARC) is required for sending to protect your domain identity.
• Disposable and throwaway email addresses are blocked at registration to prevent abuse.
• Inbound email is scanned by a Bayesian-learning spam classifier and an antivirus engine with 3.6M+ signatures (hourly virus-DB updates).
• Per-IP rate limiting protects against flooding on all SMTP ports.
• Brute-force protection bans repeat offenders across SSH, SMTP, IMAP, webmail login, and scanner probes.
• Content Security Policy, Permissions-Policy, Referrer-Policy, and HSTS headers are enforced on all responses.
• Disabled and suspended mailboxes are excluded from mail delivery — no mail is accepted or routed for non-active mailboxes.
• Vulnerable dependencies are blocked at deploy time via automated audit checks.

API and MCP security

• API tokens use bearer authentication over HTTPS. Tokens start with tm_live_ and are stored as SHA-256 hashes.
• Scopes limit what each token can do. Domain constraints limit which domains it can access.
• Mailbox deletion requires a two-step intent-and-confirm flow with a 10-minute expiration.
• The MCP server disables destructive operations by default — delete tools require explicit opt-in.
• SSRF protection validates all user-supplied hostnames (SMTP, migration) against private/loopback IP ranges, including IPv4, IPv6, and AAAA DNS records.
• All API activity is fully logged in the audit trail, visible under AI Agents & API → Audit Log. Audit events are retained for 90 days.
• Daily request limits per token prevent mailbox scraping via the Message API.

Quick fixes and troubleshooting

• Enable 2FA for all admins to reduce account takeover risk.
• Keep DNS records current to prevent spoofing and deliverability issues.
• Revoke API tokens immediately if you suspect they have been compromised.
• Review the API audit log regularly to detect unexpected activity.
• Report suspicious activity via the Support Center with timestamps and affected accounts.