Self-hosted email for HIPAA

The risk analysis itself is the covered entity's document, and it must cover every system that stores or transmits ePHI, including mail. For the mail platform, the record should list where ePHI travels (client to server, server to server, server to external recipients), who can reach mailboxes and the admin console, and the threats and likelihood for each path. HHS OCR's risk analysis guidance names deciding whether and how to use encryption as a decision the analysis should inform, so the mail entries should link to the encryption decision described below. Each identified risk should carry a documented treatment, owner and review date. DeployOpen can help prepare the mail system inventory and data flow diagrams that feed this analysis, but the analysis must be owned and signed off by the entity. Confirm the expected format with your privacy officer and compliance lead before work starts.

Under 45 CFR 164.306(d)(3), encryption for transmitted ePHI is an addressable specification, so the entity must assess whether it is reasonable and appropriate. If it is, the record should name the mechanism, such as enforced TLS for SMTP and TLS for IMAP, JMAP and webmail. If it is not, the record must explain why and describe an equivalent alternative measure that is reasonable and appropriate. The assessment should reference the risk analysis and be approved by a named owner. Most self-hosted email designs will find encryption in transit reasonable, so the document should focus on how it is enforced for external recipients, including what happens when a remote server does not support TLS. NIST SP 800-52 covers TLS and is listed by HHS as informational guidance. Your team should confirm the final wording with counsel.

Auditors and OCR investigators typically ask for a current list of every mail endpoint and the protocols and cipher configuration each one accepts. The inventory should cover SMTP submission, SMTP between servers, IMAP, JMAP, CalDAV, CardDAV and the webmail front end, with the certificate subject, issuer, expiry date and renewal owner for each. Evidence includes scan output from a TLS testing tool run against each endpoint, the minimum protocol version set in the configuration, and the policy for enforcing TLS to external domains. For a self-hosted platform, the certificate inventory is maintained by the operator, so it must be generated and kept current, not reconstructed at audit time. DeployOpen configures and documents these settings and can produce the inventory as part of hardening. Confirm with the entity which TLS baseline it wants to adopt.

Evidence for DKIM and DMARC is produced by the mail platform's signing configuration and by the aggregate and forensic reports that receiving mail systems send back. The platform should hold the DKIM selector records, key length and key rotation log, plus the published DMARC policy and its reporting addresses. The DMARC aggregate reports, which receivers send to the address in the policy, show which sources send mail for the domain and whether it passes alignment. Keep these reports for the period the entity's retention policy sets, and record how unauthorized senders were investigated and closed. HIPAA does not name DMARC, so these artifacts support the integrity and transmission safeguards rather than satisfy a named requirement. Confirm with your security team how long reports are retained.

The audit control standard, 45 CFR 164.312(b), requires mechanisms that record and examine activity in systems containing ePHI. For mail, that means logs of mailbox logins and failures, IMAP, JMAP and webmail sessions, delegated and shared mailbox access, administrative changes to accounts, domains, routing and forwarding rules, and the logs of the security tools that filter mail. The entity must set how long these logs are kept and who reviews them, and the review itself is evidence. Logs should be forwarded off the mail host to a central store so an administrator cannot silently alter them. Automatic forwarding and external auto-forward rules deserve specific review because they move ePHI outside the system. Confirm with your SIEM team which events the platform can emit and how they are shipped. DeployOpen can set up log forwarding and review procedures as part of an implementation.

Auditors will expect a change record for each material update to the mail platform, including software upgrades, security patches, configuration changes to TLS, filtering, routing and authentication, and changes to access control. Each record should state the reason, the approver, the test performed, the date applied, the rollback plan and the result. The record for security patches should reference the vendor release and the date it was applied so the time between disclosure and deployment can be shown. Configuration should live in version control so the state at any date can be reconstructed. For open-source components, record the exact release used, such as the version number published by the project, and keep the release notes. DeployOpen can run upgrades under a written scope and document each change, but the entity's change board still approves production changes.

The Security Rule's contingency and data integrity expectations are met partly by proving that mail data can be restored. The evidence is a backup policy that states what is backed up (mailboxes, configuration, database, encryption keys, and certificates), how often, where copies are stored and how they are encrypted, and the retention period. A backup is only evidence once a restore test has been run, so keep dated restore test records showing the scope, the time taken, the mailboxes checked and the issues found. Include the key material needed to decrypt backups, stored separately under access control. NIST SP 800-66 Rev. 2 gives sample questions on contingency planning that can structure the test record. DeployOpen can plan and run restore tests under a fixed scope, but the recovery objectives must be set by the entity.

