Self-hosted email for healthcare

Why self-hosted email for healthcare starts with ePHI, not mailboxes

For a covered entity or business associate, the HIPAA Security Rule applies to every electronic protected health information (ePHI) message the mail platform creates, receives, maintains or transmits, so the mail platform falls within scope along with the clinical systems behind it. Under 45 CFR 164.312(e)(1), the mail system needs technical measures that guard against unauthorized access to ePHI sent over a network, and under 164.312(b) it needs audit controls that record and examine activity on systems holding ePHI. Moving clinical and administrative mail off a consumer or generic hosted service therefore means selecting a platform on its ability to enforce those controls, with delivery as a secondary test. The right choice depends on your scope and your staffing, because each candidate places a different share of the work on your team.

Stalwart, mailcow and OX App Suite are the main candidates, and they trade off differently. Stalwart is an all-in-one server supporting IMAP, JMAP, SMTP, CalDAV, CardDAV and WebDAV, licensed under AGPL-3.0 with an optional Enterprise License from Stalwart Labs, so confirm which features your controls depend on before you commit to the community edition. mailcow-dockerized, licensed under GPL-3.0, packages a full mail stack in containers and suits teams that already run and patch Docker hosts. OX App Suite v8 is designed for a Kubernetes cluster, is delivered as Helm charts, requires Istio or a basic ingress-nginx option, and depends on MariaDB, Redis and a distributed file system. Open-Xchange also states that certain modules may carry separate fees under the license agreement, so request that list in writing before you design around it.

There is no HIPAA certification for any mail platform. HHS states that no Security Rule standard requires an entity to certify compliance, and private certifications do not prevent HHS from later finding a violation, so the evidence is what your organization produces and can show the Office for Civil Rights. For ePHI mail, that evidence includes enforced TLS settings for external messages, mailbox access logs kept under your audit policy, and a business associate contract under 45 CFR 164.314(a)(2)(i) with any hosting or managed service provider. Start building that evidence file during design, and confirm with each vendor which logs they can export and how long those logs are retained.

Which HIPAA email requirements shape the build

This table maps the HIPAA Security Rule provisions that touch email to the design decisions they force on mail routing, TLS, logging, access and vendor contracts. Read each row as a requirement, what it means for the mail platform, and the evidence an assessor will ask to see. The main takeaway is that the Security Rule covers any ePHI the organization creates, receives, maintains or transmits, so mail routing and logs are in scope even when the mail server is run by a partner.

Requirement	What it means for the mail build	Evidence to prepare
Scope: ePHI created, received, maintained or transmitted (45 CFR 164.302)	Every mailbox, relay, archive and backup that holds patient content is in scope, not only the production mail server	Data flow diagram showing where ePHI enters, is stored and leaves the mail platform
Transmission security (45 CFR 164.312(e)(1))	Mail in transit must be guarded against unauthorized access, so external routes need enforced TLS and a defined fallback policy	TLS policy configuration, list of exceptions, and test results for inbound and outbound paths
Encryption specifications (addressable, 164.312(a)(2)(iv) and 164.312(e)(2)(ii))	Decide where encryption is required, such as external messages with ePHI, and document why an alternative is used if one is chosen	Written encryption decision, key management procedure and records of encrypted delivery
Audit controls (164.312(b))	Mailbox access, administrator actions and message routing events must be recorded and reviewed, so log forwarding to a protected store is needed	Log source inventory, retention settings, sample review records and alert rules
Unique user identification (164.312(a)(2)(i), required)	Each clinician, administrator and service account needs its own identity, so shared mailboxes need named delegation	Identity provider configuration, account list and delegation records
Automatic logoff (164.312(a)(2)(iii), addressable)	Webmail and mobile sessions should time out, and the chosen setting needs a documented rationale	Session timeout settings and the risk decision for each client type
Business associate terms (164.314(a)(2)(i))	A hosting or support provider that can access ePHI needs a contract requiring Security Rule compliance, subcontractor flow-down and incident reporting	Signed business associate agreement and a subcontractor list covering mail hosting and backup
Implementation specification count (Appendix A to Subpart C)	The rule lists 36 implementation specifications, 14 required and 22 addressable, so each email control maps to a documented decision	Control mapping that shows how each relevant specification is met or why it is not applicable

