Self-hosted email for financial services

Self-hosted email for financial services: why retention, not delivery, sets the design

A regulated firm that must keep every business message and wants control over where its mail lives should start from a simple point: the mail server is rarely the compliance record. Under SEC Rule 17a-4(b)(4), broker-dealers must preserve originals of communications received and copies of communications sent relating to the business, including inter-office communications, for not less than three years. That obligation applies to the messages, wherever they sit, so the design separates mail hosting from a separate archive that captures copies of every relevant message. The mailbox server handles delivery, access and user experience; the archive holds the retained, searchable and tamper-resistant record. Bank, insurance and other financial entities face parallel expectations from their own regulators, so confirm the exact rule set that applies to your entity before you size anything.

On platforms, the short answer is that Stalwart, mailcow and OX App Suite can all carry mail for an organization, and the archive decision is made independently of that choice. The facts available for this page do not establish which of these platforms offers journaling, legal hold, eDiscovery or supervision features, or how each one exports journal copies to a third-party archive. Treat that as an open question. Ask each candidate partner and vendor to show, in writing, how journaling is configured, what format the journal copies use, whether the archive can be filled and verified without touching mailboxes, and how legal hold is applied. Ask your compliance team to confirm which archive product, and which retention settings, they will accept as the official record.

The practical next step is a decision record before procurement. Name the business communications in scope, including chat and calendar items where your policy treats them as records, and identify who owns the archive, the retention schedule and the supervision review. Then ask any implementation partner to describe how the mail flow, journal path and archive connect, and where failures would surface. A design that cannot answer those questions will not hold up in an examination, regardless of how well the mailboxes deliver.

Which financial services rules shape the mail build

This table maps each financial services rule to the concrete mail build decision it drives, such as journaling, MFA, contract terms or exit planning. Read each row as a question to answer before the platform is chosen, and note that the rule text itself does not name a product. The main takeaway is that retention and resilience obligations apply to the mail system and its archive as a whole, not to the mailbox server alone.

Rule or requirement	What it asks for	Build consequence	Evidence to confirm with your assessor
SEC Rule 17a-4(b)(4)	Broker-dealers preserve originals of business communications received and copies of those sent, including inter-office messages, for not less than three years	Journal every in-scope mailbox to a separate archive that the mail server cannot alter, and keep the archive outside the mailbox server's backup and deletion path	Journaling configuration, archive retention settings, and a sample retrieval of a message from the archive rather than from the mailbox
SEC Rule 17a-4 scope of 'business communications'	Communications relating to the business must be captured, which includes internal messages and personal-device exchanges used for business	Define which aliases, shared mailboxes, calendars and external connectors are in journaling scope, and confirm how mail from non-corporate clients is captured	Written scope list, mailbox population report and exceptions approved by compliance
FTC Safeguards Rule, 16 CFR 314.4(c)(5)	Multi-factor authentication for any individual accessing an information system, unless the Qualified Individual approves an equivalent control in writing	Enforce MFA on webmail, admin consoles, and IMAP and SMTP submission where the client supports it, or document a written equivalent control for clients that cannot	MFA policy export, the Qualified Individual's written approval for any exception, and the list of clients without MFA support
DORA Article 28(3)	A register of information covering all contractual arrangements for ICT services, including the mail platform and any hosting, relay or archive provider	Record the mail platform, archive, spam filtering, backup and any managed service as separate entries, each linked to the function it supports	Current register extract showing each mail component, provider, and the supported function
DORA Article 30(2)	Each ICT services contract states where services are provided and data processed, gives advance notice of location changes, and covers data return on insolvency or termination	Contract clauses naming hosting regions and sub-processors, notice periods for changes, and a defined export format for mailboxes, archives and journal data	Signed contract clauses on data location, change notice and return, with the export format named
DORA Article 28(8)	Documented, tested exit strategies and transition plans for ICT services that support critical or important functions	Write an exit plan for the mail platform and archive, including how archived records stay readable after the platform changes and how mail routing moves to a successor	Exit plan document, a test restore of archive data into a second environment, and the date of the last exercise
PCI DSS v4.0.1 (only where cardholder data appears in mail)	Protection of cardholder data wherever it is stored, processed or transmitted, including by email, with the v4.0.1 requirements now the only active version	Block or redact primary account numbers in mail flow, restrict mailboxes that could touch the cardholder data environment, and log access to them	Data discovery results for mail, the scope statement for the cardholder data environment, and the assessor's view of mail's place in scope
Retention and eDiscovery readiness	Records must be retrievable on request for supervision, examinations and legal holds	Build search and legal hold on the archive, test retrieval by sender, recipient, date and keyword, and document who may place holds	Search and hold runbook, retrieval test results, and an access list for hold administrators

