[mh_key_takeaways]
To encrypt an email is to convert the message body and attachments into ciphertext before sending. The mail servers in between see only scrambled data. Only a recipient with the correct key or credential can read the content.
This guide explains what encryption means in practical terms, how an encrypted email looks to sender and recipient, and when a dedicated encrypted email service fits better than the built-in options in Outlook or Gmail.
The details vary by platform. The underlying protection is the same. Content is unreadable to anyone without the correct decryption key or authentication credential.
Encryption Converts Message Content Into Ciphertext
Encryption applies a mathematical algorithm to the message body and attachments. The algorithm uses a key to scramble the content into ciphertext. Only a matching key or credential can reverse the process and produce readable content.
The sender does not see the ciphertext. The compose window looks the same as a normal message. The encryption applies at send time, either automatically based on a policy or manually by clicking an Encrypt option.
The recipient does not see the ciphertext either. The mail client or portal decrypts before display. What both parties see is a normal-looking message with a lock icon or policy label that confirms encryption was applied.
The ciphertext exists on the wire between servers and at rest on the sending platform. Anyone who intercepts the traffic or gains access to the storage sees only scrambled data.
Three Layers of Encryption Cover Different Threats
Email encryption applies at three possible layers. Transport encryption between mail servers uses TLS. Message-level encryption uses S/MIME or PGP. Portal-based encryption stores encrypted messages on a server and delivers a link to the recipient.
TLS protects the message during network transmission. It does not protect the message at rest on the sending or receiving mail server. TLS is the baseline, not the full solution for regulated content.
Message-level encryption protects the content from the sender client to the recipient client. Servers in between see ciphertext. This is true end-to-end encryption and it fits scenarios where both parties can hold cryptographic keys.
Portal-based encryption sits between the two. The sending platform holds the encrypted content and manages authentication. The recipient reads the message in a browser session after signing in or entering a one-time passcode.
The Sender View Looks Almost Identical to Regular Mail
The sender view of an encrypted email is nearly the same as a normal email. The compose window uses the same fields, the same formatting, and the same attachment controls. The one difference is a lock icon or a policy label on the message.
In Outlook, the sender clicks Options, then Encrypt, and picks a policy. In Gmail on Workspace with client-side encryption, the sender clicks a lock icon in the compose bar. In a HIPAA email service, the sender either clicks a Send Secure button or the encryption applies automatically to every outbound message.
The Send button behaves the same way. The message enters the outbound queue. The encryption applies before or during the send. The sender does not see any technical change.
The Sent folder shows the encrypted message under its subject line, the same as any other sent message. The sender can preview the content because the sender is a party to the encryption.
The Recipient View Depends on Platform and Method
The recipient view varies. Internal recipients on the same mail platform typically see the message inline. External recipients on other platforms follow a different path depending on the encryption method.
A Purview-encrypted message to a Gmail recipient arrives as a notification email with a Read the message button. The button opens outlook.office365.com in a browser. The recipient signs in with a Microsoft or Google account or requests a one-time passcode.
An S/MIME message decrypts inside the recipient mail client if the client has the correct certificate. Otherwise the recipient sees an unreadable attachment. This is why S/MIME works well for internal or business partner scenarios and poorly for patient communication.
A HIPAA email service typically shows the recipient a branded notification with a Read Message button. The button opens a portal where the recipient reads the decrypted content. Some services deliver the message directly to the recipient inbox if the recipient is on a compatible platform.
[mh_example]
Unencrypted Email Exposes Content to Anyone on the Path
An unencrypted email travels as plain text or under opportunistic TLS only. Opportunistic TLS drops back to cleartext if the receiving server does not support TLS. Any mail relay along the path can read the content.
The mail servers at each end store the message in cleartext. A breach of a mail server exposes the content of every stored message. Backups of mail servers also carry the cleartext content.
For casual content this is often acceptable. Personal mail, meeting confirmations, and general business correspondence typically travel unencrypted. The exposure risk is low relative to the content sensitivity.
For regulated content, the exposure changes the calculus. PHI, financial records, legal work product, and trade secrets in unencrypted mail create compliance exposure under HIPAA, GLBA, HITECH, and similar frameworks. The HHS Security Rule treats encryption as an addressable specification for transmission and at-rest storage.
Encryption Methods Compared at a Glance
The four common methods differ in setup complexity, recipient experience, and threat coverage. The table below summarizes the trade-offs.
| Method | Setup Complexity | Recipient Experience | Fits Best For |
|---|---|---|---|
| TLS | Low, on by default | No change | Baseline transit protection |
| S/MIME | High, needs certificates | Automatic in-client decrypt | Internal and B2B mail |
| Microsoft Purview | Medium, needs license | Portal sign-in or passcode | Outlook tenants on Business Premium |
| HIPAA Email Service | Low, gateway configured | One-click portal | Patient and PHI communication |
The right choice depends on the recipient environment, the license already in place, and the compliance requirements. Practices sending to patients almost always want the one-click portal experience because patient tech literacy varies.
Encrypting an Email in Outlook Uses Microsoft Purview
In Outlook on Microsoft 365 Business Premium and higher, encrypting an email means clicking Options, then Encrypt, in the compose ribbon of a new message. Two policies are available: Encrypt-Only and Do Not Forward.
Encrypt-Only encrypts the content and lets the recipient reply, forward, and print. Do Not Forward encrypts the content and blocks forward, print, and download. The sender picks the policy at send time.
Microsoft Purview handles the delivery. Internal Microsoft 365 recipients see the message inline. External recipients receive a notification with a Read the message button that opens a browser portal for decryption.
The detailed sender steps are in the Microsoft support guide for encrypted messages in Outlook. Tenants on Business Basic or Business Standard do not have the button and need a license upgrade or a separate service.
Encrypting an Email in Gmail Depends on Workspace Plan
Gmail encryption depends on the Workspace plan. Enterprise Plus and Education Plus support client-side encryption. Other plans support confidential mode, which is not the same thing.
Client-side encryption encrypts the message content in the browser before it reaches Google servers. The keys stay with the customer through an external key service. Google cannot decrypt the message.
Confidential mode sets an expiration and disables forward, copy, print, and download. It does not encrypt the message body in a way that meets HIPAA transmission requirements. Google can still access the content.
Standard Workspace plans that need encryption for HIPAA use a HIPAA email service that routes outbound mail through a gateway. The Gmail interface stays the same. Encryption applies at the service layer.
[mh_protip]
Encryption Is One Layer of HIPAA Compliance
Sending an encrypted email is not the same as being HIPAA-compliant. The Security Rule requires administrative, physical, and technical safeguards. Encryption covers part of the technical safeguards.
The covered entity also needs a signed business associate agreement with the email provider, access logs on message activity, workforce training on when to encrypt, and a documented incident response plan.
Common gaps in the compliance picture include:
- Sending encrypted mail without a signed BAA in place with the provider.
- Encrypting outbound mail but leaving stored copies unencrypted at rest.
- Missing workforce training that leaves staff unsure of when to encrypt.
- No incident response plan for a mail account compromise scenario.
- No access logs on message activity for audit review.
Each of these gaps is a real audit finding, not a theoretical concern. Practices building out the wider security posture around encrypted mail also need to cover the website, patient portal, and intake forms. See the guide on healthcare website security features for the site-side controls that pair with encrypted email.
When a HIPAA Email Service Simplifies the Encryption Decision
A dedicated HIPAA email service handles the encryption, the BAA, the access logs, and the recipient portal in a single plan. The sender writes mail in a familiar Gmail or Outlook interface. Outbound mail routes through the service gateway.
Mailhippo is one option in this category. It works with existing Gmail and Outlook accounts. The BAA is included in the base plan. Encryption applies to every outbound message. Recipients open messages with one click and no account creation.
The secure email service approach fits practices that need HIPAA compliance without adding license overhead or IT complexity. The trade-off is a routing dependency on the service.
Related reading covers what encrypted mail actually looks like and how it behaves in specific tools: what does encrypt an email mean, what does encrypting an email do, what happens when you encrypt an email outlook, what is an encrypted email mean, what does an encrypted email look like, and encrypt an email.
The Practical Decision Comes Down to Three Questions
The practical decision on how to encrypt an email comes down to three questions. Who is the recipient. What license is already in place. What compliance framework applies.
If the recipient is another employee or a business partner with technical staff, S/MIME or Purview inline delivery works well. If the recipient is a patient or a member of the public, a portal experience with one-click access is the realistic path.
If the license is Microsoft 365 Business Premium or higher, Purview is the built-in option. If the license is a lower Business plan or a Workspace plan without Enterprise Plus, a HIPAA email service fills the gap without an upgrade.
If HIPAA applies, the choice must include a BAA with the provider handling encryption. A dedicated HIPAA email service handles the BAA by default. The wider healthcare digital footprint, including site and portal, can be coordinated by a healthcare marketing agency that pairs the compliance stack with the marketing stack.
[mh_faqs]