Covered entity or business associate: who carries the obligation

Covered health care providers, health plans and health care clearinghouses are the covered entities under the HIPAA Security Rule. They remain responsible for the security of the ePHI they create, receive, maintain or transmit, including email, even when they outsource the mail platform. Outsourcing moves operational work to a vendor. It does not move the accountability for risk analysis, access decisions and the technical safeguards in 45 CFR 164.312 that protect messages in transit and audit activity on mailboxes.

Ownership of the risk decision: The covered entity still decides which messages may carry ePHI, which external recipients are allowed, and whether patient content may be sent by email at all.
Safeguards in the mail flow: Enforced TLS for external messages, unique user identification for every mailbox and audit records of mailbox access remain the entity's obligations, even when a partner configures them.
Documentation the entity keeps: Policies, risk analysis results and the configuration baseline for the mail platform should be held by the covered entity, not only by the hosting partner.
Contract with each business associate: Under 45 CFR 164.308(b), the entity must obtain satisfactory assurances from any business associate before ePHI reaches it, documented through the contract required by 164.314(a).
Staff and access reviews: Internal staff who administer or read mailboxes still need role-based access and a process to remove access when people leave.

Before signing a hosting agreement, confirm with counsel which party is the covered entity for each mailbox, and which parties are business associates.

Which open-source mail platforms fit a healthcare workload

Three open-source mail platforms cover most healthcare requirements, but they differ in operating load and in how much of the HIPAA technical safeguard evidence they produce by default. Each card below sets out the fit, the operating burden and the specific checks to run on the version you intend to deploy before any ePHI moves through it.

Stalwart for lean deployments

Stalwart is a single all-in-one server that speaks IMAP, JMAP, SMTP, CalDAV, CardDAV and WebDAV, licensed under AGPL-3.0 with an optional Enterprise License from Stalwart Labs. Its small component count suits a clinic group or practice with a modest mailbox estate and a team that can own the server directly. Confirm with the vendor whether the version you select enforces TLS for outbound and inbound SMTP connections, how it exports mailbox access and administrative logs to your SIEM, and which features sit behind the Enterprise License.

mailcow for a Docker-based stack

mailcow-dockerized bundles Postfix, Dovecot, SOGo, Rspamd and ClamAV into a Docker Compose deployment licensed under GPL-3.0. It fits a healthcare IT team that already runs container hosts and wants a well-known component set with a clear update path. Verify the TLS policy settings for SMTP and IMAP in the release you deploy, confirm how Dovecot and Postfix logs are retained and forwarded for audit control review, and document who reviews mailbox access logs on a set schedule.

OX App Suite v8 for scaled estates

OX App Suite v8 runs on Kubernetes and is delivered as Helm charts that require Helm 3.17.0 or newer. It depends on Istio (or a basic ingress-nginx option where Istio cannot be used), MariaDB with InnoDB, Redis 7.4.x and a distributed file system for attachments. Plan on the v8.47 LTS line for production stability, and confirm that the modules you need for audit, retention and access logging are included in your license, since some features may carry separate license terms.

Audit log export as a selection test

Whichever platform you choose, the HIPAA audit controls standard expects mail activity touching ePHI to be recorded and reviewed, so log export is a selection criterion, not an afterthought. Ask each candidate for the fields recorded on login, message send and mailbox access events, the format and transport of those logs, and whether retention can be set independently of the mail server. Test an export into your log platform before you commit to a version.

Enforced TLS for external messages

The transmission security standard requires technical measures against unauthorized access to ePHI in transit, and encryption is an addressable specification that your risk analysis must address. For external patient correspondence, you need to decide whether TLS is opportunistic or enforced for named partner domains, and how that policy is set per domain on the chosen platform. Confirm the exact configuration keys and default behavior in the release you deploy, and test it against the receiving domains you expect to serve.

Support and upgrade ownership

Healthcare mail cannot run on an unpatched release for long, so the support model matters as much as the feature list. OX publishes a support commitment in which standard releases are supported for 12 weeks, while LTS releases are supported until the next LTS plus six months. Stalwart and mailcow rely on their own release cadence, so define in your contract who applies security updates, how quickly, and who tests them against your audit log and TLS configuration before rollout.

Deployment patterns for hospitals, clinics and business associates