Which mail platform fits a regulated firm and why

Stalwart is an all-in-one mail and collaboration server that supports IMAP, JMAP, SMTP, CalDAV, CardDAV and WebDAV in one product. It is licensed under AGPL-3.0, and an optional Enterprise License is available from Stalwart Labs. For a financial firm, the fit depends on whether the team is comfortable running a single, fairly self-contained server and whether it needs a vendor to stand behind the software under contract. The current release was v0.16.26, published on October 11, 2026.

Protocol coverage: One binary covers mail access, submission and groupware, which reduces the number of components to patch and monitor.
License choice: AGPL-3.0 carries source-disclosure obligations for modified versions offered over a network, so legal review is needed before changes are made. The Enterprise License is the option to price if a commercial agreement is required.
Operating model: The team must own clustering, backup, upgrades and monitoring. Confirm the supported high-availability design with the vendor before committing.
Archive integration: Confirm whether journaling to an external archive and the connector type your archiving product needs are supported in the release you plan to run.
Fit: Suits a small platform team with strong Linux and mail administration skills and a need for lean infrastructure.

Before selecting Stalwart, ask the vendor for its supported journaling method, its audit logging output and its written support terms under the Enterprise License.

Which components sit between the mailbox and the archive

A mail server delivers messages, but the retention record is built by the components around it. Each piece below must produce its own evidence, and a regulator or examiner will ask for that evidence component by component. Confirm each one before the mail platform is sized or purchased.

Journaling at the MTA

Every inbound and outbound message, including inter-office mail, must be copied at the mail transfer agent before it reaches the mailbox, so the copy does not depend on user action. Check that the MTA journals messages that are rejected, quarantined or bounced by filters, because those can still be business communications. Ask the platform vendor how journal copies are signed, how delivery to the archive is retried on failure, and what the log shows when a copy is lost. The evidence to produce is a journal log that reconciles message counts between the MTA and the archive.

Archive store with immutability

The archive is the system of record for retained messages, so it needs write-once or equivalent controls that stop edits and early deletion before the retention period ends. Ask whether the store supports non-rewriteable, non-erasable storage or an audit-trail alternative, and who holds the keys that could alter it. Confirm how retention periods are assigned per message class and how the archive reports its own integrity checks. The evidence to produce is a retention policy export and immutability configuration that a third party can inspect.

Supervision review queues

Supervisory staff must sample and review messages against policy, such as lexicon hits, client communications and personal account use. Review queues need assigned reviewers, escalation paths and a recorded disposition for every flagged item, with reviewers unable to alter the original message. Confirm whether the archive or a separate compliance tool holds the queues, how sampling rates are set, and whether reviewer actions are logged. The evidence to produce is a completed review log with timestamps and the reviewer's decision for each flagged message.

eDiscovery and legal hold

Legal hold must suspend deletion for named custodians or matters, overriding normal retention expiry, and search must reach the archive, not only live mailboxes. Confirm how holds are applied and released, whether holds survive mailbox deletion or user offboarding, and how search results are exported with hash values and chain-of-custody records. Ask the vendor how search performance holds up across a large archive. The evidence to produce is a hold register and an export package that shows what was searched, when, and by whom.

Identity and MFA for archive access

