Email/password sessions, TOTP setup, and recent-MFA-sensitive flows.
Internal email platform
Email operations, operator controls, and webmail in one boundary.
Thunder Mail combines domain onboarding, mailbox provisioning, scoped access, audit, usage visibility, API keys, MFA, and a Bulwark-based webmail experience for teams operating across departments, brands, and projects.
Live entry points
Go straight to operator administration or mailbox access.
Grounded in current repo behavior
- Tenant, domain, mailbox, API key, usage, and audit surfaces are implemented.
- Route 53 plus GoDaddy Connect, durable bulk jobs, and webmail integration exist.
- Manager export, manager mailbox, and live production proof remain intentionally gated.
Platform snapshot
Built for controlled mailbox operations, not generic brochure copy.
The repo already supports real operator flows across the Manager Portal, Platform API, and Thunder Mail webmail surface.
One credential-bearing mailbox account per address, plus durable bulk processing.
Domains, mailboxes, API keys, audit, usage, and role-sensitive admin controls.
Repo-owned branding and configuration around the Bulwark mail client.
Tenant, domain, and mailbox workflows
Webmail separated from operator administration
Tenant-scoped audit, usage, and API keys
Session auth with MFA-sensitive flows
Capabilities
What the platform already supports
This homepage is intentionally anchored to implemented code paths and current docs, not aspirational feature language.
Domain onboarding and Connect
Create domains, drive Route 53 and GoDaddy orchestration, verify DNS and SES state, and keep rollback paths visible to operators.
Mailbox provisioning
Provision individual mailboxes or durable bulk jobs with generated credentials, idempotent handling, and recoverable worker processing.
Manager Portal workflows
Operate tenants, users, domains, mailboxes, API keys, usage, and audit from a browser-only portal backed by the Platform API.
Thunder Mail webmail
Offer direct mailbox login through the branded Bulwark client, with JMAP-facing configuration and repo-owned branding.
Scoped access and safe defaults
Keep role-sensitive flows, MFA-protected credential reveal, default-deny API-key behavior on human routes, and capability flags around unfinished sensitive paths.
Audit and usage visibility
Write append-only audit events, expose tenant-scoped audit queries, and show internal usage without pretending billing or production rollout is complete.
How it works
Move from domain setup to mailbox access without splitting the workflow across tools.
The platform ties together operator administration and direct mailbox use while keeping content access and management surfaces distinct.
Set up the operating boundary
Create tenants, add domains, assign roles, and define who can manage what.
Connect infrastructure
Use provider-aware domain workflows to reconcile DNS, SES identity state, and related onboarding checkpoints.
Provision mailbox accounts
Generate one mailbox account per address, store the secret in the application vault, and track progress across bulk jobs when scale is needed.
Use webmail and operator controls
Let credential holders log into Thunder Mail while operators stay on the Manager Portal for administration, audit, usage, and controlled reveal flows.
Why this shape
Designed around real email operations, not a generic productivity stack.
The strongest differentiator in this repo is how product workflow, mailbox lifecycle, and operator guardrails are already stitched together.
One platform boundary
The Manager Portal talks only to the Platform API, while the webmail client stays focused on mailbox access. Operational logic stays centralized.
Truthful rollout posture
The copy here intentionally tracks implemented surfaces, capability-gated work, and runtime evidence that is still missing.
Operator-ready bulk work
Durable parent jobs, result manifests, retry support, and tenant-aware controls make higher-volume mailbox generation a first-class workflow.
Webmail without a custom mail client rewrite
Thunder Mail reuses Bulwark where that is sensible, then layers manager workflows, audit, and provisioning around it through repo-owned code.
Product workflow
What an operator journey looks like today
This sequence reflects current implementation boundaries and calls out the areas still kept behind gates.
Onboard the tenant and domain
Add the internal department or brand, register the domain, then reconcile DNS state through the domain workflow.
Provision addresses one by one or at bulk scale
Create individual mailbox accounts or submit durable bulk jobs that the worker can process, report, and retry safely.
Reveal current credentials when policy allows
Owner and admin users can reveal the current generated password with recent-MFA protection and no-store response handling.
Use Thunder Mail for direct mailbox access
The branded webmail layer gives the credential holder a dedicated mailbox experience on top of Stalwart via JMAP.
Review audit and usage
Operators stay inside the Manager Portal for audit queries, API key management, and internal usage visibility.
Keep gated surfaces honest
Manager export, manager mailbox, and broader production claims stay disabled or unproven until runtime evidence catches up.
Security and posture
Security controls are part of the product story, and so are the current limits.
The repo already contains material control points. It also explicitly documents what is not yet safe to market as live or production-proven.
Session auth plus TOTP MFA
Privileged flows are built around browser sessions with MFA setup and recent-MFA-sensitive actions.
Encrypted mailbox secret storage
Provisioned mailbox secrets are stored as encrypted vault data rather than plaintext application records.
Append-only audit surfaces
Audit writes and tenant-scoped audit query routes already exist on the platform boundary.
Capability-gated sensitive flows
Incomplete manager-only features stay off by default instead of being marketed as available today.
Contact and rollout
Start the next rollout with the right scope from the start.
This homepage does not invent a fake lead endpoint. Instead, it gives your team a ready-made intake brief you can copy into the contact channel you actually use.
Start with a rollout brief
Capture the domain count, mailbox volume, access model, and whether you need gated features reviewed before expanding the footprint.
Covers team, domains, mailbox count, access model, audit, API keys, and any gated-feature review.
Domain onboarding
Align on DNS ownership, provider constraints, and rollout sequencing first.
Mailbox volume
Decide whether single-create flows are enough or whether bulk job workflow is required.
Access model
Confirm who needs manager-side operations, who only needs mailbox credentials, and which sensitive capabilities should remain gated.