A business associate agreement is required when a vendor creates, receives, maintains or transmits ePHI on behalf of a covered entity or another business associate, and this covers a hosting or support partner that can reach mail data. Under the Security Rule, business associates must comply with the rule for electronic PHI (45 CFR 164.302), so the agreement should require safeguards, incident reporting and subcontractor flow-down. The entity should list every party with administrative or technical access, including any managed backup provider, relay or spam filtering service, and confirm each has a signed agreement. If the implementation partner only builds and documents the system and never accesses ePHI, its role should be recorded and the access limits written down. Confirm the agreement terms with counsel, since HHS does not publish standard BAA language.

A self-hosted mail server can be operated in a way that supports HIPAA obligations, but no product or hosting model is certified as HIPAA compliant. HHS states that no Security Rule standard requires certification and that it does not endorse or recognize private certifications. Compliance is a documented program: a risk analysis, the transmission security and audit controls under 45 CFR 164.312, written policies, workforce training, and evidence that the controls operate. The mail platform is one part of that program. Your own covered entity or business associate status, and the agreements you hold with partners, also shape what you must do.

Cost is set by the written scope, not by a published price. DeployOpen does not publish a price list, and most engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts. The main drivers are the platform choice, the number of mailboxes and domains, how much TLS and encryption enforcement you need for external recipients, the design of mailbox access logging, whether you add a separate archive, the number of integrations with identity, ticketing or backup, and how much documentation the assessment will ask for. Ongoing operations, patching and any support retainer recur. Ask for a quote that separates one-time build work from recurring operation, and that names who pays for hardware, licenses and third-party services.

The duration depends on the scope, the existing mail estate and how quickly your policy owners and approvers respond, so no fixed timeline applies. A rollout usually moves through risk analysis input, design, a pilot group, migration, logging validation and handover. Each stage has dependencies on your change windows and DNS and certificate work. Ask for a written plan with milestones, the decisions required from your side at each stage, and the acceptance criteria for each deliverable. Be cautious of any partner who quotes a duration before reviewing your environment and requirements.

Your team supplies the decisions and access that only your organization can give. The most important input is your risk analysis, including whether and how encryption is used for ePHI in email, which HHS OCR guidance names as a decision the risk analysis should inform. You also need named owners for policies, retention, access approval and incident response, plus DNS administration for MX, SPF, DKIM and DMARC records and access to the certificate authority or public certificate process. Expect to provide directory and identity details, a list of mailboxes and external partners who exchange ePHI, and approval for logging and archive retention periods.

An internal team can run self-hosted mail if it has the skills and time to operate it, but the compliance work is a separate effort that requires documentation discipline. Mail operations involve deliverability, spam and malware filtering, certificate renewal, backups, patching and migration, and each needs a named owner. For HIPAA, you also need to show that encryption and integrity decisions were assessed, that audit controls record and examine activity on systems containing ePHI, and that the program is documented. Many teams split the work, keeping day-to-day administration in-house while bringing in a partner for the design, the controls evidence and periodic testing. DeployOpen plans, implements, hardens and documents self-hosted platforms in your environment, and can be engaged for any of those parts under a written scope.

Civil money penalties are set per violation and capped per calendar year, with the amounts adjusted for inflation. For penalties assessed on or after January 28, 2026, 45 CFR 102.3 sets the inflation-adjusted amount for violations on or after February 18, 2009 at a range from $145 per violation (no knowledge) to $2,190,294 per violation (uncorrected willful neglect), with a calendar-year cap of $2,190,294. The actual amount depends on the culpability tier, how quickly the violation was corrected and the facts of the case. Because penalties scale with how long a gap persists, documented risk analysis, prompt correction and evidence of control operation matter. HHS OCR enforces the Security Rule through complaints, compliance reviews and audits, so keep your records current.

The transmission security standard in 45 CFR 164.312(e)(1) requires technical measures that guard against unauthorized access to ePHI sent over an electronic communications network. Its two implementation specifications cover integrity controls, which address detecting improper modification of transmitted ePHI, and encryption, which calls for a mechanism to encrypt ePHI when deemed appropriate. Both are addressable, meaning you must assess them, implement them if reasonable and appropriate, and otherwise document the reason and implement an equivalent measure. Audit controls under 45 CFR 164.312(b) require records and examination of activity in systems containing ePHI. Ask your partner to map each control to a specific configuration, log source and evidence artifact.