Access to the archive, review queues and hold controls is the most sensitive permission in the stack, so it needs separate roles and multi-factor authentication. The FTC Safeguards Rule requires multi-factor authentication for any individual accessing an information system unless the Qualified Individual approves an equivalent control in writing, which applies to non-bank financial institutions under FTC jurisdiction. Confirm which directory the archive authenticates against, how administrator accounts are separated from reviewer accounts, and how privileged actions are logged. The evidence to produce is a role matrix and login logs tied to MFA events.

Backup with its own retention

Backups of the archive are records in their own right, so their retention, encryption and restore testing must match the preservation obligation rather than the mailbox backup schedule. Confirm how long backup copies live, whether they are immutable, where they are stored, and who can restore them without a hold check. Ask the vendor how a restore is validated against message counts and hashes. The evidence to produce is a backup policy, dated restore test records and proof that backups carry the same hold and retention status as the archive.

How a regulated mail rollout proceeds, phase by phase

The sequence turns mail into a documented, testable retention process: the regulated populations and message definitions are agreed first, then the archive, then the platform, and only then users move across.

Scope regulated populations and message definitions
Compliance, legal and records owners agree which users, shared mailboxes and business units fall under retention rules, and define what counts as a business communication, including inter-office messages and attachments. DeployOpen documents the agreed scope and the rule set in writing before any configuration starts. The step is done when compliance signs the scope document and every mailbox type has an owner and a retention category.
Select the archive and confirm journaling
Choose a separate, write-once or compliant archive that the mail server can journal into, and confirm in writing with the archive vendor how it stores originals, supports legal hold and meets the preservation requirements that apply to your firm. Ask the vendor which journaling method it supports and what it records for each message. The step is done when the archive vendor's compliance documentation is on file and the journaling method is tested against a sample message.
Build the mail platform in a non-production environment
Deploy the mail, calendar and contacts services in a staging environment with the same authentication, TLS settings, filtering and backup design planned for production. Record the configuration, versions and change history so auditors can trace how the platform was built. The step is done when the staging build passes functional tests for sending, receiving, calendars and client access, and the configuration is stored under version control.
Test journaling completeness
Send test traffic that covers internal, inter-office, inbound external, outbound external, forwarded, bcc and blind-copied messages, and mail with large or unusual attachments. Compare the messages in the mailboxes with the copies held in the archive, and check that metadata, timestamps and attachments survive the journey. The step is done when every test case has a matching archived record and the gaps, if any, are logged and closed with a retest.
Run legal hold and search drills
Run a simulated litigation or regulatory request: place a hold on a test custodian, search by sender, recipient, date range and keyword, export results and confirm that held messages cannot be deleted by users or administrators. Record who performed each step and how long the search and export took. The step is done when the drill output is reviewed by legal and compliance and any missing search fields or export formats are fixed.
Cut over with coexistence
Migrate mailboxes in waves while the existing system remains reachable, with mail routing and calendar free/busy working across both platforms during the transition. Keep journaling active for each wave from the first day the mailbox is live, and verify that no retention gap appears at the boundary. The step is done when every wave is migrated, the old system is in read-only or retired status according to the plan, and the archive shows continuous coverage.
Document the register and exit plan
Record the mail platform, archive and hosting locations as ICT services in the firm's register of information, with the data locations and contract terms that the register and the firm's contracts need. Write an exit strategy that covers moving mail and archive data to another provider, with tested export steps. The step is done when the register entry, the exit plan and the test evidence are approved by risk and the named owners, and they are scheduled for periodic review.

What examiners and auditors ask for, and which component produces it

This table maps the evidence that examiners and auditors typically request from a financial services mail platform to the component that generates it. Read it as a preparation list: each row names the artifact, the system that produces it, and the point where teams most often find gaps. DeployOpen prepares this evidence, but independent auditors and regulators decide whether it is sufficient.

