Approved message route

HIPAA email setup that gives every message a safe route.

A business email platform is only the starting point. A medical practice still needs to decide who owns each mailbox, when PHI may appear, which destination is approved, what safeguards apply, and what record proves the handoff was controlled.

Privacy choice: Essential site functions stay on. Optional measurement loads only if you allow it.

Representative messageRoute before send
No real patient data shown
01Source02Content03Destination04Owner + record

The route changes with the message. An appointment reminder, referral packet, patient attachment, billing file, and vendor screenshot should not inherit one blanket rule.

Published May 20, 2026 · Updated September 18, 2026 · Written and technically reviewed by
Start here

Email is not one yes-or-no channel.

HHS permits electronic communication with reasonable safeguards, while the Security Rule requires appropriate administrative, physical, and technical safeguards for ePHI. The practical setup job is to define permitted routes, not to label one product “HIPAA compliant.”

Short answer

A BAA, encryption feature, or business plan does not finish the setup. The practice must connect platform scope, risk analysis, access, patient preferences, workforce rules, approved alternatives, incident handling, and documented ownership.

  1. 1Where can PHI enter or leave?Messages, subject lines, attachments, scans, signatures, and replies
  2. 2Who owns each mailbox and account?Named users, shared functions, administrators, delegates, and leavers
  3. 3Which destinations and tools are approved?Email, patient portal, Direct messaging, fax, phone, mail, or vendor portal
  4. 4What changes when a patient chooses ordinary email?Preference, warning, minimum content, address verification, and documentation
  5. 5What evidence shows the route is controlled?BAA record, access review, domain records, policy, training, and exception log
Representative workflows

Give the message a route before staff press send.

This ledger is a planning aid, not a universal policy. The practice's risk analysis, legal/compliance guidance, contracts, systems, patient request, and clinical or records responsibilities determine the approved route.

MessagePreferred route questionControlOwner record
Low-detail noticeAppointment reminderKeep content limited and avoid unnecessary clinical detail.
Approved reminder platform or bounded email/SMS workflowConfirm the destination and communication rule.
Template + address checkLimit what the reminder reveals.
Front-desk ownerApproved template and exception path
Inbound patient fileInsurance card, form, or photoA patient may initiate email, but the practice still owns what happens next.
Move to the approved intake or record pathAvoid leaving the only copy in a personal inbox or ad hoc folder.
Identity + destination + cleanupApply the practice's records procedure.
Intake ownerReceipt and handoff record
Clinical handoffReferral or provider documentConfirm the actual recipient, system, and workflow.
Approved secure exchange, portal, Direct route, fax, or other scoped pathDo not assume the ordinary mailbox is the correct clinical route.
Minimum necessary + verified destinationUse a known contact path.
Referral ownerSend/receipt follow-through
Revenue cycleBilling or authorization attachmentMatch content and destination to a defined business workflow.
Approved payer, portal, clearinghouse, or protected message pathAccount for downstream processors and contract scope.
Role access + attachment handlingPrevent uncontrolled local copies.
Billing ownerSubmission and exception record
Vendor supportScreenshot, log, or troubleshooting requestSupport artifacts can expose names, messages, schedules, or credentials.
Sanitized artifact through an approved support channelUse the vendor and system path defined for the engagement.
Remove PHI and secretsConfirm authorization before access.
System sponsorTicket, approval, and closeout

Do not copy these examples into policy without review. State law, specialty rules, payer or vendor contracts, records obligations, and the facts of a patient request may change the appropriate route.

Platform gate

A BAA defines obligations. It does not configure the tenant.

HHS explains that a cloud provider handling ePHI generally needs an appropriate business associate agreement, while the covered entity or business associate must still understand the environment, conduct risk analysis, and establish risk-management policies.

1

Confirm the exact service and plan

Record the legal customer, covered service, included features, exclusions, renewal owner, and where the BAA is stored.

2

Keep admin access separate

Use named accounts, limit privileged roles, protect emergency access, and avoid shared administrator credentials.

3

Define the mailbox lifecycle

Approve creation, delegation, shared mailbox access, forwarding, mobile use, offboarding, retention, and recovery ownership.

4

Map every connected sender

Include scanners, EHR notices, scheduling tools, website forms, billing systems, vendors, and applications that send as the domain.

5

Choose usable secure alternatives

Staff need usable portal, Direct, fax, phone, mail, or vendor routes when ordinary email is not the chosen path.

6

Keep an evidence file

Retain the BAA record, risk decision, account review, configuration evidence, domain reports, training, exceptions, and remediation owners.

Identity and domain controls

Protect the account, the mailbox, and the domain together.