A healthcare mail platform can run in the hospital data center, in the organization's own cloud account, or in a dedicated tenant operated by a business associate. Each pattern moves responsibility for hosting, access and backup to a different party, and each one changes what the covered entity must contract for and verify.

On-premises mail in the data center

The mail server, its storage and its backups sit in the hospital's own data center, under the same physical and network controls as the electronic health record. Staff already run that environment, so the main risks are staff capacity and single-site failure. Check how mail traffic leaves the site, how inbound TLS is enforced for external senders, and whether the mail host is covered by the same audit logging and access reviews as other ePHI systems. Ask who is on call for mail outages outside business hours.

Self-hosted in the organization's cloud account

The organization runs the mail platform in its own cloud account, with infrastructure as code, its own key management and its own logging. The covered entity keeps administrative control, but it also carries patching, certificate renewal and deliverability work. Confirm that the cloud provider is covered by a business associate agreement where the provider will hold ePHI, that encryption keys are managed by the organization, and that audit logs are shipped to storage the mail administrators cannot edit.

Dedicated tenant run by a business associate

A business associate operates a separate mail tenant for the clinic or hospital group, with its own domains, mailboxes and administrators. The business associate contract under 45 CFR 164.314(a)(2)(i) must require Security Rule compliance, flow the same terms to subcontractors that touch ePHI, and require reporting of security incidents. Ask for the tenant isolation model, the subcontractor list, and how the covered entity receives audit log extracts on request.

External care team access over VPN and MFA

Visiting specialists, home health staff and referring clinics often need mailbox access from outside the network. Require access through a VPN or a zero-trust gateway, with multi-factor authentication for every session, and limit each external account to the mailboxes and folders its care role needs. The CNIL's 2026 decision against a French hospital cited external access to a patient record system without VPN or multi-factor authentication, and that same gap applies to webmail for outside clinicians.

Identity integration with OIDC or SAML

Connect mailbox sign-in to the organization's identity provider using OpenID Connect or SAML where the chosen mail or groupware platform supports it, so that deprovisioning a clinician in the directory also removes mail access. Confirm which protocol each component supports, how group membership maps to mailbox roles, and what happens to cached sessions and app passwords when an account is disabled. Do not assume every protocol endpoint, such as IMAP or ActiveSync, honors the same single sign-on policy.

Backup location and recovery scope

Backups of mail that carries ePHI must be encrypted, stored in a location the business associate and covered entity have agreed in writing, and tested by restore. Decide whether backups stay in the same region as the primary, whether they are immutable, and who can request a restore of a single mailbox after a patient complaint or a misdirected message. Ask for the restore time objective, the retention period for backups separate from any archive, and how backup media is destroyed at end of life.

How a healthcare mail rollout is phased

The sequence moves from mapping which ePHI travels by email to a tested, logged and supported mail platform, with each phase closing on a written artifact that the security and compliance owners can review before the next phase starts.

Map ePHI flows and mailbox population
Start by inventorying where patient information enters and leaves email today: clinician-to-patient replies, referral correspondence, billing messages, lab notifications, shared clinic mailboxes and any personal devices or consumer services staff use for work. The team lists which mailboxes, distribution lists and external partners are in scope, and who owns each flow. The step is done when the data flow inventory is signed off by the privacy officer, the security lead and the clinical operations owner, and every flow is tagged as internal only, external, or patient-facing.
Run risk analysis and set the configuration baseline
Using the inventory, the security team performs a documented risk analysis covering transmission security, access control, audit controls and integrity of messages in transit, then writes a configuration baseline for the chosen platform. The baseline records how TLS is enforced for submission, delivery and client access, which certificates and cipher policies apply, how mailbox access is authenticated and logged, and how unique user identification is assigned. The step closes when the configuration record is approved and each baseline setting has a named owner and a test method.
Pilot with one limited care unit
Deploy the platform to a single care unit or clinic with a small, defined user group, and route only the agreed flows through it. The pilot checks real clinical correspondence patterns, including how staff send results to external referrers, how patients reply, and whether attachments are scanned and blocked when policy requires. Operations staff record issues and decide on changes to routing or filtering before any wider rollout. The pilot is complete when the issue log is reviewed, each open item is resolved or accepted in writing, and the clinical lead confirms the workflow is usable.
Validate enforced TLS and mailbox logging
Test the baseline against the controls it claims to meet. Confirm that external messages are sent only over encrypted sessions where policy requires it, that connections failing the policy are refused or handled as the baseline states, and that mailbox access, administrative changes and message handling events are written to logs that cannot be silently altered and that reach a central store. Test log review procedures with the people who will perform them. The output is a test evidence pack with the test cases, results, screenshots or exported log samples, and the names of the reviewers who signed each result.
Migrate mailboxes and cut over
Move mailboxes, calendars and contacts in batches so that each group has a rollback point and a defined window of coexistence. Update DNS records, client profiles and mobile configuration, and retire forwarding from the old service only after mail flow and access tests pass for that batch. Keep the old archive or retention copy available until the records owner confirms that retained messages are accounted for. The cutover record lists each batch, the migration checks run, mail flow results, rollback decisions and the date each legacy route was closed.
Operate and track releases
After cutover, the platform moves into routine operations: monitoring of mail flow and certificate expiry, scheduled log review, access recertification for shared and clinical mailboxes, backup restore tests and documented patching. The team tracks upstream and vendor release notes, assesses security fixes, and applies them through the change process with the configuration baseline updated to match. The step is ongoing, and the evidence it produces, including change records, review logs and restore test results, is kept current so that a later assessment can be answered from the record.

