Security & compliance trust center

Professional and Team are fully self-serve on this site. Enterprise covers regulated rollouts that need a dedicated compliance workspace and contractual scope.

Shanghai R&D holds engineering assets and source repositories. Hong Kong offshore entity operates commercial contracts and customer-facing support. Production data and physical servers are hosted in a US Virginia compliant datacenter.

• The Shanghai R&D entity holds engineering assets only; R&D environments do not store production database credentials, HttpOnly session secrets, or IMAP decryption keys. Access to US-hosted production infrastructure is limited to designated operational roles under least-privilege policy, MFA, and audit logging — routine engineering does not require production mailbox access.
• Data processing is designed for dual jurisdictional alignment: US CCPA and Hong Kong PDPO (Personal Data Privacy Ordinance) obligations.
• Mail bodies remain on Dovecot IMAP; the Finmail database stores index metadata and compliance artifacts only — bodies are not persisted as the system of record in SQL.

On Enterprise, the Compliance Officer workspace records material mail actions — open, download, forward, secure-link send — into an append-only audit log. Team and Pro log key events (reads, secure links) for operational review; the full console and Legal Hold require the Enterprise program.

Each entry receives a monotonic sequence number (assigned only on the server), a link to the previous hash, and an entry hash computed with SHA-256 over canonical row data. Concurrent writes retry safely on conflict.

Platform administrators cannot alter history without breaking chain verification. Damaged chains are repaired only through a controlled, audited repair procedure — never silent edits.

compliance_audit_logs (append-only)
┌─────────┬──────────────┬──────────────────────────────────────┐
│ seq (n) │ previousHash │ entryHash = SHA-256( canonical row ) │
├─────────┼──────────────┼──────────────────────────────────────┤
│    1    │   (genesis)  │  H₁                                  │
│    2    │     H₁       │  H₂ = f(row₂ ∥ H₁)                   │
│    3    │     H₂       │  H₃ = f(row₃ ∥ H₂)                   │
│   …     │     …        │  tamper → verifyAuditLogChain FAIL   │
└─────────┴──────────────┴──────────────────────────────────────┘
• sequence: BIGINT, strictly monotonic (server-only assignment)
• Actions: read, download, forward, mail.send.secure_link, …
• Client may verify; cannot forge chain head or rewrite history

The Privacy Enhancement Gateway reduces metadata leakage on outbound and inbound paths:

• Header scrubbing removes sensitive MIME headers (client IP traces, device fingerprints, unnecessary Received hops) before relay.
• Read-mode HTML sanitization blocks passive tracking pixels where configured, with blocked events counted for review.
• Shield shadow aliases let outbound mail send from a relay address, masking the analyst's real address from external recipients while preserving deliverability.

Mail bodies are not stored in the SQL database. At login, your mailbox password is sealed in HttpOnly session cookies and decrypted only in-process for IMAP and SMTP — never exposed to the browser or reused as plaintext in user profile fields.

Cross-device preferences and encrypted mail cache snapshots upload as Vault ciphertext. Keys are derived from your local master password; Finmail servers store only encrypted blobs — no platform-side decryption.

Secure Share lets recipients read sensitive content via authenticated links instead of exposing full MIME payloads in attachments.

• Burn-after-read windows and optional watermarking on the read page.
• Secure-link sends append compliance audit entries (mail.send.secure_link) without blocking delivery on audit failure.
• Outbound mail queues through mail_outbox → worker → Postfix SMTP with per-role rate limits.
• Composer encryption mode and burn-on-read trigger secure-link outbound paths.

When AI features are enabled (summaries, Ask Finmail, pre-send checks):

• Processing is scoped to provide the Service for the authenticated account only.
• External AI egress may apply PII masking per tenant settings.
• Finmail does not use mailbox content to train or improve generalized LLMs.
• Usage is metered via ai_usage_logs with monthly quotas and daily safety valves.

Customers must independently verify AI outputs before regulatory or tax filings.

Gateway features complement — but do not replace — MTA-grade TLS and identity authentication:

• SPF, DKIM, and DMARC alignment for institutional deliverability — outcomes from real RFC822 headers, not placeholder badges.
• Dovecot IMAP and Postfix SMTP with TLS-required transport on production paths.
• Edge proxy (proxy.ts) performs JWT/Cookie gating only — no database or IMAP connections in Edge Runtime.
• Corporate domain onboarding generates tenant DKIM keys with guided MX/SPF/DMARC DNS setup.

Inbound attachments pass production scanning and sandbox controls before preview:

• ClamAV integration for malware scanning with scheduled scan jobs on upload.
• Sandbox preview and redaction gates before inline display of untrusted content.
• Link Shield and spoof detection warn on suspicious URLs and sender identity mismatches.
• Outbound DLP scanning on sensitive content before send.

Finmail holds granted patents in the United States and Japan. Marketing and product pages reference the US grant; the full portfolio is listed here for diligence reviewers.

Patent specifications describe email-native value transfer and remittance-mail cluster systems among other innovations. Not every claim maps to a shipped Finmail Webmail feature — for example, Pay-To remittance is not offered today. Inbox indexing, privacy gateway, and team workflows on this page reflect the current product, not the full patent scope.

Finmail does not yet publish a SOC 2 Type II attestation report. Engineering aligns with a Trust Services Criteria roadmap for future Enterprise rollouts. Implemented controls on production paths include:

• Append-only compliance audit and archive policy
• Mandatory 2FA (TOTP and backup codes)
• Authenticated API access for all mail and settings routes
• Rate limits on sign-in and sensitive routes
• TLS-required SMTP and Postfix transport encryption
• Documented audit log repair runbook
• PII masking on external AI requests
• Secure Share burn-after-read with watermark