MFA can reduce account-compromise risk, but it does not replace mailbox review, authorized sender inventory, user lifecycle, device safeguards, or an approved response path.

1

Identity

Require strong MFA, prioritize phishing-resistant methods where appropriate, and protect privileged access.

2

Mailbox

Review delegates, shared access, forwarding rules, inbox rules, recovery methods, and dormant accounts.

3

Device

Connect email access to screen lock, patching, encryption, approved apps, and lost-device procedures.

4

Domain

Inventory legitimate senders, publish SPF and DKIM correctly, monitor DMARC, and tighten policy deliberately.

5

Response

Define who disables access, reviews sessions and rules, preserves needed records, resets credentials, and escalates.

Why SPF, DKIM, and DMARC matter

These controls help receiving systems evaluate whether a sender is authorized and whether a message aligns with the visible domain. They reduce domain spoofing risk when correctly deployed, but they do not encrypt message content, approve a workflow, stop display-name impersonation, or make every connected sender safe.

Patient communication

Patient preference belongs inside the route, not outside it.

HHS says providers may communicate with patients by email with reasonable safeguards. It also explains that patients may initiate email and may request alternative communication, while the provider should consider privacy risks and offer more secure methods when appropriate.

Before sending

Verify the address and request

Use the practice's approved process to confirm the destination, communication preference, representative authority, and any confidential-communication request.

Choose content

Limit what the message reveals

Use the least detail needed for the purpose. Subject lines, filenames, signatures, quoted replies, and attachments can reveal more than intended.

Offer a route

Make the secure option usable

Explain the portal or approved alternative in plain language. A policy that staff and patients cannot follow will create workarounds.

HealthDesk can help plan

Tenant access, MFA, shared mailboxes, forwarding, domain authentication, approved workflow mapping, staff-ready procedures, and evidence ownership.

Active events need the current response route

If an account, device, patient message, payment, or ePHI may be affected now, use the practice's approved response process and current provider, insurer, privacy, legal, vendor, and regulatory resources. This page does not start incident response.

Visible answers

Common email setup questions.

These answers provide orientation, not a legal conclusion or a substitute for the practice's risk analysis, policy, contracts, and professional advice.

Can a medical practice use email for PHI?

HIPAA does not create a blanket ban on email. HHS describes reasonable safeguards for patient email and requires the Security Rule's safeguards for ePHI. The appropriate route depends on the message, risk, recipient, workflow, and documented controls.

What does HIPAA-compliant Office 365 require?

Office 365 can support HIPAA safeguards, but a subscription or BAA alone does not establish compliance. Confirm that the services you use are covered by the applicable agreement, then review administrator access, MFA, mailbox permissions, forwarding, audit visibility, and approved ways to send sensitive information. Available controls depend on the product and license. The practice still needs risk analysis, policies, workforce procedures, and ongoing review. See Microsoft's HIPAA and HITECH guidance. For an existing tenant, request a Microsoft 365 management review.

Does a BAA finish the email setup?

No single agreement or product setting establishes compliance. A BAA addresses the vendor relationship; the practice still needs risk analysis, appropriate safeguards, permitted-use decisions, access control, workforce procedures, and ongoing review.

Should staff use one shared password?

Prefer named accounts and approved shared-mailbox delegation so access can be granted, reviewed, removed, and attributed. Avoid a common password that hides individual ownership or remains active after staff changes.

Do SPF, DKIM, and DMARC encrypt messages?

No. They help authenticate sending domains and reduce some spoofing risk. They do not encrypt message content, confirm a recipient, approve PHI use, or replace MFA and mailbox controls.

What if a patient starts the conversation by ordinary email?

HHS says a provider may generally infer that email is acceptable unless the patient states otherwise, but the practice should still follow its safeguards, consider whether the patient understands the risk, limit content, and offer a more secure route when appropriate.

What should a small practice review first?

Start with mailbox ownership, administrator roles, MFA, forwarding and inbox rules, leavers, approved patient and referral routes, scanner and application senders, BAA records, SPF/DKIM/DMARC status, and the current account-compromise procedure.

Primary sources

Read the rule and guidance behind the route.

HealthDesk does not certify products or legal outcomes. These current government sources support the bounded statements above; implementation must be evaluated in the practice's actual environment.

Scoped planning request

Review the route before changing the mailbox.

Share the platform, broad workflow, approximate user count, and the decision that needs an owner. Keep patient information and sensitive technical material out of this form.

  • No PHI, patient names, email addresses, screenshots, headers, attachments, credentials, or confidential agreements
  • This request does not start incident response, legal review, breach analysis, or system access
  • Active account or ePHI events should use the practice's approved response route

Email or phone is required. Submission does not create a client relationship, authorize access, establish compliance, or guarantee an outcome.