Evidence an auditor or regulator will ask for from mail

This table lists the evidence items a HIPAA assessor, covered entity or regulator is likely to request about a self-hosted mail platform, the component that produces each item, and what to confirm before the request arrives. Read it as a collection checklist: DeployOpen can prepare these records and controls, but independent auditors and regulators make the assessment, and no HIPAA certification exists.

Evidence item	Producing component	What to confirm before the request
TLS policy and test results for external transmission	Mail server (Stalwart, mailcow or OX App Suite) and an external TLS test	Which minimum TLS versions and cipher settings are enforced, and whether enforcement is mandatory or opportunistic for each external domain
Mailbox access and administrator audit logs with retention	Mail server logs, forwarded to a central log store	Whether logins, IMAP and JMAP access, and admin changes are recorded, and how long logs are kept under the organization's own retention policy
Unique user identification records	Identity provider and mail directory	That each mailbox maps to one named user, that shared mailboxes are documented, and who approves account creation and removal
Business associate agreements with subcontractor flow-down	Contracts held by the covered entity or business associate	That the mail hosting partner, backup vendor and any relay provider sign agreements that require Security Rule compliance and incident reporting
Risk analysis and risk management records	The organization's risk register, with DeployOpen supplying system documentation	That the mail platform, its data flows and its external dependencies are covered in the enterprise risk analysis and updated after changes
Backup and restore test records	Backup software and restore procedures, run by the operator	Dated restore tests of mailboxes and the archive, with recovered results checked against source data
Change records for upgrades and configuration	Change tickets, version control for configuration, and release notes from the platform vendor	Which releases are running, when they were applied, who approved them, and whether security patches were tested before deployment

Keeping patient communication off consumer mail services

Staff forwarding ePHI to consumer accounts is one of the most common ways patient data leaves a controlled environment, and a self-hosted mail server does not stop it on its own. A clinician who forwards a discharge summary to a personal Gmail or Outlook account, or who replies to a patient from a phone app signed into a consumer account, has moved ePHI outside the controls that 45 CFR 164.312(e)(1) expects you to apply to transmissions. The first decision is therefore policy: define which categories of patient information may leave the organization by email at all, which recipients are allowed, and which channel is the approved one for each case. Written policy is the starting point for the access and transmission controls the HIPAA Security Rule requires, and your auditors will ask to see it alongside the technical settings that enforce it.

The enforcement layer has three parts. First, a secure messaging or patient portal workflow on your own infrastructure gives clinicians an approved route for patient communication, so that a sanctioned path exists before you block the unsanctioned one. Second, data loss prevention and mail filtering rules on the self-hosted platform should detect identifiers and clinical terms in outbound messages and attachments, then hold, encrypt or block them according to policy. Confirm with your mail platform vendor which DLP rules it supports natively and which require a separate gateway, because the detection quality and false positive rate will drive how clinicians experience the control. Third, outbound connectors and relay settings must not allow a user's mail client to send to consumer domains through an unmonitored path. Log every rule hit, because the audit controls in 45 CFR 164.312(b) require you to record and examine activity in systems that hold ePHI.