Evidence requested	Producing component	Where gaps usually appear
Journaling completeness reports showing every business message reached the archive	Journaling from the mail server to a separate archive, with message counts reconciled against mailbox logs	Journal rules that skip shared, alias or delegated mailboxes, and no reconciliation job
Retention configuration exports showing preservation periods and legal hold settings	Archive platform retention policies, exported and version-controlled from the archive console	Retention set on mailboxes instead of the archive, or exports taken without a dated baseline
MFA enforcement settings for every mailbox and admin account	Identity provider and mail server authentication policy, exported with a timestamp	Legacy protocols such as basic authentication left enabled for some clients or service accounts
Mailbox access and administrative logs	Mail server audit logging forwarded to a central log platform with retention matched to policy	Logs stored only on the mail host, short retention, or admin actions not logged
DORA register of information entries for the mail platform and its providers	Contract and service register maintained by the firm, linked to hosting locations and data processing details	Missing hosting locations, subcontractors or data return terms in the contract file
DORA exit strategy test records for critical or important functions	Documented exit plan and dated test records covering archive export and mailbox migration	Exit plans written but never exercised, or archive formats not tested for readability
IT general control change records per the areas named in SEC Release 33-8810	Change management tickets, configuration version history and deployment records for the mail stack	Emergency changes applied directly to servers without a ticket or approval
Configuration baselines and hardening records for mail, archive and directory components	Version-controlled configuration repository and periodic drift reports	Baselines that exist as documents only, not matched against running systems

What financial firms ask before self-hosting business email

What drives the total cost of self-hosting business email at a financial firm?

The total cost is driven by the work around the mail server more than by the server itself. Cost components include infrastructure in your own cloud account or data center, a separate archive store sized for multi-year retention, spam and malware filtering, outbound relay or clean sending addresses, backup, migration, and the staff time that deliverability and archive administration take. Some costs are one-time, such as design, migration and archive integration. Others recur, such as storage growth, staff time, support and upgrades. If you use OX App Suite, ask for licensing terms in writing, because the Operations Guide states that certain modules or features may be subject to custom packaging, limitations or separate fees set in the license agreement. Ask any partner for a quote that separates these components and states which ones are recurring.

How long does it take to put a compliant archive in place?

The timeline depends on how fast your compliance and legal teams can define the retention rules, not only on how fast the technology can be installed. Before any build, confirm which communications must be preserved, for how long, in what format, and who can search them under legal hold. SEC Rule 17a-4(b)(4) requires broker-dealers to preserve originals of communications received and copies of communications sent relating to the business, including inter-office communications, for not less than three years. Journaling every message into a separate archive, testing search and legal hold, and running a documented acceptance test all take time that no supplied fact quantifies. Ask any partner to show a fixed-scope plan with written milestones and an acceptance test that your compliance team signs off on before cutover.

What must the firm supply before an implementation partner can start?

Before work starts, the firm needs to supply decisions that no platform can make for it. Compliance must define retention periods, supervision rules and which channels are in scope. Legal must define eDiscovery, legal hold and preservation procedures. The identity team must provide the directory, the sign-in method and the multi-factor approach. For a non-bank firm under the FTC Safeguards Rule, 16 CFR 314.4(c)(5) requires multi-factor authentication for any individual accessing any information system, unless the Qualified Individual approves an equivalent control in writing. Network and security teams must confirm DNS control, TLS policy, and where the infrastructure runs. Written decisions from each function reduce scope disputes and rework during the fixed-scope engagement.

Can our internal team run a self-hosted mail and archive platform alone?

Some firms can, but the answer depends on skills and capacity you can confirm inside your own team. Running mail well involves mail routing, DNS records for SPF, DKIM and DMARC, reputation monitoring, spam tuning, backup testing, and archive operations such as legal hold and export. Each area needs named owners with time allocated for on-call and patching. Teams often split the work: an internal team owns identity, retention decisions and access reviews, while an external partner handles build, hardening, integration, documentation and support under a retainer. Ask any partner which parts they would hand over and which they would keep, and what runbooks and training your staff would receive.

How do DORA contract terms apply to a self-hosted email provider?