The CNIL's decision against Hopital Prive de la Loire, which imposed a fine of EUR 500,000 under GDPR Articles 32 and 34 on 3 September 2026, shows what happens when access control fails in the same way. The regulator found that external access to the patient record system lacked VPN and multi-factor authentication, and that access rights ignored the care team's need to know. The lesson for email is that a mailbox reachable from anywhere, with no second factor and no role-based limit on who can see which patient correspondence, creates the same exposure. Before go-live, confirm that remote webmail and mobile access require multi-factor authentication, that shared or departmental mailboxes are restricted to the staff who need them, and that access reviews are scheduled and documented.

Questions healthcare teams ask before self-hosting mail

Is self-hosted mail HIPAA compliant?

HIPAA does not certify software or hosting platforms, so no mail server is compliant on its own. The Security Rule applies to the covered entity or business associate that creates, receives, maintains or transmits ePHI. For email, 45 CFR 164.312(e)(1) requires technical measures that guard against unauthorized access to ePHI sent over an electronic network, and 164.312(b) requires audit controls that record and examine activity in systems holding ePHI. A self-hosted deployment can meet these needs with enforced TLS for external messages, mailbox access logging and retained audit records, but the organization must document how each control is implemented and tested. HHS states that no standard requires certification, and private certifications do not prevent HHS from later finding a violation. Confirm the controls against your own risk analysis and your counsel's reading of the rule.

What drives the cost of self-hosting healthcare email?

Cost falls into a few components, and each has a different payer. Staffing is usually the largest recurring line, covering administrators who run mail, handle deliverability and respond to incidents. Licensing applies only if you choose a commercial edition or add-on modules; Open-Xchange notes that some modules may carry separate fees set in the license agreement. Archiving, backup and high availability add infrastructure and storage that recur every year, and retention periods lengthen that storage over time. One-time costs include design, migration, and the initial configuration of TLS, logging and identity integration. Ask any partner for a quote that separates these items, states which parts recur, and names who holds each license.

How long does a healthcare mail rollout take?

The duration depends on the size of the estate, the number of systems that send or receive ePHI, and how much of the design is already settled. The main dependencies are the ePHI inventory, the policies that define acceptable use of external email, the identity source for mailboxes and administrators, and the migration plan for existing archives. Compliance evidence, such as logging and access reviews, usually needs a period of operation before it can be assessed. DeployOpen plans and implements these systems under a fixed scope with a written timeline agreed before work starts, so ask for that timeline to be tied to each dependency listed in the scope.

What must our organization supply before a self-hosted mail project starts?

The organization supplies the decisions and the access that no implementation partner can make alone. Start with an inventory of where ePHI appears in email, including clinical referrals, billing, scheduling and patient messages, and which teams send it. Provide written policies for encryption of external messages, retention, access reviews and patient communication. Identity is the other critical input: the mail platform needs an authoritative directory, named administrators and a process for joiners and leavers. Business associate contracts under 45 CFR 164.314(a)(2)(i) should be in place with any partner that handles ePHI, so confirm them early.

Can our internal IT team run a self-hosted healthcare mail server?

Yes, many teams run mail servers internally, but the workload is specialized. Day-to-day operation includes patching, certificate renewal, spam and malware tuning, monitoring of sender reputation through DMARC reports, and restoring mailboxes from backup. Those tasks need named staff with mail and security skills, and at least one person must be able to respond during an outage. Teams that lack this depth often use a partner for design, hardening and documentation, then operate the platform in-house or on a retainer. DeployOpen offers ongoing support and upgrades as retainers, so the choice between in-house and partner operation can be decided against your staffing.

What is the HIPAA civil money penalty range for email failures?

For penalties assessed on or after 28 January 2026, the inflation-adjusted HIPAA civil money penalty under 45 CFR 102.3 ranges from $145 per violation to $2,190,294 per violation, with a calendar-year cap of $2,190,294. The range is set by the penalty tiers in that table, and actual amounts depend on the facts, the culpability level and the entity's response. Treat the figure as context for risk planning, not as a prediction. Unencrypted external email carrying ePHI or unlogged mailbox access are the kinds of gaps that a complaint or compliance review can surface.

Should patient communication stay off consumer mail services?