DORA applies to in-scope financial entities regardless of whether the mail platform is self-hosted, so the firm still carries the obligations. DORA Article 28(3) requires a register of information on all contractual arrangements for ICT services. Article 30(2) requires every ICT services contract to state where services are provided and data processed, with advance notice of changes, and to cover data return on insolvency or termination of the provider. Article 28(8) requires documented, tested exit strategies for ICT services that support critical or important functions. If you engage a partner, the contract should cover these points, including the location of data, change notice, data return and exit support. Confirm with your legal and third-party risk teams how each clause maps to your engagement.

How do OX App Suite licensing and LTS timing affect planning?

Licensing and release support both shape the platform choice and the operating calendar. OX App Suite has a support commitment in which a standard release is supported for 12 weeks, ending with the availability of the third following release, while an LTS release is supported until the next LTS release plus six months. v8.47 (FCS 2026-03-18) is the current LTS, and v8.53, with first customer shipment on 2026-09-23, is the newest release listed in the support commitment. Plan upgrades against the support window, and confirm with the vendor which modules your edition includes, because the Operations Guide says some features may carry separate fees. Ask any partner how upgrades will be tested against your archive and journaling before each move.

Which technical controls will examiners ask to see from a self-hosted mail system?

Examiners and auditors typically ask for evidence of retention, access control, logging and change management rather than a specific product feature. Expect questions about who can read archived mail, how access is granted and reviewed, whether administrator actions are logged, how backups are restored and tested, and how changes to mail routing or retention rules are approved. For the archive, be ready to show journaling coverage, search results, legal hold records and proof of integrity. DeployOpen prepares systems, controls and evidence for compliance assessments, but it does not issue audit reports or attestations. Independent auditors and certification bodies make those determinations, so ask your auditor which evidence they expect before the build starts.

Should a financial firm keep the mail server and the archive on the same platform?

Most regulated firms keep the mail server and the archive as separate systems, with journaling copying every relevant message into an archive that is independent of mailbox users. This separation supports retention, legal hold and eDiscovery because users cannot delete or alter archived records through their mailboxes. It also means the mailbox server alone is not the record. Confirm with compliance counsel whether your retention obligations require this separation and how the archive must be stored, indexed and exported. Ask any partner to show how journaling, archive access and mailbox deletion behave in a test before you rely on them.

What to ask an implementation partner before signing

Start with the journaling test. Ask the partner to show how they prove that every business message from the mail server reaches the archive, including messages to and from external recipients, BCC'd copies, aliases, distribution lists and messages that fail delivery. Ask for the test plan, the sample size, the reconciliation method between mailbox counts and archive counts, and how a gap would be detected and reported. Ask who signs off the result and whether the signed record is part of the handover. Your compliance team should also confirm which retention periods apply to your firm, since the SEC rule sets a minimum of three years for the business communications it covers, and your supervisory procedures may set longer periods. Next, ask how archive administration is separated from mail administration. Ask which named roles can change journaling rules, delete or export archived items, place or release legal holds, and read archived content, and whether those roles sit in a different identity group with separate approvals and audit logs. Ask who holds the administrator credentials for the archive platform and where they are stored. Request the access matrix and the change procedure for the journaling connector. A partner that cannot separate these duties in writing will struggle to support a regulated firm's supervision and eDiscovery expectations. Finally, ask what evidence and contract documents you receive. Request a sample of the register of information entries that cover this service, the exit strategy and transition plan for the mail and archive components (DORA Article 28(3) and 28(8) apply if you are an EU financial entity), and the contract clauses on data location, notice of changes and data return on termination (Article 30(2)). For OX App Suite, confirm which Kubernetes and Istio versions the partner will support, how they track Helm chart and Redis or MariaDB upgrades, and how they handle a legal hold request raised during a support window, including who can act outside business hours and how the hold is confirmed in writing.

Where self-hosted financial email most often fails

Most failures in regulated mail are not caused by the mail server software. They come from assumptions that the mailbox is the archive, that every message gets captured, and that exceptions and exits will simply work. Each card below names one of these gaps and the control to verify before go-live.

The mailbox treated as the record