Patient communication that contains ePHI should run through systems the covered entity controls, with its own logging, encryption and retention. Consumer mail services may not sign a business associate contract, may not enforce the transport controls you require, and may not give you audit records in the form you need. Confirm whether any consumer service is in use today, including personal accounts that staff forward to, and treat that as a finding to remediate. Work with your compliance lead to define which messages may leave the organization and through which channel.

What to ask an implementation partner for healthcare mail

Start by asking the partner to show, in writing, how each 164.312 technical safeguard maps to a specific configuration on the mail platform. The HIPAA Security Rule's technical standards in 45 CFR 164.312 cover unique user identification, emergency access, automatic logoff, and encryption and integrity controls for ePHI in transit and at rest. Ask which of these become settings in OX App Suite, the MTA and mailbox store, and the directory, and which are handled by procedure. Ask for the mapping as a control matrix you can keep with your risk analysis, and ask which items the partner considers addressable and what documented decision they recommend for each. Confirm with the partner that the mapping will be reviewed when the Security Rule changes, since the proposed revision published in the Federal Register on 6 January 2025 has not been finalized as of October 2026.

Next, ask how the partner enforces TLS for external messages, including whether opportunistic TLS is refused or downgraded for domains you designate, how certificate chains are validated for partner domains, and how the mail platform records the protocol and cipher used for each delivery. Ask how mailbox access is logged for both user and administrator actions, where those logs are shipped, who can read them, and how the partner tests that logs are complete by replaying a sample of access events. For audit controls under 164.312(b), ask for the retention period the partner recommends, how logs are protected from change, and how a restore of the log store is tested. Ask about business associate terms as well: the partner should confirm in writing that it is bound by a business associate agreement under 45 CFR 164.314(a)(2)(i), list every subcontractor that can reach ePHI (including backup, relay and hosting providers), and explain how it reports security incidents to you. Finally, ask how the partner tests restores of mailboxes and audit logs on a set schedule, and how it will support upgrades within the OX App Suite LTS timing, so your change board can plan testing before a release leaves support.

How DeployOpen scopes and supports healthcare mail

DeployOpen is a Chainscore Labs company that builds and supports self-hosted mail inside your own infrastructure. The cards below cover what we scope, what we harden, what evidence we prepare and how the work continues after go-live.

Fixed-scope engagement with written scope

Most engagements are fixed-scope, so the mail domains, mailbox counts, integrations, deliverables and timelines are agreed in writing before work starts. For healthcare, the scope should name which mailboxes and flows carry ePHI, which external recipients are in scope, and which systems must log access. Ask for the written scope to list what is excluded, such as the EHR, patient portal or archive, so the boundary is clear at signing.

Implementation and hardening in your environment

DeployOpen plans, implements and hardens the mail platform in your cloud accounts, data center or private network, so messages and mailbox data stay under your control. Hardening covers enforced TLS for external messages, access restrictions for administrative interfaces and separation of mail administration from clinical systems. Confirm which mail server and which edition you will run, and whether the chosen components support the encryption and logging you need.

Audit logging and mailbox access evidence

We configure logging of administrative actions and mailbox access, forward logs to your central store and set retention for them. The HIPAA Security Rule requires audit controls that record and examine activity in systems containing ePHI, so the evidence must be reviewable, not just generated. Ask how logs are protected from tampering, who reviews them and how long they are kept under your policy.

Compliance readiness without attestation

DeployOpen prepares systems, configuration records, policies and evidence for your compliance assessments. We do not issue audit reports, attestations or certifications, and HIPAA has no certification. Independent auditors, HHS enforcement and your own risk analysis decide compliance status. Ask your partner to map each control to a specific configuration or record you can show an assessor.

Backup, documentation and handover

Each engagement includes the backup design, restore testing plan and runbooks needed to operate mail without us. Documentation should cover mail flow, encryption settings, certificate renewal and the process for handling a misdirected patient message. Confirm that restore tests are scheduled and that the handover includes administrator training and written procedures your staff can follow.

Retainers for support, upgrades and testing

After go-live, ongoing support, upgrades and continuous security testing are available as retainers. Mail platforms need regular patching, certificate maintenance and review of changes that affect encryption or logging. Ask for the retainer's response expectations, upgrade process and how security testing results are reported to your security team before you sign.