A mail server stores messages for delivery and user access, not for long-term preservation under a fixed policy. Users can delete items, and mailbox retention settings are often changed by administrators without a second review. For broker-dealers subject to SEC Rule 17a-4(b)(4), the preserved copy must be kept in a store that cannot be altered by the people who created the messages. Check that a separate, write-once or equivalent archive holds every business message and that deletion in the mailbox does not remove the archived copy.

Journaling gaps for BCC and lists

Journaling captures messages at the server, but gaps appear when mail reaches distribution lists, is expanded by a relay, or is delivered through a BCC path that skips the journal rule. Inter-office messages and messages sent through a secondary gateway are common blind spots. Ask for a test plan that sends messages through each path (direct, BCC, list expansion, forwarding and external relay) and confirms that each one appears in the archive with the correct envelope data.

Unmanaged MFA exceptions

Mail is a common entry point for account takeover, and a single legacy client or service account that bypasses multi-factor authentication can undo the rest of the control set. The FTC Safeguards Rule requires multi-factor authentication for any individual accessing an information system unless the Qualified Individual approves an equivalent control in writing. Check that every exception, including IMAP and SMTP app passwords, has a written approval, an owner, an expiry date and a log entry that can be reviewed.

Exit plans that were never tested

DORA Article 28(8) expects documented and tested exit strategies for ICT services that support critical or important functions, and Article 30(2) requires contracts to address data return on termination or insolvency. For a self-hosted mail platform, the exit test should export mailboxes, calendars and archive records into a second system and confirm that message headers, attachments and retention metadata survive. Ask the implementation partner to run this test on a copy of production data and record the result.

Unclear licensing for modules

Open-source core components are not always the full feature set. Open-Xchange's Operations Guide states that certain modules or features may be subject to custom packaging, limitations or separate fees set in the license agreement. Before design sign-off, list every function the business depends on, such as journaling, legal hold, mobile sync, or administrative audit, and confirm in writing which edition or license includes it and which is an add-on that recurs.

Outbound mail to client correspondence

Statements, confirmations and trade notices sent to clients must reach inboxes reliably. A newly self-hosted domain without aligned SPF, DKIM and DMARC records, or an IP address with poor reputation, can send legitimate correspondence to spam folders. Check that outbound mail is signed, that DMARC alignment is in enforcement mode after monitoring, that reverse DNS and TLS are in place, and that delivery reports from receiving providers are reviewed each week during rollout.

How DeployOpen scopes and supports financial email

DeployOpen is a Chainscore Labs company that plans, implements, hardens, backs up and documents self-hosted platforms inside the client's own infrastructure, whether that is their cloud account, data center or isolated network. For financial email, the work usually spans the mail platform, the journaling path to a separate archive, identity integration, access logging, backup and the runbooks a supervision or compliance team will ask for. The first decision is which of those pieces DeployOpen builds, which your team keeps, and which a third-party archiving product owns. That split should be written down before any configuration starts, because it decides who answers an examiner's question about where a message was preserved.

DeployOpen prepares systems, controls and evidence for compliance assessments, such as retention settings, journaling configuration, access records and tested restore procedures. It does not issue audit reports, attestations or certifications. Independent auditors, certification bodies and your own regulator-facing functions make those determinations, so ask any partner to show, in writing, which artifacts they will produce and which conclusions remain with you. Confirm with your compliance lead which evidence format your examiners or assessors expect before the scope is signed, since that changes how the documentation is structured.

Engagements are fixed-scope. Scope, deliverables, responsibilities and acceptance criteria are agreed in writing before work begins, and changes go through a written change request. Pricing follows from that written scope, and DeployOpen does not publish a price list, so ask for a quote that itemizes implementation, integration, archive connection, testing and handover separately. Ongoing support, upgrades and continuous security testing are available as retainers, which matter for financial email because mail stacks, TLS settings and filtering rules need regular maintenance. Agree in advance on response expectations, the upgrade process and who approves changes to journaling or retention rules.

Self-hosted email for financial services