Secure Email Encryption Service Buyer Guide for 2026

secure email encryption service guide featured image

๐Ÿ”‘ Key Takeaways

  • Three questions decide a secure email vendor: BAA included, auto-trigger, and recipient friction.
  • Office 365 and Gmail bundle native encryption on higher plans, but neither ships a BAA by default.
  • Free services like Proton and Tutanota work for personal use; small clinics outgrow them fast.
  • Entry tier plans run $3 to $8 per seat; enterprise bundles with DLP and archiving hit $10 to $25.
  • Recipient experience drives adoption; portals create tickets, one-click links keep patients happy.

A secure email encryption service protects the contents of a message from the moment a sender hits send to the moment a recipient opens it. Covered entities under HIPAA, financial institutions under GLBA, and law firms handling privileged material all use these services to meet regulatory requirements.

The market splits into three groups. Native tools built into Microsoft 365 and Google Workspace, dedicated third party services like Mailhippo encrypted email, and enterprise gateways from Barracuda, Cisco, and Proofpoint. Each group solves a different problem.

This guide walks through what a secure email encryption service actually delivers, how the main providers compare, and how to test recipient experience before you sign anything.

Secure email encryption service defined

A secure email encryption service scrambles message content so only the intended recipient can read it. The service uses TLS between mail servers as the baseline layer.

On top of TLS, providers add a second layer through S/MIME certificates, PGP keys, or a portal-based delivery model. The second layer protects the message once it lands on a server the sender does not control.

Enterprise services stack more features. Data loss prevention scans outbound content for regulated data. Archiving retains messages for compliance audits. Phishing filters catch inbound threats. Administrative controls let IT enforce encryption on messages that match specific policies.

The core deliverable stays the same across every vendor. Content confidentiality, sender identity verification, and delivery proof. Everything else is packaging.

Office 365 email encryption service options

Microsoft ships Office 365 Message Encryption with Business Premium, E3, and E5 plans. The service runs on Microsoft Purview and adds the Encrypt button to the Outlook Options ribbon on desktop, web, and mobile.

Senders click Encrypt, pick a permission preset, and send. External recipients get a portal link and sign in with Microsoft, Google, or a one-time passcode. Internal recipients see the encrypted message in Outlook without extra steps.

Business Basic and Business Standard plans do not include the Encrypt button. Practices on those SKUs need to upgrade to Business Premium at $22 per user per month or add a dedicated encryption gateway.

Microsoft signs a business associate agreement with covered entities on qualifying plans. Admins need to accept the BAA in the Microsoft 365 admin center under Contracts before sending PHI. Documentation lives at Microsoft Learn Purview Message Encryption.

secure email encryption service in article illustration one

Gmail email encryption service options

Gmail encrypts every message in transit using TLS. Google Workspace paid plans add S/MIME support on Enterprise Plus, which requires certificate management for both senders and recipients.

Confidential mode adds link expiry and SMS passcode options on every Workspace tier. Confidential mode does not encrypt content end to end. The message content sits in Google servers in a readable form for the sender organization.

Google signs a business associate agreement with covered entities on paid Workspace plans configured for HIPAA. Admins accept the BAA in the Workspace admin console. The BAA covers Gmail, Drive, Calendar, Meet, and other core services.

Practices sending real PHI usually stack a dedicated encryption gateway on top of Workspace. The gateway triggers on subject line keywords, data patterns, or recipient domain rules, then routes the message through an encrypted delivery path. See Google Workspace encryption documentation for the current feature matrix.

GoDaddy email encryption service pricing

GoDaddy resells Proofpoint-powered email encryption as an add-on to its Microsoft 365 packages. The add-on runs about $7 per user per month on top of the base 365 license, so a five-seat practice pays roughly $85 per month total.

Senders trigger encryption by adding [encrypt] to the subject line or clicking a button. Recipients register a Proofpoint portal account or verify a one-time code to open messages.

GoDaddy signs a business associate agreement on qualifying plans. The BAA covers the encryption service and the underlying Microsoft 365 tenant. Practices with existing Proofpoint contracts should compare direct Proofpoint pricing at higher seat counts, which often beats the GoDaddy reseller rate.

Support quality varies. GoDaddy phone support handles billing and provisioning. Encryption configuration issues route back to Proofpoint, which adds a delay when a message fails to send. Test the escalation path before you deploy across all seats.

Example

A 20-provider urgent care group ran a 30-day pilot comparing Proofpoint via GoDaddy at $7 per user against Mailhippo at $4.95 per user. They sent 50 identical PHI messages through each service to a mix of iOS, Android, and desktop recipients. Proofpoint required 60 percent of recipients to register a portal account, generating 14 support calls in three weeks. Mailhippo delivered a one-click link that opened for 46 of 50 recipients without an account. The group signed with Mailhippo, saving $492 per month across 20 seats.

Free secure email encryption service trade offs

Free encryption services exist for personal use. ProtonMail, Tutanota, and Skiff offer end to end encrypted email between accounts on the same platform.

Messages to external recipients require the recipient to accept a link, verify a passcode, or install a certificate. Solo practitioners often use free plans for the first quarter of operation, then upgrade once patient email volume rises past 200 messages per month.

Free services rarely sign a business associate agreement. ProtonMail offers a paid Business plan that includes a BAA at $12.99 per user per month. Tutanota and Skiff do not currently offer a BAA at any tier.

Free plans also lack retention controls, audit logs, and admin tools. Compliance risk usually outweighs the license savings once real PHI enters the mailbox. Read the HHS guidance on business associate agreements before picking any free tier for regulated content.

US Bank secure email encryption service model

US Bank uses a portal-based encryption service to send account statements, wire transfer confirmations, and loan documents to customers. Recipients get a notification email with a link to the portal.

The recipient registers an account on the first message, sets a password, and opens the message inside the browser. Follow-up messages from US Bank arrive at the same portal. The model works well for high volume, low urgency correspondence.

Portal-based encryption pushes friction onto the recipient. A customer who cannot find the login page will call the bank. A customer with an expired portal password will call the bank twice.

Financial institutions accept the friction because regulatory pressure outweighs support cost. Healthcare practices with lower call center capacity often pick a zero-step model instead, which delivers the encrypted message directly to the recipient normal inbox.

secure email encryption service in article illustration two

Nonprofit 365 pricing for email encryption service

Microsoft runs a nonprofit program that discounts 365 plans by 30 to 75 percent. Business Basic drops to $0 per user per month for the first 10 seats. Business Standard runs about $3 per user per month.

Business Premium, the plan that includes Purview Message Encryption, drops to about $5.50 per user per month for verified nonprofits. A community clinic with 20 seats pays $110 per month for encrypted email plus Office desktop apps, Intune, and Defender.

Nonprofits still sign the standard business associate agreement in the admin center. The BAA does not change with nonprofit pricing. Documentation lives at the Microsoft Nonprofits portal.

Barracuda, Cisco, and Proofpoint also offer nonprofit discounts of 20 to 50 percent. The discount usually applies to the base plan and not to compliance add-ons, so a small clinic saving money on seats still pays list price for the archiving module.

Mobile and desktop email encryption service parity

The best encryption service works identically on mobile and desktop. Services that require an S/MIME certificate on each device create setup pain for both senders and recipients.

Portal-based services often break the reply flow on mobile browsers. A recipient on an iPhone taps the portal link, logs in, reads the message, then hits reply and gets bounced to a login page again.

Zero-step encryption models handle the mobile case best. The sender uses the normal Gmail or Outlook app on any device. The recipient opens the message inside a standard inbox view on any device.

Test the reply flow on iOS Safari, Android Chrome, and desktop Chrome before committing to a multi-year contract. Vendors will send a test message on request. A five-minute test saves months of user complaints later.

๐Ÿ’กPro Tip: Ask for second-year pricing in writing

Enterprise email security vendors routinely quote a discounted first-year rate that jumps 30 to 50 percent on renewal. Ask for the second-year and third-year rate in writing before signing anything longer than a monthly agreement. Confirm the renewal cap is contractual, not verbal. If the vendor refuses to commit to future pricing, price in an assumed 40 percent renewal jump when comparing total cost of ownership against services with flat published rates.

Provider comparison for secure email encryption service buyers

Buyers picking between vendors weigh four factors above everything else. BAA inclusion, delivery model, price predictability, and admin controls.

Native Microsoft and Google options work well for organizations that already pay for the higher tier plans. Dedicated services like email encryption service providers and encryption email service platforms fit organizations that need a signed BAA in the base plan without a Business Premium upgrade.

Enterprise gateways from Barracuda email encryption service and secure email encryption service cisco add DLP, phishing protection, and archiving in one bundle. The bundles fit organizations with dedicated security teams.

Key evaluation questions:

  • Does the vendor sign a BAA in the base plan or as an add-on
  • Does encryption trigger automatically on regulated content patterns
  • Does the recipient need a portal account, a certificate, or a passcode
  • Does the price stay flat on renewal or jump after year one
  • Does the admin console log every encrypted message for audit

Healthcare practices and secure email encryption service selection

Healthcare covered entities and business associates carry the highest regulatory load. HIPAA, state privacy laws, and payer contracts all require encrypted transmission of PHI.

The right service for a five-person dental practice looks nothing like the right service for a hospital system with 4000 clinicians. Practices with under 50 seats usually pick a zero-step service with a bundled BAA. Larger organizations layer an enterprise gateway on top of Microsoft 365 or Google Workspace.

Practice websites also need to match the same security posture. Patient intake forms, appointment booking, and portal login pages all handle PHI. A HIPAA compliant website design partner handles the web side while the email service handles the mail side.

Practices running healthcare website security features already have most of the operational habits needed to run an encryption service. Password rotation, MFA on admin accounts, and audit log review carry over directly.

Choosing a secure email encryption service without regret

Most buying regret traces back to two mistakes. Picking a vendor without testing the recipient experience, and signing a long contract to lock in a first-year discount that resets on renewal.

Run a 30-day pilot with a single department. Send 50 real messages. Track how many recipients open the message on the first try, how many call for help, and how many ignore the message entirely.

Mailhippo works as an alternative when HIPAA compliance and per-recipient friction both matter. The service adds a BAA in the base plan, works with existing Gmail or Outlook accounts, and delivers messages without asking the recipient to install a certificate or register a portal account. The setup takes minutes.

Whatever vendor you pick, read the renewal clause before signing. Ask for the second-year rate in writing. Confirm the BAA transfers with account transfers. A secure email service that hides its renewal pricing is a service that plans to raise the price on renewal. Reference materials from HIPAA Journal on compliant email and NIST SP 800-177 Trustworthy Email help buyers write a defensible selection memo.

Frequently Asked Questions

What is a secure email encryption service? +

A secure email encryption service scrambles the contents of an email so only the intended recipient can read it. The service uses TLS to protect the connection between mail servers, then adds a second layer with S/MIME certificates, PGP keys, or portal-based delivery. Enterprise services also add data loss prevention, phishing filters, and archiving. Healthcare, finance, legal, and government users pick these services to meet HIPAA, GLBA, or CJIS requirements. The core deliverable is content confidentiality, sender identity verification, and delivery proof.

Does Office 365 include encryption? +

Yes, Office 365 Business Premium, E3, and E5 include Microsoft Purview Message Encryption at no extra cost. Users click the Encrypt button in the Options ribbon before sending, and external recipients open the message through a secure portal after signing in with Microsoft, Google, or a one-time passcode. Basic and Standard plans do not include the Encrypt button. Practices on those plans need to upgrade or add a dedicated encrypted email service to send protected health information under a signed business associate agreement.

Is Gmail encrypted email HIPAA compliant? +

Gmail encrypts email in transit using TLS on every Workspace tier, but transit encryption alone does not meet HIPAA. A covered entity needs a signed business associate agreement with Google, which comes only with Workspace paid plans configured for HIPAA. Confidential mode adds link expiry and passcode options but does not encrypt content end to end. Practices sending real PHI usually add a dedicated encryption gateway on top of Workspace, or route sensitive messages through a third party service like Mailhippo.

How does GoDaddy Email Encryption work? +

GoDaddy sells Proofpoint-powered email encryption as an add-on to its Microsoft 365 packages. Senders trigger encryption by adding a keyword to the subject line or by clicking a button. Recipients open messages through a Proofpoint portal after registering an account or verifying a one-time code. GoDaddy signs a business associate agreement on qualifying plans, and pricing runs about $7 per user per month on top of the base 365 license. Larger practices usually negotiate direct Proofpoint pricing at higher seat counts.

What is the best encryption service for mobile and desktop use? +

The best service works identically on mobile and desktop without extra apps. Services that require an S/MIME certificate on each device create setup pain, and portal-based services often break the reply flow on mobile browsers. Zero-step encryption models handle the mobile case best because the sender uses the normal Gmail or Outlook app and the recipient opens the message in a standard inbox view. Test the reply flow on iOS Safari and Android Chrome before committing to a multi-year contract with any vendor.

Can nonprofits get discounted encrypted email? +

Yes, most major vendors run nonprofit programs. Microsoft, Google, Barracuda, and Cisco publish nonprofit pricing at 30 to 50 percent off list. Microsoft 365 Business Premium runs about $5.50 per user per month for verified nonprofits, which includes Purview Message Encryption. Discounts usually cover the base plan and not the compliance add-ons, so a small clinic saving money on seats still pays list price for the archiving module. Submit IRS 501(c)(3) documentation and a signed nonprofit attestation to activate the pricing.

What features matter most when comparing providers? +

BAA in the base plan, zero-step delivery, mobile-friendly recipient experience, archiving, admin controls, and pricing predictability. Practices sending regulated content should not settle for a vendor that treats the BAA as an upsell. Zero-step delivery keeps staff from forgetting to encrypt. Archiving and audit logs matter when a HIPAA auditor asks for six years of message history. Predictable pricing avoids the trap of a low first-year deal that jumps 40 percent on renewal, which happens often in the enterprise email security market.

Encrypted Emails in Outlook Sending Guide and Troubleshooting Fixes

encrypted emails outlook guide featured image

๐Ÿ”‘ Key Takeaways

  • Outlook offers three encryption paths: Purview, native S/MIME, and third-party add-ins like Virtru.
  • Purview encryption is four clicks: Options, Encrypt, pick policy, Send. External users get a portal.
  • No Encrypt button usually means the wrong Microsoft 365 plan, not an Outlook bug.
  • S/MIME needs an X.509 cert on both sides, which clusters use in orgs with central PKI.
  • HIPAA practices need a Microsoft BAA plus Purview or S/MIME before routing any PHI through Outlook.

Sending encrypted emails in Outlook is straightforward once the correct license and configuration are in place. The confusion for most users starts with which encryption method their license supports and whether the Encrypt button in the ribbon is available at all.

This guide covers the three practical routes for encrypted email in Outlook: Microsoft Purview Message Encryption, S/MIME through certificates, and third-party add-ins. Each section includes step-by-step instructions and the license or setup requirement.

A dedicated troubleshooting section addresses the “cant send encrypted emails Outlook” errors that generate the most support tickets. Every fix is based on Microsoft’s current documentation and typical production configurations.

Three Encryption Routes in Outlook

Outlook supports encrypted email through three separate mechanisms. The right choice depends on the Microsoft 365 license, the recipient population, and whether the organization needs certificate-based zero-knowledge encryption.

Microsoft Purview Message Encryption is the most common route. It ships with Microsoft 365 Business Premium and Enterprise E3, E5, A3, and A5 licenses. Users encrypt messages with a single click in the Options ribbon.

S/MIME is the second route. It requires an X.509 certificate installed on the sender’s device and prior key exchange with the recipient. S/MIME is standards-based and interoperable across mail clients that support it, but the setup burden limits adoption.

Third-party add-ins are the third route. Virtru, Mailhippo, and Barracuda all publish Outlook add-ins that add encryption capability to Outlook regardless of the underlying Microsoft license. These add-ins fit tenants on lower license tiers or workflows that need features Microsoft native encryption does not cover.

Sending an Encrypted Email with Purview Message Encryption

Purview Message Encryption is the fastest route to encrypted email in Outlook for tenants with an eligible license. The sending workflow takes four steps.

Compose a new message in Outlook Desktop or Outlook on the web. Click the Options tab in the ribbon at the top of the compose window. Click the Encrypt button in the Options ribbon. Choose the encryption policy from the dropdown: Encrypt-Only for content encryption or Do Not Forward for encryption plus forwarding restrictions.

  • Compose the message as normal (recipient, subject, body, attachments)
  • Click Options in the ribbon
  • Click Encrypt, then select the policy
  • Click Send

Recipients on Microsoft 365 read the message inline in their inbox with no additional steps. External recipients receive a notification email with a link to Microsoft’s Message Encryption portal. They sign in with a Microsoft account, Google account, or a one-time passcode to read the message.

encrypted emails outlook in article illustration one

Sending an Encrypted Email with S/MIME in Outlook Desktop

S/MIME encryption in Outlook Desktop requires an X.509 certificate installed in the Windows certificate store on the sender’s machine. The certificate can be issued by an internal certificate authority or a commercial CA.

Once the certificate is installed, configure Outlook to trust it. Open Outlook, click File, Options, Trust Center, Trust Center Settings, Email Security. Under Encrypted email, click Settings. In the Security Settings Name dropdown, name the profile. Under Signing Certificate and Encryption Certificate, click Choose and select the S/MIME certificate. Click OK.

To send an encrypted message, compose the message as normal. Click the Options tab and select Encrypt (or Sign, if digital signing only). Send. For encryption to work, Outlook needs the recipient’s public certificate. If the recipient has sent a previously signed message, Outlook captures the certificate automatically.

Our companion piece on how to send encrypted emails covers the S/MIME setup in more depth including certificate procurement from commercial CAs.

Understanding Encrypt-Only Versus Do Not Forward

The Encrypt button dropdown in Outlook offers two Purview policies: Encrypt-Only and Do Not Forward. The difference matters because it affects what recipients can do with the message after they read it.

Encrypt-Only applies message-level encryption to the content in transit and at rest. Recipients can read, reply, forward, print, and copy the content freely once decrypted. The encryption protects against server-side exposure and network interception.

Do Not Forward adds rights management restrictions on top of encryption. Recipients using compliant clients cannot forward, print, or copy the content. The restrictions are enforced by the recipient’s mail client, so they may not hold in all environments (particularly on mobile clients or non-Microsoft mail apps).

Choose Encrypt-Only when the concern is transport and mailbox exposure and the recipient needs full flexibility to work with the content. Choose Do Not Forward for messages containing internal deliberations, confidential negotiations, or sensitive personnel information where distribution controls matter.

Example

A 12-clinician orthopedic practice on Microsoft 365 Business Standard tried to send an MRI report to a referring surgeon and found no Encrypt button in the Outlook ribbon. IT verified the plan in the admin center, upgraded three clinical mailboxes to Business Premium at $22 per seat per month, and confirmed Azure Rights Management showed Activated. The Encrypt button appeared within 45 minutes of license assignment. A test send to a Gmail address delivered a portal link that opened after a one-time passcode.

Fixing “Cannot Send Encrypted Emails” Errors in Outlook

The most common cause of the “cant send encrypted emails Outlook” error is a license mismatch. Purview Message Encryption is not included in Microsoft 365 Business Basic or Business Standard. The Encrypt button in the ribbon does not appear when the license is not eligible.

Verify the license in the Microsoft 365 admin center at admin.microsoft.com. Navigate to Billing, Licenses, and confirm the assigned license is Business Premium, E3, E5, A3, or A5. If the license is Business Basic or Business Standard, upgrade to enable Purview Message Encryption.

The second common cause is Azure Rights Management being disabled at the tenant level. In the admin center, navigate to Settings, Org settings, Services, and confirm Rights Management is set to Activated. Microsoft’s documentation at learn.microsoft.com purview ome covers the tenant-level activation steps.

The third common cause is Outlook not being fully signed in to the Microsoft 365 mailbox. Check the account status in File, Account Settings and confirm the account shows as connected. Sign out and sign back in if the account shows as offline or unauthenticated.

encrypted emails outlook in article illustration two

Encrypted Emails in Outlook on the Web

Outlook on the web (outlook.office.com) supports Purview Message Encryption with the same license eligibility as Outlook Desktop. The compose window includes an Encrypt option in the toolbar.

Click New message. Compose the message. Click the ellipsis (three dots) in the message toolbar. Select Encrypt, then choose the policy. The recipient experience matches the Desktop workflow.

Outlook on the web does not support S/MIME as fully as Outlook Desktop. Some S/MIME features require the S/MIME extension for Edge or Chrome. Organizations relying on S/MIME should standardize on Outlook Desktop or accept the reduced feature set in the web client.

For workflows where users move between Desktop and web frequently, Purview Message Encryption provides a consistent experience. S/MIME works best when the user consistently uses Outlook Desktop.

Encrypted Emails in Outlook Mobile

The Outlook mobile app for iOS and Android supports Purview Message Encryption for both sending and reading. The interface mirrors the desktop workflow with an Encrypt option in the compose menu.

To send an encrypted message on mobile, tap New Message. Compose the message. Tap the three-dot menu. Tap Encrypt and select the policy. Tap Send.

S/MIME on mobile is more limited. iOS Mail supports S/MIME natively when a certificate is provisioned through a configuration profile. Outlook mobile has limited S/MIME support and generally requires organization-specific configuration through Intune or a similar mobile device management platform.

For practices where mobile use is heavy, Purview Message Encryption provides a smoother path than S/MIME. Users who need S/MIME on mobile should plan on iOS with MDM-managed certificates rather than trying to make it work on Android or Outlook mobile.

๐Ÿ’กPro Tip: Confirm the Azure Rights Management state first

License upgrades alone do not always surface the Encrypt button. Azure Rights Management must be Activated at the tenant level under Settings, Org settings, Services. Roughly one in five license-upgrade tickets stall here because the tenant was provisioned before automatic activation became default. Activating takes two clicks in the admin center, and the button appears in Outlook after the client resyncs licenses (usually within an hour).

Encrypted Emails in Outlook for HIPAA Compliance

Healthcare practices sending PHI through Outlook need a Business Associate Agreement (BAA) covering the Microsoft 365 tenant. Microsoft signs a BAA for Business and Enterprise plans but not for free Outlook.com accounts.

The BAA plus TLS in transit plus encryption at rest satisfies the HIPAA Security Rule’s transmission and storage safeguards. Adding Purview Message Encryption or S/MIME provides additional message-level protection. HHS publishes BAA guidance at the HHS BAA reference page.

Practices should confirm the BAA is signed before sending PHI. The Microsoft 365 admin center under Compliance shows the BAA status for enterprise agreements. For Business tier agreements, the BAA is typically part of the Microsoft Products and Services Data Protection Addendum available from the Microsoft Trust Center.

Our team at Redefine Web has published guidance on healthcare website security features for practices building broader HIPAA programs beyond email.

Third-Party Encryption Add-Ins for Outlook

Tenants on Microsoft 365 Business Basic or Business Standard cannot access Purview Message Encryption. Rather than upgrading the whole tenant license, some practices add a third-party encryption product that includes an Outlook add-in.

Common options include Virtru (browser and Outlook add-in), Barracuda Email Gateway Defense (Outlook add-in through the gateway), and inbox-native services such as Mailhippo (Outlook add-in with recipient inbox delivery).

These add-ins install through Microsoft AppSource and integrate into the Outlook compose window. Users click an encryption button in the ribbon or toolbar to route the outbound message through the service.

The trade-off is that the sender manages two encryption tools if the tenant also uses Purview. For small practices, standardizing on a single add-in and skipping Purview keeps the workflow simpler. Larger organizations that already own Business Premium or higher typically standardize on Purview and use add-ins only for niche workflows.

Opening and Forwarding Encrypted Emails in Outlook

Recipients on Microsoft 365 read Purview-encrypted messages inline in Outlook Desktop, Outlook on the web, or Outlook mobile. No additional steps are required.

External recipients receive a notification email with a Read the message button. Clicking opens Microsoft’s Message Encryption portal in a browser. The recipient signs in with a Microsoft, Google, Yahoo, or one-time passcode option. The decrypted message displays. Our companion piece on how to open encrypted emails in Outlook covers this flow.

Forwarding an encrypted email depends on the policy. Encrypt-Only messages can be forwarded and remain encrypted in transit. Do Not Forward messages are blocked from forwarding in compliant clients. S/MIME messages can be forwarded, but the forwarding recipient must have the original recipient’s public certificate for the encryption to reach them successfully.

For practices where forwarding is common (referrals, care coordination), Encrypt-Only is usually the correct default policy. Do Not Forward suits legal, personnel, and executive communications where distribution controls matter more than workflow flexibility.

Frequently Asked Questions

How do I send an encrypted email in Outlook? +

Open a new message in Outlook Desktop or Outlook on the web. Click the Options tab in the ribbon. Select Encrypt and choose either Encrypt-Only or Do Not Forward from the dropdown. Compose the message and click Send. Recipients on Microsoft 365 read the message inline. External recipients receive a portal link to read through Microsoft’s Message Encryption portal. This method requires the tenant to have Microsoft 365 Business Premium or higher, or an Enterprise E3, E5, A3, or A5 license.

Why can I not send encrypted emails in Outlook? +

The most common cause is a license issue. Microsoft Purview Message Encryption is not included in Microsoft 365 Business Basic or Business Standard. Upgrading to Business Premium or higher enables the Encrypt button in the ribbon. Other causes include Azure Rights Management being disabled at the tenant level, Outlook not being connected to the Microsoft 365 mailbox, or corporate policies blocking the encryption option. Verify the plan in the Microsoft 365 admin center and confirm the correct account is signed in to Outlook.

What is the difference between Encrypt-Only and Do Not Forward in Outlook? +

Encrypt-Only encrypts the message content in transit and at rest. Recipients can read, reply, forward, print, and copy the content. Do Not Forward encrypts the message and applies rights management restrictions that prevent forwarding, printing, and copying (for recipients using clients that honor those restrictions). Do Not Forward is enforced by the recipient’s mail client, so restrictions may not hold on all clients. Choose Encrypt-Only when the concern is transport and mailbox exposure. Choose Do Not Forward for additional distribution controls.

How do I set up S/MIME encryption in Outlook Desktop? +

Obtain an S/MIME certificate from an internal certificate authority or a commercial certificate authority such as Sectigo or DigiCert. Install the certificate in the Windows certificate store on the machine running Outlook. Open Outlook, go to File, Options, Trust Center, Trust Center Settings, Email Security. Under Encrypted email, click Settings and select the certificate. Save. To send encrypted, compose a message, go to Options in the ribbon, and select Encrypt (S/MIME option) if the recipient’s certificate is already known to Outlook.

Can external recipients read encrypted emails from Outlook? +

Yes. External recipients read Purview-encrypted messages by clicking a link in the notification email that opens Microsoft’s Message Encryption portal. They sign in with a Microsoft account, Google account, or a one-time passcode. The portal displays the decrypted message. For S/MIME encrypted messages, the external recipient must have their own S/MIME certificate and a mail client that supports S/MIME. Not all external recipients meet those requirements, so Purview is more practical for mixed audiences.

Does encrypted email in Outlook satisfy HIPAA compliance? +

Encrypted email in Outlook satisfies HIPAA when three conditions are met. The Microsoft 365 tenant must be on a plan for which Microsoft signs a BAA (Business or Enterprise, not free Outlook.com). Encryption must be applied to PHI-containing messages using Purview Message Encryption or S/MIME. The organization must have documented policies and access controls consistent with the HIPAA Security Rule. Meeting all three keeps Outlook-based email HIPAA-compliant for most healthcare workflows. Practices should verify the BAA is signed before sending PHI.

What happens if I forward an encrypted email in Outlook? +

Forwarding behavior depends on the encryption method and policy. An Encrypt-Only message can be forwarded by the recipient and remains encrypted at the transport level. A Do Not Forward message is blocked from forwarding in clients that honor the restriction. An S/MIME encrypted message can be forwarded, but the forwarding recipient must have the original recipient’s certificate or the sender re-encrypts to the new recipient. Forwarding across encryption boundaries (Purview to S/MIME or vice versa) often falls back to unencrypted or requires re-encryption at the forwarding client.

Virtru Email Encryption Reviewed with Pricing and Setup Details

virtru email encryption guide featured image

๐Ÿ”‘ Key Takeaways

  • Virtru adds client-side encryption to Gmail and Outlook via extension in minutes, not weeks.
  • The proprietary TDF format supports revocation and expiration that S/MIME and PGP cannot match.
  • Pricing runs free personal, Pro at about $79 per user yearly, and custom Enterprise with DLP.
  • The Pro tier BAA covers Virtru servers but not the underlying Gmail or Outlook mailbox itself.
  • Reviews praise setup speed and post-send controls; recipient Secure Reader is the top friction.

Virtru email encryption is one of the most widely adopted client-side encryption products in the small and mid-market segment. The service plugs into Gmail and Outlook through a browser extension or add-in and encrypts messages on the sender’s device before they leave the mail client.

This guide covers how virtru email encryption works, what it costs, and where it fits. Sections address pricing tiers, HIPAA coverage, the proprietary Trusted Data Format, review sentiment, and honest deployment trade-offs.

The material is aimed at IT decision makers evaluating Virtru against alternatives. Every section reflects Virtru documentation, published pricing on the Virtru site, and aggregated review sentiment from Gartner Peer Insights, G2, and TrustRadius.

How Virtru Email Encryption Works

Virtru installs as a browser extension for Gmail and as an add-in for Outlook. Once installed, the compose window in either application displays a Virtru toggle above the message body.

Enabling the toggle before Send encrypts the outbound message using Virtru’s Trusted Data Format. The message body and attachments are wrapped in a TDF container that includes policy metadata and references to encryption keys held on Virtru servers.

The recipient receives an email with a Secure Reader link. Clicking the link opens the Virtru Secure Reader in a browser and displays the decrypted content. First-time recipients complete a short verification flow. Returning recipients read directly.

The sender can also enable post-send controls at the time of encryption: message expiration, disable forwarding, disable printing, watermarking, and read receipt visibility. Those controls are enforced by the Secure Reader when the recipient opens the message.

Virtru Email Encryption Pricing Tiers

Virtru publishes three pricing tiers on its site. The tiers scale from free personal use to enterprise deployments with custom pricing.

The free personal tier supports encrypted send and receive on personal Gmail accounts. Basic post-send controls are included. The tier does not include a BAA and is not suitable for HIPAA-covered content.

  • Free tier: personal Gmail encryption, basic controls, no BAA
  • Pro tier: approximately $79 per user annually, BAA included, full post-send controls
  • Enterprise tier: custom pricing, adds DLP, key management options, advanced integrations
  • Volume discounts: apply above ~100 seats on the Enterprise tier

The Pro tier at $79 per user per year sits above the Zixcorp base tier ($30 to $50) and roughly comparable to portal-based products such as Barracuda Email Gateway Defense at the small business scale. Enterprise negotiations often move on volume and add-on scope.

virtru email encryption in article illustration one

Downloading and Installing Virtru

Installation is one of the shorter paths in encrypted email deployment. The Virtru extension for Chrome installs from the Chrome Web Store in under a minute. Firefox and Edge extensions install through their respective add-on stores.

The Outlook add-in installs through Microsoft AppSource for Outlook 2016 and later, Outlook for Mac, and Outlook on the web. Enterprise administrators can deploy the add-in centrally through the Microsoft 365 admin center for all users at once.

After installation, the user signs in to Virtru with their existing Gmail or Microsoft 365 credentials through OAuth. That step links the mail account to the Virtru service. No new mailbox or address is created.

Total time from installation to sending the first encrypted message is typically under five minutes. That contrasts with the 30 to 90 day tuning cycle common for gateway policy products such as Zixcorp or Proofpoint.

The Trusted Data Format and Its Trade-Offs

Trusted Data Format (TDF) is Virtru’s proprietary encryption container. It wraps content in a package that includes both the ciphertext and policy metadata such as expiration dates, forwarding restrictions, and watermark instructions.

The design gives senders post-send controls that neither S/MIME nor PGP provide. A sender can revoke access to a message after delivery, change the expiration date, or add a watermark. Those features rely on the Secure Reader enforcing the policy at open time.

The trade-off is interoperability. TDF is not an open standard supported by native mail clients. Recipients read TDF messages through the Virtru Secure Reader, not through Outlook’s or Apple Mail’s S/MIME support. That dependency ties recipient access to Virtru infrastructure remaining operational.

Organizations that need standards-based encryption for interoperability with S/MIME or PGP users need a different tool. Our guide to S/MIME email encryption signature covers the standard-based approach.

Example

A boutique law firm with eight attorneys picks Virtru Pro at $79 per user annually for client communication involving privileged material. Setup finishes in under an hour on a Tuesday morning. Within two weeks, attorneys use post-send revocation four times to pull back messages sent to wrong recipients from autocomplete errors. Clients on Gmail open messages through the Secure Reader with a verification code on first read. The firm accepts the modest recipient friction because revocation and expiration controls justify the pricing above simpler portal options.

Virtru Email Encryption and HIPAA

Healthcare practices use Virtru on the Pro and Enterprise tiers to send HIPAA-covered PHI through Gmail or Outlook. The BAA covers Virtru’s services under HIPAA’s business associate rules.

The BAA scope includes Virtru servers, the Secure Reader portal, and the TDF encryption process. Practices should confirm the signed BAA is in force before routing PHI. HHS publishes sample provisions at the HHS BAA reference page.

The Virtru BAA does not extend to the underlying Gmail or Outlook mailbox. For full HIPAA coverage across the mail path, the practice needs Google Workspace on a BAA-eligible plan or Microsoft 365 on a business plan with a BAA. Free consumer Gmail does not qualify. Our companion piece on HIPAA compliant email Gmail covers the Workspace plan requirements.

Practices building broader HIPAA compliance often pair encrypted email with hardening on the web side. Our team at Redefine Web has published guidance on healthcare website security features.

virtru email encryption in article illustration two

Virtru Review Notes from Peer Sources

Aggregated reviews from Gartner Peer Insights, G2, and TrustRadius cluster around consistent themes. Positive scores focus on ease of setup, Gmail and Outlook integration quality, and the post-send controls.

The setup speed is a common highlight. Reviewers frequently note that a small practice can be sending encrypted email within an hour of purchasing. That contrasts with 30 to 90 day gateway deployments and drives adoption in the small business segment.

Negative scores focus on the proprietary TDF model, the recipient Secure Reader experience (which has improved but historically drew complaints), and pricing above budget-conscious small practices. Reviewers also occasionally cite the OAuth reauthentication cycle in Gmail as a friction point after Google credential rotation events.

Deliverability and the sender experience rarely draw complaints. The integration into the existing mail client keeps sender workflow essentially unchanged. That is a real strength compared to portal-based products where the sender must remember to route sensitive mail through a separate compose interface.

Post-Send Controls in Virtru

Post-send controls are one of the strongest Virtru differentiators. The sender can enforce policy on a message after it has already left the outbox by adjusting metadata stored on Virtru servers.

Message expiration lets the sender set a date after which the Secure Reader refuses to display the content. Useful for time-limited offers, contract negotiations, and clinical results with a documented review window.

Revocation lets the sender cut off access to a specific message even before expiration. Useful when a message was sent to the wrong recipient or when a situation changes after send.

Disable forwarding, disable printing, and watermarking add friction against internal or accidental redistribution. None of these controls are cryptographically enforceable in the strict sense, since a determined recipient can screenshot or transcribe. They act as policy signals and legal deterrents rather than technical guarantees.

๐Ÿ’กPro Tip: Verify post-send controls fit your actual workflow

Virtru's revocation, expiration, and disable-forwarding controls are its strongest differentiator. Before signing, list the last twenty sensitive messages the team sent and ask whether any of them would have benefited from those controls. A workflow of routine patient reminders rarely uses revocation. A workflow of contract negotiations, clinical results with review windows, or attorney-client documents uses them weekly. Match the tier to actual usage patterns, not to the theoretical value of features that sit unused.

The Recipient Experience with Virtru

Recipients of Virtru-encrypted messages receive a normal-looking email with a Secure Reader link. Clicking the link opens the Secure Reader in a browser tab and displays the decrypted content.

First-time recipients complete a short verification flow. Virtru typically sends a verification code to the recipient’s email address to confirm identity. That step reduces phishing risk but adds a small friction to the first read.

Returning recipients read directly through the Secure Reader with a shorter session flow. Recipients who receive frequent messages from the same sender often find the Secure Reader workflow acceptable. Recipients who receive occasional messages find the extra click and verification step noticeable.

For senders whose recipients want no portal or Secure Reader step at all, inbox-native services such as Mailhippo deliver decrypted content directly to the recipient’s regular inbox with a one-click experience.

Virtru Compared to Alternatives

Virtru competes with three categories of alternatives: gateway policy products (Zixcorp, Barracuda, Proofpoint), Microsoft-native encryption (Purview Message Encryption), and inbox-native services.

Against gateway policy products, Virtru wins on setup speed and loses on policy-based enforcement. A Virtru sender must remember to enable the toggle. A Zixcorp gateway scans every outbound message automatically. For high-volume regulated senders, that enforcement gap matters.

Against Microsoft Purview Message Encryption, Virtru offers more granular post-send controls and works with both Google Workspace and Microsoft 365. Purview is bundled with M365 E3 and E5 and works transparently between M365 tenants without additional cost for licensed users. Purview documentation lives at learn.microsoft.com purview ome.

Against inbox-native services, Virtru offers more post-send controls and a longer feature list. Inbox-native services offer a smoother recipient experience and often a lower price point. Our companion piece on email encryption service covers the category comparison.

When Virtru Fits and When It Does Not

Virtru fits small to mid-size teams that use Gmail or Outlook, need HIPAA-compliant email quickly, and value post-send controls such as revocation and expiration. Legal firms, healthcare practices, and financial advisors are common Virtru customers.

Virtru does not fit large enterprises with heavy regulated content flow that need policy-based automatic enforcement across thousands of users. The user-triggered toggle model depends on the sender remembering to encrypt, which introduces enforcement gaps at scale.

Virtru also fits less well for organizations that need cryptographic zero-knowledge encryption with recipient-held keys. TDF holds encryption keys on Virtru servers, so Virtru servers can decrypt if compelled by legal process. Organizations with true zero-knowledge requirements need S/MIME or PGP.

For a broader view, our companion articles on secure email encryption service and email encryption cover the category landscape and help match tool to workflow.

Frequently Asked Questions

What does Virtru email encryption cost? +

Virtru offers a free personal tier for individual users. The Pro tier for business users is priced around $79 per user annually and includes the BAA for HIPAA coverage. The Enterprise tier is custom-priced and adds data loss prevention, key management options, and integration features. Volume discounts apply at higher seat counts. Small practices under 10 seats pay approximately full list. Enterprises above 500 seats typically negotiate below list. Confirm current pricing on the Virtru site because published rates are updated periodically.

Is Virtru email encryption free for personal use? +

Yes. Virtru offers a free tier for personal Gmail users that supports encrypted send and receive with basic controls. The free tier does not include a BAA and is not suitable for HIPAA-covered PHI. It also lacks the DLP integrations and advanced management features of the Pro and Enterprise tiers. The free tier works well as an evaluation environment or for individual privacy-focused users who want client-side encryption on a personal Gmail account without paying for a business plan.

How does Virtru email encryption work in Gmail and Outlook? +

Virtru installs as a browser extension for Gmail (Chrome, Firefox, Edge) and as an Outlook add-in for Outlook desktop and Outlook web. Once installed, the compose window shows a Virtru toggle. Enabling the toggle encrypts the outbound message using Virtru’s Trusted Data Format. The recipient receives a normal-looking email with a Secure Reader link that opens the decrypted content in a browser. The sender can also enable post-send controls such as expiration, disable forwarding, and watermarking through the same interface.

What is the Virtru Trusted Data Format? +

Trusted Data Format (TDF) is Virtru’s proprietary encryption container. It wraps message content and attachments in a package that includes policy metadata and references to encryption keys held by Virtru servers. TDF supports features that S/MIME and PGP do not, such as post-send revocation, expiration, disable forwarding, and watermarking. The trade-off is that TDF is not an interoperable open standard. Recipients read TDF-wrapped content through Virtru’s Secure Reader rather than through their normal mail client’s native encryption support.

Does Virtru email encryption include a BAA for HIPAA? +

The Pro and Enterprise tiers include a Business Associate Agreement covering Virtru’s services under HIPAA. The free personal tier does not include a BAA and is not suitable for PHI. The BAA covers the Virtru servers, the Secure Reader portal, and the TDF encryption process. Healthcare organizations should confirm the signed BAA is in force before routing PHI. The BAA does not extend to the underlying Gmail or Outlook account, so the mail platform must also be on a BAA-eligible plan for full path coverage.

How does Virtru compare to Zixcorp email encryption? +

Virtru and Zixcorp target different segments. Virtru fits small to mid-size teams that want quick setup on existing Gmail or Outlook accounts. Zixcorp fits enterprises with heavy regulated content flow, mature IT teams, and a need for policy-based enforcement across large user populations. Pricing overlaps in the middle. Virtru at $79 per user is competitive with the Zix base tier at $30 to $50 per user, though Zix drops with volume. Our companion piece on Zixcorp email encryption covers Zix in detail.

Can Virtru email encryption prevent phishing? +

Virtru is an outbound encryption product. It does not scan inbound mail for phishing. Preventing phishing requires a separate inbound email security product such as those offered by Microsoft Defender for Office 365, Google Workspace advanced security, Barracuda Email Gateway Defense, or a dedicated anti-phishing service. Virtru complements those products by protecting outbound content but does not replace them. Practices should treat encryption and phishing defense as separate categories of protection and evaluate each independently.

Are Emails Encrypted by Default in 2026

are emails encrypted guide featured image

๐Ÿ”‘ Key Takeaways

  • About 95% of Gmail traffic runs on TLS, but any relay refusing the handshake drops to plain SMTP.
  • Encryption at rest guards disks, not access; a court order or hijacked account still reads inboxes.
  • Internal 365 mail stays inside Microsoft’s network and never touches the public internet.
  • True end-to-end mail needs S/MIME, PGP, or a portal service like Purview or Mailhippo.
  • HIPAA won’t accept TLS alone for PHI; regulators expect message-level encryption on external sends.

Most email today rides on some form of encryption. The question is which kind, at what stage, and whether it survives long enough to matter.

Ask are emails encrypted and the honest answer is a qualified yes. Transport encryption covers the connection between mail servers when both sides support it. Message-level encryption, the kind used for encrypted email delivery, protects the content from the sender’s device to the recipient’s inbox.

The gap between those two matters for anyone sending regulated data. This guide walks through where each layer applies, which providers use which methods, and what changes when HIPAA or a business associate agreement enters the picture.

TLS in transit is the default, not end-to-end protection

TLS, or Transport Layer Security, is the standard method for encrypting the link between two mail servers. When a sending server hands a message to a receiving server, both sides negotiate a TLS session and the traffic across that hop is encrypted.

Google reports that around 95 percent of Gmail traffic uses TLS on outbound and inbound. Microsoft 365 numbers are similar. The 5 percent gap is real, and it usually reflects small receiving servers that do not support modern TLS versions.

TLS does not encrypt the message body itself. It encrypts the connection. Once the receiving server accepts the message, it stores the content in whatever form its policies dictate.

Opportunistic TLS also falls back to plain SMTP if the handshake fails. MTA-STS and DANE are the two standards that force a receiving server to require TLS, and they close that downgrade path. Most large providers publish MTA-STS records now, but many smaller domains do not.

Gmail encrypts in transit and at rest, but not end to end

Are all Gmail emails encrypted? In transit, almost all of them are, when the receiving provider supports TLS. Google publishes real-time transparency numbers on this at their Safer Email Transparency Report.

At rest, Gmail stores every message with server-side encryption using keys Google manages. That protects the mailbox from disk theft or unauthorized physical access to Google data centers.

End-to-end encryption is a different layer. Gmail supports S/MIME on Google Workspace Enterprise Plus and Education Plus, which encrypts the message body before it leaves the sender’s device. Personal Gmail accounts do not include native S/MIME.

For consumer-grade Gmail users who need to send an encrypted message once in a while, the practical options are Confidential Mode, which sets an expiration and a passcode but does not encrypt the body, or a browser extension that layers PGP over the compose window.

are emails encrypted in article illustration one

Microsoft 365 encryption depends on the license tier

Are Microsoft emails encrypted? Internal messages between two users on the same Microsoft 365 tenant stay on Microsoft’s network and are encrypted the entire way. External messages use opportunistic TLS.

Purview Message Encryption, which was previously called Office 365 Message Encryption, is Microsoft’s message-level product. It encrypts the body and attachments and delivers external recipients a portal link. Recipients sign in with a Microsoft or Google account, or with a one-time passcode.

Purview requires Business Premium, Microsoft 365 E3, or higher. Business Basic and Business Standard do not include it. Practices on lower tiers either need to upgrade the entire tenant or send outbound clinical mail through a dedicated encrypted service.

Azure Rights Management sits behind Purview and handles the actual key management. If a tenant has never activated Azure Rights Management, the Encrypt button in the Outlook ribbon does not appear even on the correct license.

Internal Office 365 traffic never leaves Microsoft infrastructure

Are internal Office 365 emails encrypted? Yes, at every layer. Internal email between two users on the same tenant traverses Microsoft’s private network and never touches the public internet.

The traffic between Exchange Online servers is TLS-protected. The mailboxes themselves are encrypted at rest with BitLocker at the storage level and additional service-level encryption in the message database.

Cross-tenant email is a different case. A message from one Microsoft 365 tenant to another still uses Microsoft infrastructure end to end, but it is treated as external and subject to standard transport encryption rules.

Administrators can enforce Modern Authentication, disable legacy protocols like POP and IMAP, and turn on Customer Key to hold their own encryption keys. Those steps harden the tenant but do not change the underlying encryption layers already in place.

Example

A cardiology group assumed their Google Workspace Business Starter setup encrypted patient lab results because Gmail showed the padlock icon on outbound messages. During a HIPAA risk assessment, the security consultant tested by sending a message to a legacy mail server at a rural referring clinic that did not support TLS. The delivery downgraded to plain SMTP silently. The group enforced MTA-STS on their domain, added Mailhippo for external PHI sends at $4.95 per user per month, and closed the finding within one week.

DocuSign notifications are not encrypted documents

Are DocuSign emails encrypted? The notification email itself is an ordinary message sent over TLS. It contains a link, a sender name, and a subject line, and none of that content is encrypted end to end.

The signed document lives inside the DocuSign platform, not in the email. When the signer clicks the link, they authenticate to DocuSign and view the document over HTTPS. The document itself is protected by DocuSign’s platform encryption and access controls.

The gap this creates is that anyone with mailbox access to the recipient can click the link and, if additional authentication is not enforced, sign the document. DocuSign offers signer authentication options like SMS codes, knowledge-based questions, and ID verification. Those are separate from the email.

Providers like Adobe Sign, Dropbox Sign, and PandaDoc all follow the same pattern. The document is protected in the platform, and the notification is a routine email.

Are emails automatically encrypted or does the sender configure it

Are emails automatically encrypted? Transport encryption is automatic when both servers support it. Message-level encryption is not automatic on any consumer email service.

The sender has to take an action. On Outlook 365, that action is clicking the Encrypt button on the message ribbon. On Gmail Enterprise, S/MIME messages are marked automatically if certificates are installed on both sides.

Some services automate the encryption trigger based on content. Data loss prevention rules can inspect outbound mail for patterns like credit card numbers, Social Security numbers, or clinical terms, then apply encryption when a rule matches.

For healthcare senders who need every message with protected health information to be encrypted without depending on user behavior, the practical approach is a gateway service that encrypts by default. Mailhippo works this way, applying encryption to every outbound message from the connected account rather than relying on a user to remember the correct button.

are emails encrypted in article illustration two

End-to-end encryption requires S/MIME, PGP, or a portal service

Three technologies deliver true end-to-end email encryption today: S/MIME, PGP, and portal-based services. Each protects the message body from the sender’s device to the recipient’s inbox or portal.

S/MIME uses X.509 certificates issued by a certificate authority. Each user has a personal certificate, and the sender needs the recipient’s public key to encrypt a message to them. Certificate management is the hardest part of running S/MIME at scale.

PGP uses a similar public-private key pair model but operates through a web of trust rather than a central authority. It is common in developer and privacy-focused circles but rare in mainstream business email.

Portal services like Purview Message Encryption and Mailhippo skip the certificate problem by delivering messages through a browser-based portal. The recipient does not need to manage keys, and the sender only needs an account.

HIPAA requires encryption when it is reasonable and appropriate

The HIPAA Security Rule lists encryption as an addressable specification for transmitting electronic protected health information. Addressable means the covered entity must implement it if it is reasonable and appropriate, or document why it is not.

In practice, HHS treats email encryption as the default expectation for any transmission of PHI outside a covered entity’s internal network. The 2013 Omnibus Rule reinforced that position by tying breach notification safe harbor to encryption of the data involved.

The HHS guidance on the Security Rule and NIST Special Publication 800-52 Rev. 2 both point to TLS 1.2 or higher for transport and AES-128 or AES-256 for content encryption. Meeting those baselines matters more than the specific product chosen.

Practices that route external clinical email through a service with a signed business associate agreement satisfy the encryption requirement and the vendor accountability requirement at the same time. Emails that carry hipaa phishing emails patterns still need employee training on top of encryption.

๐Ÿ’กPro Tip: Enforce MTA-STS to block silent TLS downgrades

Opportunistic TLS falls back to plain SMTP whenever the receiving server refuses the handshake, and the sender never sees a warning. Publish an MTA-STS policy on your domain so receiving servers know to require TLS on inbound. Configure enforced TLS on outbound to any recipient domain that regularly gets PHI. If TLS negotiation fails, the message queues instead of shipping in plaintext. This one change removes the most common HIPAA transport gap.

Free and consumer options do not include a BAA

ProtonMail sends encrypted messages to other ProtonMail users automatically. Messages to outside recipients go through a password-protected portal that the recipient opens in a browser.

Outlook.com supports Microsoft’s free encryption for consumer accounts through the same Purview infrastructure used by business tenants. The recipient experience is identical to the paid version.

Free S/MIME certificates are available from providers like Actalis for personal use. Setting them up requires installing the certificate in the operating system’s certificate store and pairing it with each mail client.

None of the free options include a business associate agreement. For a healthcare practice, that rules them out for anything involving protected health information. If a topic covers are there free tools for encrypting emails, the compliance angle is where free services fall short. Compliance requires a paid service that will sign a BAA and accept vendor liability.

Steps to confirm your email is being encrypted correctly

Gmail shows a small padlock next to the sender address on received mail. A closed padlock means TLS was used on the last hop, an open one means it was available but not enforced, and no padlock means the message arrived over plain SMTP.

Outlook shows a shield icon on S/MIME-signed or encrypted messages. A green check inside the shield means the signature validated. A red X or a missing shield means the message was not S/MIME protected.

Portal messages arrive as a link rather than an inline body. Recipients who see a Read the message button and a sender-branded landing page are receiving a message-level encrypted message.

For senders who want to confirm their outbound TLS posture, tools like the NIST SP 800-52 Rev. 2 guidelines outline the correct cipher and version baseline, and free tests like CheckTLS or the Google Postmaster Tools show the negotiated TLS status per destination domain.

What to configure for a healthcare or compliance-heavy practice

Start with a written policy that defines what qualifies as protected health information and which outbound messages need encryption. Staff cannot apply a rule they do not know exists.

Configure MTA-STS and DANE on the practice domain to prevent TLS downgrade attacks on outbound mail. Publish DMARC at reject or quarantine to stop spoofed messages from reaching patients.

Choose one encryption path and stick with it. Options include Microsoft 365 Business Premium plus Purview, Google Workspace Enterprise plus S/MIME, or a gateway service like Mailhippo that layers encryption over the existing Gmail or Outlook account without a license upgrade.

Practices that want a broader marketing and website foundation to match the security posture often work with a specialist agency. Firms that focus on healthcare marketing services understand how encryption, patient acquisition, and HIPAA-safe intake forms fit together, and how a compliant healthcare website security setup supports the practice’s digital communications.

  • Verify TLS 1.2 or higher on outbound and inbound mail flow.
  • Enable MTA-STS and DANE on the practice domain.
  • Enforce Modern Authentication and disable legacy IMAP and POP.
  • Route external PHI-bearing mail through an encrypted service with a signed BAA.
  • Train clinical and administrative staff on when encryption is required.

Answering the core question, are emails encrypted, comes down to which layer and which sender. Transport encryption is close to universal between major providers. Message-level protection is the sender’s responsibility, and it is what compliance rules actually require.

Frequently Asked Questions

Are Gmail emails encrypted end to end? +

No. Gmail encrypts messages in transit using TLS whenever the receiving server supports it, and it encrypts stored messages at rest on Google’s servers. Neither method prevents Google from reading the content, and neither protects the message once it lands in a mailbox on a provider that does not enforce TLS. For true end-to-end encryption inside Gmail, the sender needs S/MIME through Google Workspace Enterprise or an external tool that encrypts the body before the message reaches Google.

Are Microsoft 365 emails encrypted? +

Internal messages between users on the same Microsoft 365 tenant stay on Microsoft servers and are encrypted the entire way. External messages use TLS when the receiving server supports it. Microsoft 365 also offers Purview Message Encryption on Business Premium and higher, which applies message-level encryption and delivers external recipients a portal link. Encryption at rest is enabled by default on all Microsoft 365 mailboxes, but that only protects stored data on disk.

Are internal Office 365 emails encrypted? +

Yes. Internal email between two users on the same Microsoft 365 tenant never leaves Microsoft’s infrastructure, and the traffic is encrypted across every internal link. The mailbox contents are also encrypted at rest with Microsoft-managed keys. That protects the message from external interception, but it does not stop a compromised account or an administrator with the correct role from reading the content. Internal encryption is not the same as end-to-end encryption.

Are DocuSign emails encrypted? +

The notification emails DocuSign sends are ordinary messages over TLS, and they contain a link rather than the document itself. The signed document lives on DocuSign’s servers, protected by DocuSign’s platform encryption and access controls. When a signer clicks the link, they authenticate to the DocuSign platform and view the document over HTTPS. The email notification is not encrypted end to end, and anyone with mailbox access can click the link.

How can I tell if an email I received was encrypted? +

Gmail shows a small padlock icon next to the sender address that indicates the transport encryption status between servers. A green padlock means TLS was used, a gray one means TLS was available but not enforced, and a red one means no encryption at all. Outlook displays a similar shield icon for S/MIME-signed or encrypted messages. Portal-based services deliver a link rather than an inline message, which itself is a sign the sender used message-level encryption.

Is there a free way to send an encrypted email? +

Free options exist but each carries a trade-off. ProtonMail sends encrypted messages to other ProtonMail users automatically, and to outside recipients through a password-protected portal. Outlook.com supports Microsoft’s free encryption for consumer accounts. Some sender-side tools also offer free S/MIME certificates from providers like Actalis. Free tiers do not include a business associate agreement, which rules them out for healthcare use. Compliance-grade sending requires a paid service with a signed BAA.

Does encryption protect an email from being read once it arrives? +

No. Once the recipient decrypts and opens the message, the content sits in their mailbox as readable text. Anyone with access to that mailbox, including a shared inbox user, an assistant with delegated access, or a malicious actor with stolen credentials, can read the content. Encryption protects the message during transmission and, in some cases, during storage. It does not protect against account takeover, screen capture, or forwarding by the recipient after decryption.

How to Send Encrypted Email Across Any Client

how to send encrypted email guide featured image

๐Ÿ”‘ Key Takeaways

  • Opportunistic TLS drops to plaintext without warning; the Sent padlock lies to you.
  • S/MIME encrypts message-level in Outlook and Apple Mail but needs certs on both sides.
  • PGP does the same job with public and private keys; recipients must set up software.
  • Portal services encrypt every send and give recipients a one-click browser link.
  • HIPAA also demands a signed BAA, six-year access logs, and verified encryption proof.

Every modern mail client can send encrypted email, but the definition of encrypted varies across methods. Some protect only the connection between mail servers. Others protect the message content itself. The difference matters for compliance and for real security.

This guide covers how to send encrypted email across Gmail, Outlook, Apple Mail, and portal-based services. Each method has a specific use case, a specific setup cost, and a specific recipient experience.

The right method depends on the sensitivity of the content and the technical setup of the recipient. Match the tool to the message.

TLS Is the Default Encryption Layer for Every Modern Mail Server

Transport Layer Security, or TLS, protects the connection between two mail servers. When Gmail sends to Outlook, both servers negotiate a TLS handshake and encrypt the traffic in flight. Any observer on the network path sees only ciphertext.

TLS is on by default in Gmail, Outlook, Apple Mail, Yahoo Mail, and every other major provider. Users do not enable it. Administrators do not configure it. It happens automatically when both servers support it.

The problem is fallback. If the receiving server does not support TLS, the sending server delivers the message in plaintext by default. There is no warning. The message reaches the recipient. The sender assumes it was encrypted because their client showed a padlock.

For any content that is regulated, the opportunistic fallback rules out TLS as a standalone protection. You cannot verify that every recipient server supports TLS. According to NIST SP 800-45, verified end-to-end encryption is the required protection for sensitive email.

S/MIME Provides Message-Level Encryption in Outlook and Apple Mail

S/MIME uses X.509 certificates to encrypt the message content itself, not just the transport. Once encrypted, only the recipient with the matching private key can read it. The mail provider stores ciphertext and cannot decrypt.

Outlook supports S/MIME on all Microsoft 365 plans that include the desktop apps. Apple Mail supports S/MIME natively on macOS and iOS. Gmail supports S/MIME on Workspace Enterprise Plus, Education Standard, and Education Plus.

Setup requires a certificate for the sender and a certificate for the recipient. Both must come from a trusted certificate authority. The public key gets attached to signed emails, so correspondents can build up a keyring by receiving signed messages from each other.

S/MIME suits organizations that can deploy certificates across all their staff and partners. It does not suit external correspondents like patients, vendors, or one-off recipients who do not have a certificate installed.

how to send encrypted email in article illustration one

PGP Delivers the Same Protection with a Different Key Model

PGP, or Pretty Good Privacy, is the open-source alternative to S/MIME. It uses a public-private key pair generated locally by the user. The public key is shared. The private key is protected with a passphrase and stays on the sender machine.

Thunderbird includes PGP support by default. Mailvelope adds PGP to Gmail and Outlook Web through a browser extension. GPG Suite adds it to Apple Mail. The GNU Privacy Guard command-line tool underlies most implementations.

PGP does not require a certificate authority. Users trust each other public keys directly, either through personal verification or through a web-of-trust model where mutual acquaintances sign each other keys. This is more flexible than S/MIME but harder for non-technical users to manage.

PGP suits technical teams, security researchers, and correspondents who exchange keys manually. It does not suit a healthcare workflow where a receptionist needs to email a lab result to a patient who has never generated a key pair.

Outlook Encrypt Button Uses Microsoft Purview Message Encryption

Outlook 365 users on Business Premium, E3, E5, and comparable Education plans get an Encrypt button in the Options ribbon of the compose window. Behind the scenes, this triggers Microsoft Purview Message Encryption.

External recipients receive a portal link and sign in with Microsoft, Google, or a one-time passcode. Internal recipients on the same tenant see the message inline in Outlook or Outlook on the web without the portal step.

Setup takes minutes if Azure Rights Management is already enabled on the tenant. For tenants that have not activated it, an administrator must enable Rights Management under the Microsoft 365 Admin Center before the Encrypt button appears in Outlook.

According to Microsoft documentation, Purview Message Encryption meets HIPAA transmission requirements when combined with a signed business associate agreement, available on Microsoft 365 Business plans and higher.

Example

A pain management clinic uses Microsoft 365 Business Standard with the Encrypt button unavailable. Staff send referral summaries to physicians on Yahoo, iCloud, and small hospital systems. TLS delivery drops to plaintext on roughly fifteen percent of sends because those receiving servers refuse TLS. The clinic adds a portal-based service at $9 per user monthly. Every outbound referral now enforces encryption, falls back to portal delivery when TLS fails, and produces an audit trail the compliance officer can export for annual risk assessment review.

Portal-Based Services Remove the Recipient Setup Barrier

Portal-based encrypted email services solve the biggest problem with S/MIME and PGP. The recipient does not need to install anything, configure anything, or generate any keys. They receive a notification, click a link, and read the message in a browser.

Mailhippo works as an SMTP relay. The sender continues to write and send from Gmail, Outlook, or any other client. Mailhippo intercepts the message, encrypts it, and delivers over TLS when the recipient server supports it or through a portal link when it does not.

The recipient experience is one click. They receive a notification email, click the link, authenticate with a one-time passcode sent to their phone or email, and read the message in a browser. No account creation. No software.

For HIPAA, the service includes a signed BAA in the base plan and logs every message access. Healthcare organizations use this model because patient recipients cannot be expected to manage keys or install plug-ins.

how to send encrypted email in article illustration two

Comparison Across the Main Methods

Each method has a specific fit. The table below summarizes the practical tradeoffs.

Method End-to-End Recipient Setup HIPAA Ready Best For
TLS No None No, opportunistic fallback Non-sensitive routine mail
S/MIME Yes Certificate install Yes, with BAA Internal certified teams
PGP Yes Key pair generation Yes, with process controls Technical correspondents
Purview Message Encryption Yes Portal or Microsoft login Yes, with M365 BAA Microsoft 365 users
Portal-based service Yes Click and passcode Yes, with BAA in base plan External recipients, patients

The clearest divide is recipient friction. S/MIME and PGP are excellent when both parties are set up. Portal-based services and Purview handle every recipient without setup, which matters for healthcare and any business email compliance workflow.

Gmail Encryption Steps Depend on the Workspace Tier

Personal Gmail supports TLS by default and Confidential Mode as an inbox-level access control. It does not support S/MIME. For encryption beyond TLS, personal Gmail users need a browser plug-in for PGP or a third-party service.

Workspace Business tiers support TLS and Confidential Mode. S/MIME hosted encryption is unavailable at these tiers. Healthcare organizations on Business Standard or Business Plus typically layer a HIPAA-compliant service to close the gap.

Workspace Enterprise Plus, Education Standard, and Education Plus include S/MIME hosted encryption. Administrators enable it in the Admin console under Apps, Google Workspace, Gmail, User settings.

Full step-by-step for the Gmail path is covered in the sibling guide how to send encrypted email in Gmail and the tier-specific instructions in how to send encrypted email using Gmail.

๐Ÿ’กPro Tip: Never Rely on Opportunistic TLS for PHI

TLS is opportunistic. When the receiving mail server refuses encryption, the sending server delivers the message in plaintext without alerting the sender. Your Sent folder shows the padlock because the initial hop succeeded. For any regulated content, pick a method that refuses plaintext delivery: S/MIME with verified certificates, or a portal-based service that routes to browser delivery when TLS is not available.

Outlook Encryption Steps Depend on the Microsoft 365 Plan

Outlook desktop supports S/MIME on all Microsoft 365 plans that include the desktop apps, provided the user has a certificate installed. The certificate goes into the Windows certificate store or the macOS keychain.

The Encrypt button in the Outlook ribbon requires Microsoft 365 Business Premium or Enterprise E3, E5, or higher. Lower Business tiers do not include Purview Message Encryption. This is the most common gap that surprises small-business owners after a plan upgrade.

For lower Microsoft 365 tiers, the practical path is a portal-based service that adds encryption without requiring the plan upgrade. This suits solo practitioners, small clinics, and small-business teams that need HIPAA-covered email but not the enterprise feature stack.

Verification Steps for Every Sensitive Send

Before sending regulated content, verify the method for that specific send. Do not assume. TLS may have dropped to plaintext. S/MIME may have fallen back because the recipient certificate expired. Purview may have failed to trigger because the tenant setting changed.

  • Check the encryption indicator in the compose window before sending.
  • Confirm the recipient will receive the intended experience by sending a test message with non-sensitive content.
  • For portal-based services, verify the audit log records access after the recipient opens the message.
  • For S/MIME, confirm the padlock or lock icon shows green in the sent copy.

According to HIPAA Journal, the most common documented compliance failure is a sender assuming TLS was in effect when the recipient server had disabled it. Verify per send.

Choose the Method by Recipient and Content

The decision framework is simple. Match the recipient technical setup and the content sensitivity to the encryption method with the lowest friction that still meets the security bar.

  • Internal team, routine content, no regulated data: TLS is sufficient.
  • Internal or partner team with certified users, regulated data: S/MIME or PGP.
  • Microsoft 365 users sending to external recipients: Purview Message Encryption.
  • Any recipient without technical setup, regulated data, HIPAA scope: portal-based service with a BAA.

For healthcare providers coordinating email with website and patient acquisition, encrypted email pairs with HIPAA-compliant website design as part of a broader compliance stack.

The last practical point is that the wrong method causes friction for the recipient, and friction becomes a security risk. Recipients who cannot open an encrypted message will ask for it in plaintext. Pick the method that removes that pressure.

Frequently Asked Questions

What is the difference between encryption in transit and end-to-end encryption? +

Encryption in transit protects the connection between two mail servers using TLS. Once the message reaches the destination server, TLS no longer applies and the mail provider can read the content. End-to-end encryption protects the message content from the moment the sender clicks Send until the recipient opens it. Only the sender and the recipient can read the content, not the mail provider in between. S/MIME and PGP provide end-to-end encryption. TLS alone does not.

Do I need special software to send encrypted email? +

It depends on the method. TLS is automatic in every modern mail client and requires no user setup. Confidential Mode in Gmail and Encrypt in Outlook are built into the compose interface. S/MIME needs a certificate installed in the mail client. PGP needs a key pair generated and shared. Portal-based services either install a browser plug-in or route mail through an SMTP relay, and the sender continues to use their existing client. Recipients on portal-based services need no software at all.

Can I send encrypted email to someone who does not use encryption? +

Yes, but the method matters. S/MIME and PGP will not work because both parties need matching keys or certificates. TLS covers the transport but drops to plaintext if the recipient server does not support TLS. Portal-based services solve this because the recipient does not need to configure anything. They receive a notification, click a link, enter a one-time code, and read the message in a browser. Any recipient with an email address and a web browser can open portal-encrypted messages.

Is Gmail Confidential Mode enough for HIPAA? +

No. Confidential Mode does not use end-to-end encryption. Google can read the message content, and the business associate agreement Google signs for Workspace does not extend Confidential Mode into a HIPAA-safe transmission method. Confidential Mode blocks forwarding, copying, and downloading, which are useful controls, but does not meet the transmission encryption standard HIPAA requires for PHI. Use a HIPAA-focused service with a signed BAA that provides verified encryption for every send.

How do S/MIME certificates get issued and renewed? +

S/MIME certificates come from a trusted certificate authority such as DigiCert, Sectigo, or IdenTrust. The user or administrator submits a certificate signing request, verifies identity, and receives the certificate for install in the mail client. Certificates typically expire after one to three years. Renewal repeats the request-and-verify process. Departing employees should have their certificates revoked so their prior encrypted messages cannot be decrypted after they leave. Enterprise deployments automate the process through a managed PKI.

What happens if I send an encrypted email to the wrong person? +

With TLS, the message reaches the wrong recipient and they read it because TLS does not restrict access at the mailbox level. With S/MIME or PGP, the wrong recipient cannot decrypt unless they somehow hold the intended recipient private key, which is very unlikely. With portal-based services, most providers let the sender revoke access at any time from their outbox. The recipient link stops working immediately. This is one of the practical reasons portal-based services are the healthcare default.

Does my mail provider store copies of encrypted messages? +

Yes, in almost every case. Even with S/MIME or PGP, the mail provider stores the encrypted ciphertext in the sender Sent folder and the recipient inbox. Neither the provider nor anyone else can decrypt it without the private key, but the encrypted copy remains stored. This is why HIPAA archive requirements are satisfied by encrypted copies retained for six years. Portal-based services store the content on their own servers and use enforced access controls with logging on every read.

How to Send Encrypted Email in Gmail

how to send encrypted email gmail guide featured image

๐Ÿ”‘ Key Takeaways

  • Gmail TLS protects the connection, not the copy sitting in your Sent folder or inbox.
  • Confidential Mode blocks forwarding but Google reads the message; skip it for PHI.
  • Hosted S/MIME ships only on Workspace Enterprise Plus at $30 per user per month.
  • A portal service over Gmail adds a BAA and one-click delivery without cert setup.
  • Green padlock means S/MIME; a red or missing padlock means the send goes plaintext.

Gmail handles more than 1.8 billion active accounts, and a large share of business email in North America runs through Workspace. Every one of those messages travels over TLS by default when the receiving server supports it. TLS is not the same as message-level encryption.

Learning how to send encrypted email in Gmail means picking the right method for the recipient and the sensitivity of the content. Gmail offers three options built in: TLS transport encryption, Confidential Mode, and S/MIME on Enterprise plans.

For healthcare organizations and any team handling regulated data, native Gmail options often fall short of HIPAA requirements. This guide walks through each method and when to use it.

Gmail Uses TLS for Every Message by Default

Every Gmail message leaves Google servers over Transport Layer Security whenever the receiving mail server supports it. TLS encrypts the connection between the two servers. Nobody sitting on the network path in between can read the message.

The padlock icon in the top-right corner of an open Gmail message shows the transport status. A gray padlock means TLS is active. A red padlock means the recipient server does not support TLS and the message will travel unencrypted.

TLS protects the connection, not the stored copy. Once the message lands in the Sent folder or the recipient inbox, TLS no longer applies. Google can read the message content on its servers, and so can the recipient mail provider.

According to Google documentation, TLS is opportunistic. If a recipient server does not accept encrypted connections, Gmail sends the message in plaintext by default. That behavior alone disqualifies TLS as a standalone compliance method for protected health information.

Confidential Mode Adds Access Controls but Not End-to-End Encryption

Gmail Confidential Mode is available on every personal Gmail account and every Workspace edition. To use it, click Compose, then click the padlock and clock icon at the bottom of the compose window. A menu appears with an expiration date and an optional SMS passcode.

Confidential Mode disables forwarding, copying, printing, and downloading for the recipient. When the expiration date passes, the message becomes unreadable. Senders can revoke access before expiration from the Sent folder.

The mode does not use end-to-end encryption. Google can read the message content. Screenshots defeat the copy and print restrictions because the recipient still sees the message on screen. SMS passcodes rely on phone carrier security, which SIM-swap attacks routinely bypass.

Confidential Mode suits casual privacy needs such as sending a temporary access code or a document link that should expire. It does not meet HIPAA transmission standards, and Google does not extend its business associate agreement to cover Confidential Mode as a compliant PHI transmission method.

how to send encrypted email gmail in article illustration one

S/MIME Hosted Encryption Requires Workspace Enterprise

S/MIME is the built-in Gmail option for true message-level encryption. It is available only on Google Workspace Enterprise Plus, Education Standard, and Education Plus editions. Workspace Business tiers do not include it.

Enabling S/MIME starts in the Admin console. Navigate to Apps, then Google Workspace, then Gmail, then User settings. Toggle S/MIME encryption for sending and receiving. Save the change and wait up to 24 hours for it to propagate.

Each user then uploads a personal S/MIME certificate under Gmail settings, Accounts and Import, Upload your public certificate. The certificate must come from a trusted certificate authority. Both sender and recipient need valid certificates.

When the setup is complete, the padlock icon in a compose window turns green for messages that will send with S/MIME encryption. If the recipient does not have a valid certificate installed, the padlock stays gray and the message sends over TLS only.

Confidential Mode Setup Takes Under a Minute

Open Gmail and click Compose. Fill in the recipient, subject, and body as usual. At the bottom of the compose window, find the icon that looks like a padlock with a clock overlay and click it.

Select an expiration date from the dropdown. Options range from one day to five years. Choose whether to require an SMS passcode. If SMS is selected, enter the recipient phone number in the field that appears.

Click Save. Send the message. The recipient receives an email with a link to view the message. If SMS was enabled, they receive a text with a passcode to enter before the message loads.

  • External Gmail recipients see the message inline, gated by expiration.
  • Non-Gmail recipients click through to a Google-hosted page.
  • Sender can revoke access at any time from the Sent folder by clicking Remove Access.
Example

A three-provider therapy practice on personal Gmail needs to send session summaries to referring physicians. Personal Gmail has no BAA and does not support S/MIME. They cannot upgrade to Workspace Enterprise Plus for hosted S/MIME at $30 per user. Instead, they migrate to Google Workspace Business Standard at $12 per user for the BAA, then layer a portal-based service at $10 per user monthly. Session summaries send from Gmail normally, and referring physicians open a one-click link without managing certificates.

S/MIME Certificates Need Renewal and User-Level Provisioning

S/MIME certificates expire, typically after one to three years depending on the issuing authority. Renewals require administrator action for every user account. Certificates issued to a departing employee should be revoked in the Admin console to prevent decryption of prior messages.

Certificate authorities include DigiCert, Sectigo, GlobalSign, and IdenTrust. Costs range from around $20 per user per year for basic identity validation to over $100 per user per year for extended validation with organization details.

For encrypted send to work, the recipient also needs a valid certificate from a trusted authority. External correspondents who do not use S/MIME cannot receive encrypted messages this way. Gmail falls back to TLS transport encryption for those recipients.

This is why S/MIME suits internal exchanges between staff at the same organization or between organizations that have coordinated certificate deployment. It does not suit sending sensitive content to patients or external vendors who do not manage their own certificates.

HIPAA Coverage in Google Workspace Has Boundaries

Google offers a business associate agreement to Workspace customers on Business Standard, Business Plus, and all Enterprise editions. The BAA covers Gmail, Calendar, Drive, Meet, and other core services. Personal Gmail accounts are not covered.

The BAA covers the transmission of PHI through Gmail when standard TLS encryption is in effect between servers. It does not cover Confidential Mode as a distinct HIPAA-safe transmission method. Practices assuming Confidential Mode is HIPAA-compliant are working from a mistaken reading of the BAA.

Because TLS is opportunistic and falls back to plaintext when the recipient server does not support it, Workspace admins cannot guarantee encrypted delivery to every recipient without additional controls. That gap is what drives many healthcare organizations to add a HIPAA-focused encrypted email service.

Additional HIPAA safeguards include audit logging of message access, secure archive retention for six years, and enforced encryption on any message flagged with PHI. Native Gmail provides some of these; complete coverage typically involves a purpose-built service.

how to send encrypted email gmail in article illustration two

Third-Party Services Layer HIPAA Compliance Over Gmail

Purpose-built HIPAA-compliant email services integrate with Gmail through a browser plug-in, a Gmail add-on, or SMTP relay. The sender composes and sends from Gmail without changing workflow. The service handles encryption, delivery fallback, and audit trail.

Mailhippo works this way. It sends over TLS when the recipient server supports it, falls back to a secure portal link when TLS is unavailable, includes a signed BAA in the base plan, and requires no certificate management for senders or recipients. Practices on standard Gmail or Workspace Business use it to close the HIPAA gap without switching platforms.

The recipient experience is a single click. They receive a notification email with a link, click it, authenticate with a passcode, and read the message in a browser. No account creation, no software install, no key management.

For healthcare organizations that also handle web presence and patient acquisition, coordinating email security with the broader tech stack matters. Firms offering healthcare marketing services often deploy encrypted email and HIPAA-compliant website design together.

Recipient Experience Differs Across Each Method

TLS is invisible to the recipient when it works. The message arrives in the inbox looking like any other email. No click-through, no passcode, no external portal. Nothing signals that transport encryption was applied.

Confidential Mode delivers a notification email with a View the email button. The recipient clicks and, if SMS was enabled, enters a passcode from a text message. They read the message in a Google-hosted view with copy, forward, print, and download disabled.

S/MIME delivers a locked message icon in a supported email client. Outlook, Apple Mail, and Gmail render the message inline once the recipient certificate decrypts it. In an unsupported client, the recipient sees garbled ciphertext or an attachment they cannot open.

Portal-based services deliver a notification with a link. The recipient clicks, authenticates with a one-time code, and reads in a browser. This suits patients and external contacts who do not manage certificates but expect a low-friction click.

๐Ÿ’กPro Tip: Verify the Padlock Color Before Sending PHI

Gmail displays a color-coded padlock in the compose window: green for S/MIME, gray for TLS, red or missing when the recipient server refuses encryption. For regulated content, never send when the padlock is red. TLS is opportunistic and drops to plaintext without warning. Layer a portal-based service that falls back to a secure browser link rather than accepting plaintext delivery for any PHI transmission.

Common Errors When Sending Encrypted Email in Gmail

The red padlock is the most frequent warning. It means the recipient mail server does not support TLS. For non-sensitive content, the message still sends. For PHI or other regulated data, do not send when the padlock is red without a portal fallback.

S/MIME send failures often trace to a missing recipient certificate. Gmail shows a gray padlock instead of green, and the message sends over TLS. To force S/MIME, both parties must have valid certificates uploaded and the Workspace admin must have enabled the feature at the domain level.

Confidential Mode messages sometimes fail to render for recipients on strict email security gateways. The notification email arrives, but the click-through link is stripped or blocked by the recipient inbound filter. Test with the specific recipient before relying on Confidential Mode for time-sensitive delivery.

According to HIPAA Journal, the most common compliance failure is sending PHI to an external address without confirming the transmission was encrypted end to end. Assume nothing about transport; verify the method for every sensitive message.

Choose the Method by Recipient and Content Sensitivity

Match the encryption method to the message. Casual internal notes to colleagues who use Gmail can rely on TLS. Time-limited access to a document link or a temporary credential fits Confidential Mode. Regulated content going to an external recipient needs message-level encryption or portal delivery.

  • Internal team messages, no regulated content: TLS is sufficient.
  • Temporary access codes to trusted external recipients: Confidential Mode.
  • Regulated PHI, PII, or financial data to any external recipient: S/MIME or a HIPAA-compliant service.
  • Recipients on unknown email systems: portal-based delivery with fallback.

For healthcare providers, portal-based services with a BAA are the most reliable path. They handle recipients across all mail providers, provide audit logs, and remove certificate management. Setup takes minutes rather than the administrator overhead S/MIME requires.

Related reading covers how to send encrypted email across platforms, how to send an encrypted email from Outlook, and how to send encrypted email using Gmail for Workspace teams. For teams building patient-facing infrastructure, resources on healthcare website security features pair well with encrypted email deployment.

Verify Encryption for Every Sensitive Message

Before hitting Send on any message with regulated content, check the padlock icon. Green means S/MIME. Gray means TLS. Red means unencrypted, and the message should not go without a portal fallback.

For Workspace administrators, the Admin console provides an Email Log Search that shows the encryption status of every outbound and inbound message. Use it to audit compliance for a defined period, especially before signing off on a HIPAA risk assessment.

According to NIST Special Publication 800-45, verified end-to-end encryption or a portal-based delivery method is required for messages carrying sensitive personally identifiable information across public networks. Assumed TLS is not the same as verified TLS.

The final rule is straightforward. Do not send regulated content over Gmail unless you have picked and verified a method that meets the transmission standard. Pick S/MIME for internal certified users, or add a HIPAA-compliant service for everyone else.

Frequently Asked Questions

Is Gmail encrypted by default? +

Gmail encrypts messages in transit with TLS whenever both the sending and receiving mail servers support it, and the padlock icon in the message header shows when TLS is active. Messages are also encrypted at rest on Google servers. Neither of those is end-to-end encryption. Google holds the keys and can access message content for spam filtering, indexing, and legal requests. For true message-level protection, use S/MIME on Workspace Enterprise, Confidential Mode for limited controls, or a third-party encrypted service.

Does Gmail Confidential Mode meet HIPAA requirements? +

No. Confidential Mode does not use end-to-end encryption, Google can read the message content, and Google does not sign a business associate agreement covering Confidential Mode messages. HIPAA requires both technical safeguards and a signed BAA with any vendor that processes protected health information. Workspace Business and Enterprise editions include a BAA covering standard Gmail delivery, but the BAA does not extend Confidential Mode into a compliant transmission method for PHI. Use a HIPAA-covered encrypted email service instead.

How do I turn on S/MIME encryption in Gmail? +

S/MIME hosted encryption is only available on Google Workspace Enterprise Plus, Education Standard, and Education Plus editions. A Workspace administrator opens the Admin console, navigates to Apps, Google Workspace, Gmail, User settings, and enables S/MIME encryption for sending and receiving. Each user then uploads a personal certificate under Gmail settings, Accounts and Import, Upload your public certificate. Both sender and recipient need valid certificates from a trusted authority for encrypted send to work.

Can I send encrypted email from a free personal Gmail account? +

A personal Gmail account can use Confidential Mode for basic privacy controls, and TLS transport encryption is on by default when the recipient server supports it. Personal Gmail does not support S/MIME, and Google does not sign a BAA for personal accounts. For message-level encryption from a free Gmail account, layer a third-party encrypted email service on top, or send messages through a browser plug-in that provides PGP or S/MIME encryption client-side. Native Gmail options are limited.

What is the difference between TLS and end-to-end encryption in Gmail? +

TLS encrypts the connection between mail servers so nobody sitting between the two servers can read the message in transit. Once the message reaches Google server or the recipient server, TLS no longer protects it, and the mail provider can read the stored content. End-to-end encryption keeps the message unreadable to everyone except the sender and the recipient, including Google. S/MIME and PGP provide end-to-end encryption. TLS and Confidential Mode do not.

Why does the Gmail padlock icon sometimes appear red or missing? +

The padlock icon uses three colors. Green indicates S/MIME encryption is in use. Gray indicates TLS is protecting the connection. Red or missing indicates the recipient server does not support TLS and the message will travel unencrypted, or the S/MIME certificate check failed. If the padlock is red, Gmail warns you before sending. For regulated data, do not send when the padlock is red; use a service that falls back to a secure portal when TLS is unavailable.

How does a third-party HIPAA-compliant service work with my existing Gmail? +

A HIPAA-compliant service integrates with a Gmail or Workspace account either through a browser plug-in, a Gmail add-on, or by routing outbound mail through the service SMTP relay. The sender writes and sends from Gmail as usual. The service encrypts the message, delivers over TLS when supported, and falls back to a secure portal link when the recipient server does not support TLS. The recipient clicks the link and reads the message in a browser. No key management on either side.

How to Use Encrypted Email

Encrypted email sounds technical at first. Day-to-day, it can feel as simple as clicking one extra button before you send. You still write normal messages. You still talk with patients, clients, and staff. The main change sits behind the scenes. The content of key emails travels in a private, protected form.

You can fit encrypted email into your work without redesigning everything. It can live inside Outlook or Gmail. It can sit in a secure message portal. It can protect both messages and important files. If you want a broad overview of what encrypted email is before you dive into using it, the MailHippo guide to encrypted email provides a clear starting point.

This guide stays practical. It shows where encrypted email helps in real life, how people send and read it, and which habits keep it safe and simple.

What an encrypted email looks like day to day

From a senderโ€™s perspective, an encrypted email still starts with a blank message window. You type an address, write your note, and attach any files. Then you pick a secure send option, such as a small lock icon or a โ€œsend secureโ€ button. The system takes care of the encryption.

From a recipientโ€™s point of view, an encrypted email may appear in two main ways. In some cases, it opens directly in the inbox, with a small lock icon or banner at the top. In other cases, the inbox contains a short-notice email with a link. That link opens a secure page where the full message sits.

Staff can keep their usual email apps. Patients and clients can keep their current email addresses. Encrypted email slips into that world and provides protection, rather than asking everyone to change tools.

When people use encrypted email

Personal privacy

Some people use encrypted email to keep personal notes out of general view. That can mean ID scans, family documents, or private discussions. Normal email leaves that content open to more systems and staff than many people realize.

Encrypted email shrinks that circle. Only the sender and the approved recipient can see the message in clear form. Others see scrambled data or get a login screen. That gives peace of mind on shared Wiโ€‘Fi and shared devices.

Work communication

Managers, dentists, doctors, and office staff all send messages that carry work secrets. These can include pricing, strategy, HR notes, and vendor terms. Plain email can turn one hacked inbox into a large leak.

Encrypted email turns these key threads into harder targets. Attackers who grab stored messages now face protected content. The same goes for curious insiders who should not see everything.

Sensitive files

Many risks hide in attachments. Reports, financial statements, scanned forms, and legal drafts often travel as files. These documents often carry more detail than any short email body.

Encrypted email protects these files during the trip. Some systems extend that protection into storage. Others pair message encryption with protected attachments such as password-locked PDFs. Either way, sensitive files sit under more than a simple paper clip.

Regulated information

Teams in health, finance, and law often handle information subject to strict rules. Think of patient charts, card details, or case files. Regulators often expect strong protection both in transit and at rest.

Encrypted email helps meet that expectation. It shows that you treat regulated information with care when you send it. It also supports policies and audits that assess how you protect key data in transit.

Ways people use encrypted email

Built-in secure send tools

Many organizations enable secure send options in Microsoft 365, Google Workspace, and similar services. Staff then see small buttons or labels in Outlook or Gmail when they compose a message. A single click marks that email as encrypted.

Admins can set rules to trigger encryption when messages match certain patterns. For example, when an email includes the word โ€œpatientโ€ or โ€œSSNโ€. Staff still have manual control for oneโ€‘off cases.

Secure message portals

Secure portals move the private content into a protected website. The inbox shows only a plain email that says something like โ€œYou have a secure messageโ€ with a button. When someone clicks the button, a secure page opens in the browser.

Portals often use passwords or one-time codes to check identity. Once the person signs in, they read the message and download the files inside that page. Replies can stay in the same portal. This model suits clinics, legal practices, and small firms that work with many outside people.

PGP

Some users, often more technical, use PGP-based tools. PGP relies on public and private keys. The sender encrypts the message on their device. The recipientโ€™s private key decrypts it. Service providers in the middle see only scrambled content.

In its raw form, PGP can feel complex. Many modern services now use PGP under the hood and hide the key work. From the user’s view, it then behaves like any other secure send option.

S MIME

Many large organizations use S MIME. This method uses digital certificates that link keys to people or to roles. Outlook and Apple Mail already know how to handle S MIME once certificates are in place.

IT teams or providers install certificates on staff devices. Staff then see lock and signature icons in their mail client. Clicking these icons sends encrypted and signed messages inside and sometimes beyond the organization.

Protected attachments sent by email

In some teams, the main step sits with the file. They lock PDFs, Word documents, spreadsheets, or zip folders with passwords. They then email those files as attachments. The email can be plain or encrypted on top.

This approach is common when the biggest risk lies in a single document, such as a tax return or a lab report. Recipients open the file in a viewer and enter the password that the sender shares through a separate channel.

How to get started

Choose the method

First, pick the style that fits your current tools and contacts. If you already use Microsoft 365 or Google Workspace, built-in secure send may be the fastest path. If you mainly write to patients on many different email tools, a secure portal may make more sense.

Think about IT support. If you have a provider or internal team, S MIME or a managed secure email service may be a good fit. If you handle things yourself, built-in tools and simple portals may be easier to use.

Check recipient access

Next, think about who will open these messages. Staff inside your organization often use the same client and can handle direct inbox decryption. Patients and clients may only have a phone and basic apps.

Pick a setup that matches them. If they can open a link and read a page, a portal works. If they use modern inbox apps, inโ€‘place encryption may work. Edge cases can still use protected attachments.

Learn what parts of the email are protected.

Ask your provider or IT contact which parts of each message are encrypted: the body, attachments, or both. Also, ask what happens to subject lines and addressing data.

Once you know that, you can shape your habits. You can treat the body and files as safe places for private data. You can keep subjects and wide recipient lists free of sensitive details.

Decide how to handle attachments.

Decide what you will do with files by default. Some teams say, โ€œencrypt the message and password-protect any file with health or payroll dataโ€. Others say, โ€œmove all large or critical files into the portal and send links only.โ€

Write that choice down in one or two lines for your team. Clear defaults help staff act quickly while staying safe.

Basic send process

Draft the message

Open a new email in your tool or portal. Add the recipient address and a short, general subject. Write the body in plain language. Explain what you are sending and what action you need.

Place all private facts in the body, not the subject. That includes names, record details, and money numbers. Remember that encryption will focus on this area.

Add files

Attach any files you want to share. Check each file on your device first. Fix errors now, not after sending. If a file needs its own lock, apply that before you attach it.

Keep a clean list of which file names in your folders are protected. Use a name that makes this obvious, such as adding โ€œprotectedโ€ to the name.

Turn on protection

Find the encrypt or secure send control in your mail tool or portal. Turn it on for this message. Look for a lock icon, special label, or banner that confirms the setting.

If your system supports different levels, choose the one that states clear content protection. That might be โ€œEncryptโ€ rather than just โ€œConfidentialโ€.

Review the subject line and recipients.

Before you click send, pause for a short review. Read the subject line and strip out any private details that slipped in. Then check the address list with fresh eyes. Confirm that every address should see the message.

For very sensitive content, think about whether all recipients need the full thread. Sometimes, a separate secure email to a smaller group works better than a long, wide chain.

Send the message

Once content, files, and settings look right, send the email. For a new setup, ask the recipient to confirm that they can open and read it. Use that early feedback to adjust any confusing parts.

Basic receive process

Open the email notice.

Recipients start in their normal inbox. They open the message that mentions secure content. That may be the full email with a lock icon, or a short notice with a button.

They should take a second to confirm the sender’s name and domain. That quick check helps them avoid fake โ€œsecure messageโ€ emails from scammers.

Verify identity if asked.

If the system uses a portal or one-time code, the next screen will ask for identity proof. That might be a login, a password, or a code sent by text.

The recipient enters those details once for that session. The system then unlocks the secure view. The email itself does not hold the private content.

Read the message

Once access is granted, the person reads the message much like any other email. They can scroll, reply, and move between messages in that view.

If something looks odd or empty, they can contact the sender using a known phone number or the main website to confirm that the email is from a legitimate source.

Open any protected files.

If the message includes files, the person clicks to open or download them. For locked PDFs or office documents, the viewer will ask for a password. For portal files, the site may offer view-only or download options.

Recipients should treat downloaded copies as private documents. They can store them in a safe folder rather than on a shared desktop.

Good habits when using encrypted email

Keep subject lines general.

Subject lines often sit outside the encrypted part of the message. Many people see them on phones before they even unlock the screen. Simple, bland subjects keep you from leaking content at that level.

Think โ€œYour recent visitโ€ instead of โ€œFull oncology report for John Smithโ€. That small change makes a big difference.

Share passwords in a separate channel.

If you use passwords for PDFs, zips, or portals, share those passwords away from email. Text, phone, or a secure chat all work. Never place the password in the same email as the protected item.

This habit keeps a single stolen email from handing attackers both the lock and the key.

Use strong account security.

Encrypted email helps only if accounts stay under the right personโ€™s control. Strong, unique passwords, sign-in alerts, and multi-factor login all matter here.

Teams that combine encryption with strong account security gain far more safety than those that treat encryption as a magic fix.

Test with trusted recipients

Test each new secure send method with people who will tell you the truth. That might be a nurse, an assistant, or a longโ€‘time client. Ask them to open messages on both the laptop and the phone.

Listen for any friction. A painful extra step for them today will turn into delays and support calls later.

Common mistakes

Assuming encryption hides everything

Encryption protects the body and attachments in most systems. It rarely hides subject lines, sender and recipient addresses, or time stamps. People can still see that contact happened, even if they cannot read the message.

Safe use means keeping real secrets in the body and files. It means treating outer fields as less private.

Forgetting attachment protection

Some teams enable message encryption, yet still attach open files stored in multiple locations. Once a recipient saves a file outside an encrypted message, that file can spread freely.

For important documents, pair message encryption with protected attachments or secure links. Do not rely only on the envelope.

Sending the password in the same message

This mistake shows up often. The sender locks a PDF, then writes โ€œPassword is 1234โ€ in the email body. That step cancels out most of the gain.

Make it a clear rule on your team that passwords travel in a separate channel each time.

Using an encrypted email for the wrong task

Some tasks do not fit email, even with strong encryption. Sharing master passwords, long-term keys, or very large record sets often falls into this group.

Those cases are better suited to secure link tools or dedicated secret sharing. The MailHippo guide on sending a secure link explains how to handle that kind of data.

When a secure link works better than an encrypted email

Secure links fit best when you want strong control over a document after you send it. They shine for large files, frequent updates, and information that should not sit in many inboxes.

A secure link keeps the document in one protected place. You can turn access off, track views, and avoid email size limits. The email itself becomes a simple pointer, not a container.

Encrypted email still helps in many daily cases. Think of short notes with simple attachments. For heavy or longโ€‘lived content, secure links often win.

Common questions

How do I use encrypted email?

Use encrypted email by adding one extra step to your normal send flow. Draft your message, attach files, turn on the encrypt or secure send option, check the subject and addresses, then send. For the most sensitive files, add file-level locks or secure links as well.

The MailHippo guide on how to encrypt an email, step by step, provides detailed instructions for the sender. The companion article, “How to open an encrypted email on any device,” covers the reader’s side.

Do both sides need special tools?

For built-in and portal-based methods, the sender needs an account on the secure system. The recipient often only needs a modern browser and a basic email app. PGP and S/MIME may need extra setup on both sides.

If you want an easy rollout, start with a method that asks the least from your patients or clients. Portals and built-in secure send tools usually meet that mark.

Can I use an encrypted email on my phone?

Yes. Most major secure email methods work on phones. Outlook and Gmail apps can show protected messages. Portals open in mobile browsers. People can enter one-time codes on touch screens.

Always test your chosen method on the same kinds of phones your patients or staff use. If it works there, it will work almost everywhere.

What is the easiest way to start?

The easiest path is often to turn on the built-in secure send in your current email platform and set a simple rule such as โ€œEncrypt any message with patient or payroll dataโ€. Train staff on one clear button and subject line habits.

Once that feels normal, you can add protected attachments and secure links for the highest risk cases. The MailHippo guide on sending a secure link is a good next step once you reach that point.

Read next

If you want a detailed walk-through of each click when you encrypt a single email, read how to encrypt an email step by step. It turns this high-level picture into concrete steps.

To help your patients, clients, and staff on the other side, share instructions for opening an encrypted email on any device. That guide clears up common access questions.

For tasks that really should not live in email at all, see how to send a secure link. It shows how links can work with encrypted email to keep your most sensitive information safe.

How Do You Encrypt an Email in Outlook, Gmail, and Office 365

how do you encrypt an email guide featured image

๐Ÿ”‘ Key Takeaways

  • Modern Outlook uses Purview from the Encrypt ribbon. Outlook 2013 and older still route via S/MIME.
  • Personal Gmail has only Confidential Mode. Workspace Enterprise adds hosted S/MIME for true E2E.
  • Attachments inherit message encryption, or lock the file first with Acrobat, Word, or 7-Zip AES-256.
  • Office 365 Encrypt needs Business Standard or higher plus Azure Rights Management on the tenant.
  • A gateway skips per-user certs, works from Gmail or Outlook, and ships a BAA in the base plan.

Encrypting an email is a different set of steps in every mail client. Outlook has a button. Gmail has two paths that look similar but work differently. Outlook 2013 uses an older S/MIME workflow. Attachment encryption is its own separate topic.

This guide covers each of them in order. It also flags the HIPAA implications for practices sending PHI. For a cross-client path that works uniformly, a gateway service delivers encrypted email to any recipient without version dependencies.

Every section stands on its own with the menu paths named directly. Skip to the client and version that matches your setup.

Encrypt an Email in Modern Outlook on Microsoft 365

Modern Outlook on Business Standard and above adds an Encrypt button to the compose window. The service is Microsoft Purview Message Encryption.

Open Outlook. Start a new message. Click the Options tab in the ribbon. Click Encrypt. Choose Encrypt-Only or Do Not Forward from the dropdown.

Write the message and click Send. The recipient receives an email with a link. They authenticate with Microsoft, Google, or a one-time passcode and read the message in a browser.

Business Basic tier and free personal Outlook.com do not have the Encrypt button. Related linked topic: how do you encrypt emails for a broader coverage of alternatives.

Encrypt an Email in Outlook 2013 With S/MIME

Outlook 2013 supports S/MIME natively but has no Purview Encrypt button. The workflow uses the Trust Center and a client-installed certificate.

Install an S/MIME certificate in the Windows personal certificate store. Open Outlook. Go to File, Options, Trust Center, Trust Center Settings, Email Security.

Under Encrypted email, click Settings. Pick your signing certificate and your encryption certificate. Choose whether to sign or encrypt by default. Click OK.

To encrypt a single message, click the encrypt icon in the compose ribbon before sending. Recipients need S/MIME support in their client and a cached copy of your public key. This workflow also applies to Outlook 2016, 2019, and Outlook LTSC 2021 when S/MIME is the chosen path.

how do you encrypt an email in article illustration one

Encrypt an Email in Gmail With Confidential Mode

Gmail confidential mode is available on all Google Workspace tiers and personal Gmail. Click the lock and clock icon at the bottom of the compose window.

Set an expiration date from the dropdown. Choose whether to require a passcode. Passcode by SMS is the higher-security option. Click Save.

Write the message and click Send. The recipient receives a link. They open it in a browser, enter the passcode if required, and read the message in a hosted view.

Confidential mode is not end-to-end encryption. Google holds the keys. The mode prevents forwarding, copying, and printing. It does not seal the content against the provider. For HIPAA-scoped mail, confidential mode alone is not sufficient.

Encrypt an Email in Gmail With Hosted S/MIME

Hosted S/MIME is the Gmail path to true end-to-end encryption. It requires Google Workspace Enterprise Standard, Enterprise Plus, Education Standard, or Education Plus.

The admin uploads root and intermediate CA certificates in the Google Admin console under Apps, Google Workspace, Gmail, User Settings, then S/MIME. Enable S/MIME for the organizational unit.

Each user uploads their personal certificate through Gmail settings under Accounts. Once configured, a lock icon appears next to the recipient field. Green means encryption is possible.

Recipients on personal Gmail, Business Standard, or Business Plus cannot receive hosted S/MIME messages. The encrypted content arrives as an unopenable attachment. See Google Workspace admin help for the current tier list.

Example

A physical therapy clinic on Microsoft 365 Business Premium builds an automatic DLP rule in the Purview compliance portal. The rule matches the US HIPAA template and triggers when outbound messages contain MRN patterns or SSN patterns. Action: apply Do Not Forward automatically. A new hire forgets to click Encrypt when replying to an insurance verifier and pastes a partial MRN into the body. The DLP rule fires server-side, encrypts the message, and creates an audit log entry the compliance officer reviews weekly.

Encrypt an Email Attachment for Extra Protection

The attachment inherits the encryption of the message when sent through Outlook Encrypt, S/MIME, or a portal gateway. This is sufficient for most cases.

For extra protection, encrypt the file itself before attaching. This adds a second layer that survives even if the message encryption fails or the recipient forwards the message to an unencrypted inbox.

Common attachment encryption tools:

  • Adobe Acrobat for PDF password protection with AES-256
  • Microsoft Word, Excel, PowerPoint via File, Info, Protect Document, Encrypt with Password
  • 7-Zip for archive password protection with AES-256
  • Apple Preview for basic PDF password protection on macOS

Share the password out of band by phone or text, never in the same email chain. Verify recipient identity before releasing the password. Related linked topic: encrypt an email.

how do you encrypt an email in article illustration two

Encrypt an Email in Office 365 With Automatic DLP Rules

Office 365 supports automatic encryption through Data Loss Prevention rules on Business Premium and Enterprise tiers. This removes the human step of clicking Encrypt.

The admin opens the Microsoft Purview compliance portal. Under Data Loss Prevention, create a new policy. Choose a template for U.S. Health Insurance Act (HIPAA) or a custom policy with SSN, MRN, or ICD patterns.

Configure the action. Apply Do Not Forward, Encrypt-Only, or a custom rights template when a match is found. The policy can also block the send or require justification.

Automatic DLP encryption reduces the risk of staff forgetting to click Encrypt on a sensitive message. It also creates audit trail evidence that the covered entity applied technical safeguards under the HHS Security Rule.

Encrypt an Email With PGP Using FlowCrypt

FlowCrypt is a browser extension that adds PGP support to Gmail. It works on personal Gmail and any Google Workspace tier.

Install the extension from the Chrome or Firefox web store. Create a keypair when prompted. Back up the private key to a hardware token or an encrypted vault.

Send a secure message from the FlowCrypt compose window inside Gmail. The extension encrypts the body with the recipient public key if it is in the FlowCrypt cache. If not, the extension prompts for the recipient key or sends through the FlowCrypt password-protected fallback.

PGP is not native to any major business mail workflow. FlowCrypt fills that gap for teams that want end-to-end encryption without moving to Google Workspace Enterprise. It is not commonly used in regulated healthcare settings.

๐Ÿ’กPro Tip: Automate PHI encryption through DLP rules, never rely on manual clicks

Staff forget to click Encrypt on sensitive messages, especially during busy scheduling windows or shift handoffs. A single missed click is a HIPAA breach. Configure DLP rules in the Microsoft Purview compliance portal or Google Workspace Data Loss Prevention to match SSN, MRN, ICD-10, and custom keyword patterns. Apply Encrypt or Do Not Forward automatically when a match is found. This removes the human factor from compliance and creates audit trail evidence during OCR investigations.

Encrypted Email Options Compared

The table below compares the main paths a business considers.

Method Client Support Recipient Setup End-to-End HIPAA Fit
Outlook Encrypt (Purview) M365 Business Standard+ Passcode or SSO No, portal Yes with BAA
Outlook S/MIME Outlook 2013+ Certificate install Yes Peer traffic
Gmail confidential mode All Workspace Passcode No Not sufficient alone
Gmail hosted S/MIME Workspace Enterprise+ Certificate install Yes Yes
FlowCrypt PGP Gmail via extension PGP key exchange Yes Rare in healthcare
Gateway (Mailhippo) Any provider Passcode Portal-based Yes with base plan BAA

HIPAA Notes on Encrypting Email in Practice

Encryption is one technical safeguard among many. HIPAA requires access controls, audit logging, session timeouts, workforce training, and a signed BAA with each business associate.

Automatic DLP triggers reduce the risk of missed manual encryption. Portal delivery removes the recipient-side certificate requirement. Both are practical for a real HIPAA workflow.

Verify recipient identity before sending PHI. A wrong email address is a HIPAA breach even when the message is encrypted. Document policies and train staff. See related healthcare security features context.

Retention matters. Encrypted mail counts as PHI storage. Retention policies must match state medical board rules and the six-year HIPAA administrative retention requirement.

When a Gateway Is the Better Fit

Managing S/MIME certificates across a small team is meaningful operational work. Certificate expiration, mobile provisioning, and cross-platform trust chains all take time.

A gateway service removes the certificate step. The sender writes in the normal client. A trigger word or plugin button triggers encryption. The recipient reads in a browser.

Mailhippo works this way on top of Gmail or Outlook. It includes a BAA in the base plan. It works uniformly on desktop and mobile without version dependencies. See related how to encrypt an email for the broader walkthrough. Practices building a compliant public-facing site can pair this with HIPAA-conscious website design so intake, contact, and email flows stay inside the same compliance boundary.

Frequently Asked Questions

How do you encrypt an email in Outlook? +

On Microsoft 365 Business Standard and above, open a new message and click the Options tab in the ribbon. Click Encrypt. Choose Encrypt-Only or Do Not Forward. Write and Send. The recipient receives a link and authenticates with Microsoft, Google, or a one-time passcode. On older Outlook versions with S/MIME, install a certificate through the Trust Center under Email Security, then click the encrypt icon in the compose window before sending. The two paths produce different recipient experiences.

How do you encrypt an email in Gmail? +

Click the lock and clock icon at the bottom of the compose window for confidential mode. Set expiration and passcode. Write and Send. This is not end-to-end encryption. For true end-to-end on Google Workspace Enterprise, the admin configures hosted S/MIME and each user uploads a personal certificate. A lock icon then appears next to the recipient field. Green means encryption is possible. For personal Gmail, install a plugin like FlowCrypt to add PGP support. Confidential mode alone is not HIPAA-appropriate.

How do you encrypt an email attachment? +

The attachment inherits the encryption of the message when sent through Outlook Encrypt, S/MIME, or a portal gateway. For separate protection, encrypt the file before attaching. Open the PDF in Adobe Acrobat, choose Protect, set a password. Open the docx in Word, choose File, Info, Protect Document, Encrypt with Password. For archives, use 7-Zip with AES-256. Share the password out of band by phone or text, never in the same email chain. Verify recipient identity before releasing the password.

How do you encrypt an email in Office 365? +

Open Outlook on desktop, mobile, or the web. Start a new message. Click Options in the ribbon. Click Encrypt. Choose Encrypt-Only or Do Not Forward. Write and Send. The Encrypt button is available on Business Standard, Business Premium, Enterprise E3, Enterprise E5, and Government plans. Admins configure encryption templates in the Microsoft Purview compliance portal. Automatic encryption through DLP rules is available on Business Premium and Enterprise plans, which triggers Encrypt when messages match sensitive data patterns like SSN or MRN.

How do you encrypt an email in Outlook 2013? +

Outlook 2013 supports S/MIME but not Microsoft Purview Message Encryption. Install an S/MIME certificate in Windows through the personal certificate store. Open Outlook, go to File, Options, Trust Center, Trust Center Settings, Email Security. Under Encrypted email, click Settings, pick your certificate, and choose to sign or encrypt by default. To encrypt a specific message, click the encrypt icon in the compose ribbon before sending. Recipients need S/MIME support in their client and a cached copy of your public key.

How do you use encrypted email in daily workflow? +

Set a policy. Encrypt any message containing PHI, PII, or financial data. Use S/MIME for peer recipients who hold certificates. Use portal encryption or Outlook Encrypt for external recipients on any provider. Verify recipient email address before sending. Confirm identity by phone before releasing any attachment password. Log the send in the practice communication system if required by policy. Train staff on the trigger words that identify sensitive content and the correct encryption path for each recipient type.

Can you encrypt an email to a recipient without setup on their side? +

Yes, with portal-based encryption. Outlook Encrypt, Gmail confidential mode, and third-party gateways all use a portal model where the recipient receives a link, authenticates with a passcode or SSO, and reads the message in a browser. The recipient needs only a modern browser and the passcode. S/MIME and PGP require setup on both sides because the recipient client must decrypt with a private key it holds. Portal delivery is the model to use when the recipient set is variable or non-technical.

Email Encryption Explained (Methods, Standards, and Costs)

email encryption guide featured image

๐Ÿ”‘ Key Takeaways

  • TLS transport runs server to server. Content encryption via S/MIME, PGP, or portal locks the body.
  • S/MIME wins in enterprise Outlook and Apple Mail but small practices abandon key exchange in months.
  • Hosted encryption from Purview, Confidential Mode, or vendor gateways skips certs but adds friction.
  • HIPAA needs a signed BAA, audit logs, workforce training, and policy above any working algorithm.
  • A ten-seat practice pays about $1,200 a year on a gateway vs $3,600 on Workspace Enterprise Plus.

Email encryption sounds like one feature. It is actually a stack of choices about transport, content, keys, licensing, and recipient experience. Getting the stack wrong leaves gaps that compliance auditors find.

This guide covers email encryption methods, the standards that back them, the platforms that implement each one, and the price ranges buyers see. For HIPAA senders who want to skip the license tier upgrade, a dedicated secure email service often removes the portal step and includes a BAA in the base plan.

Read the sections in order. Each layer builds on the one before it.

Transport and Content Encryption Are Different Layers

Two encryption layers cover email. Buyers often confuse them, which leads to gaps.

Transport encryption uses TLS between mail servers. When Gmail sends to Outlook, both servers negotiate TLS 1.2 or 1.3 and the message travels encrypted. Neither user takes any action.

Content encryption protects the message body and attachments themselves. S/MIME, PGP, and hosted portal encryption all fit here. The message remains encrypted at rest in the recipient mailbox until decrypted with a key or portal credential.

TLS alone leaves messages readable at the recipient provider, in server logs, and in backup snapshots. HIPAA and PCI treat that exposure as non-compliant for regulated content. Content encryption fixes it.

Every serious encryption deployment uses both layers together.

email encryption in article illustration one

S/MIME Is the Enterprise Standard for Content Encryption

S/MIME encrypts message bodies using X.509 certificates issued by a certificate authority. It is the default choice for organizations with dedicated IT.

Outlook, Apple Mail, and Google Workspace Enterprise Plus all support S/MIME natively. No plugin required. The mail client handles encryption and decryption behind the compose window.

Setup requires purchasing a personal certificate from a public CA like DigiCert, Sectigo, or GlobalSign, installing it in the local certificate store, and exchanging signed messages with each recipient to share public keys.

Certificates typically expire after twelve months. Renewal happens through the CA portal. Expired certificates block new encrypted sends until reissued.

Related guide: S/MIME email encryption covers the certificate model in detail.

OpenPGP Serves Technical and Journalism Communities

OpenPGP is the alternative content encryption standard. It uses locally generated key pairs instead of CA-issued certificates.

Users install GPG Suite on macOS, Gpg4win on Windows, or Mailvelope in the browser. The tool generates a key pair with a passphrase. The user shares the public key with recipients through a keyserver or direct email.

Trust builds through key signing rather than a central authority. Security researchers, journalists, and open source maintainers use PGP heavily because it does not depend on any CA infrastructure.

Business adoption of PGP stays limited. Recipients cannot install extensions on locked-down corporate systems. Healthcare and financial senders skip PGP for that reason.

The technical strength of PGP is not the barrier. The recipient-side friction is.

Example

A ten-person orthopedic practice compares annual encryption costs. Microsoft 365 Business Premium at $22 per seat totals $2,640 per year and includes Purview Message Encryption plus a BAA. Google Workspace Enterprise Plus at $30 per seat totals $3,600 and adds hosted S/MIME. A dedicated gateway service at $10 per seat totals $1,200 with the BAA included in the base plan, sitting on top of the existing Business Standard Google plan. The practice picks the gateway to avoid the tier upgrade cost.

Hosted Encryption Services Handle the Recipient Portal

Hosted encryption trades certificate management for a portal step at the recipient end. Microsoft Purview Message Encryption, Google Workspace Confidential Mode, and many third-party vendors follow this pattern.

The sender clicks Encrypt in the mail client. The service routes the message body to its own storage and sends the recipient a notification email with a link. The recipient signs in with an existing account or enters a one-time passcode to read the message.

Vendor gateways from Fortinet, Cisco, Trustifi, Datamotion, and others all follow the same portal pattern with different admin interfaces and reporting.

The recipient friction depends on the vendor. Some services allow one-click reading through a signed URL. Others require full account creation. Test each with a real recipient before committing.

Related guide: email encryption service compares vendor options in depth.

email encryption in article illustration two

Encryption Techniques and Algorithms in Use Today

The math behind email encryption uses proven algorithms defined in published standards.

  • AES-256 handles symmetric encryption of the message body itself. It appears in every current standard.
  • RSA-2048 or elliptic curve algorithms handle the key exchange that carries the symmetric key to the recipient.
  • SHA-256 or SHA-384 handles integrity hashing so recipients can detect tampering.
  • TLS 1.2 with strong cipher suites, or TLS 1.3 without weak fallback, handles transport between servers.
  • Message authentication codes bind sender identity to the message so recipients can verify origin.

Buyers rarely choose algorithms directly. Every modern platform defaults to combinations aligned with NIST guidance. See the NIST cryptographic guidance publications for the current recommended parameters.

Platform-by-Platform Encryption Options

Each mail platform ships different encryption features at different price tiers.

Microsoft 365 Business Premium and higher include Purview Message Encryption behind the Encrypt button. Business Basic and Business Standard do not.

Google Workspace Enterprise Plus and Education Plus include hosted S/MIME. Business Standard and Business Plus include Confidential Mode but not hosted S/MIME.

Apple Mail supports S/MIME natively on macOS and iOS provided the user installs a certificate through Keychain or MDM configuration profile.

Yahoo, AOL, and older ISP webmail platforms do not offer S/MIME or hosted encryption. Users on those platforms rely on TLS transport plus optional PGP through browser extensions.

Match the plan tier to the required feature before rolling out an encryption program.

๐Ÿ’กPro Tip: Layer content encryption on top of TLS, never in place of it

TLS transport is the required baseline that most modern providers negotiate automatically between mail servers. Buyers who focus only on TLS leave content readable at the recipient mail provider, in server logs, and in backup snapshots. HIPAA and PCI treat that exposure as non-compliant for regulated content. Deploy S/MIME or a hosted portal service on top of TLS so the body stays encrypted end to end. NIST cryptographic guidance treats layered encryption as the required baseline for regulated data.

HIPAA Compliance Requires More Than Encryption

Encryption satisfies one HIPAA Security Rule addressable specification. Full compliance requires several additional safeguards.

The covered entity signs a business associate agreement with the email provider. Microsoft and Google both offer BAAs on eligible plans. The HHS Security Rule guidance lists every safeguard.

Administrative safeguards include workforce training on PHI handling, sanction policies for violations, and periodic risk assessments. Physical safeguards include facility access controls on the workstations that send email.

Technical safeguards beyond encryption include unique user identification, automatic logoff on idle sessions, and audit controls that record message access.

Practices that clip on encryption software without addressing the surrounding safeguards are not compliant. Encryption is one piece of a larger program.

Cost Comparison Across Encryption Approaches

Price often decides the buying question more than features. A ten-person practice compares real annual numbers.

Approach Per user per month Annual cost (10 users)
Microsoft 365 Business Premium (Purview) 22 USD 2,640 USD
Google Workspace Enterprise Plus (hosted S/MIME) 30 USD 3,600 USD
Public CA S/MIME certificates (annual) 2 to 5 USD (amortized) 240 to 600 USD plus mail plan
Dedicated encrypted email service with BAA 5 to 15 USD 600 to 1,800 USD

Numbers exclude staff training, audit review time, and the recipient-side support calls that portal-based encryption generates. Practices measuring hidden costs often find dedicated services cheaper end to end.

How to Choose the Right Encryption Approach

The decision comes down to three questions about the sending organization.

First, does the organization already run Microsoft 365 Business Premium or Google Workspace Enterprise Plus? If yes, native S/MIME or Purview cover the encryption need with no additional software.

Second, does the recipient list change frequently, as with a healthcare practice adding new patients weekly? If yes, hosted encryption or a dedicated service avoids the S/MIME public-key exchange step.

Third, is the recipient experience business-critical? If patients or referring physicians will abandon messages that require a portal sign-in, a dedicated service like Mailhippo delivers encrypted email that opens in one click without a portal.

Practices running healthcare marketing sites pair encrypted email with a compliant patient-facing web presence. See healthcare website security features for the site-side controls.

Related guides: email encryption software, secure email encryption service, and encryption for email techniques.

Frequently Asked Questions

What does email encryption actually do? +

Email encryption transforms the message body and attachments into unreadable ciphertext during transit and, depending on the method, at rest inside the recipient mailbox. Only the intended recipient with the matching key or credentials can convert the ciphertext back to readable content. Encryption protects against interception on public networks, unauthorized access at intermediate mail servers, and exposure inside a compromised recipient inbox. It does not protect against phishing, malware on endpoint devices, or attacks against the sender or recipient authentication.

What are the main email encryption standards? +

The two dominant end-to-end standards are S/MIME and OpenPGP. S/MIME uses X.509 certificates issued by trusted certificate authorities and works natively in Outlook, Apple Mail, and Google Workspace Enterprise Plus. OpenPGP uses key pairs generated locally without a central authority and works through client extensions like GPG Suite, Gpg4win, and Mailvelope. TLS 1.2 or 1.3 handles transport encryption between mail servers under RFC 8446. Most business encryption stacks combine TLS with S/MIME or a hosted portal service.

Is email encryption required by HIPAA? +

HIPAA does not name encryption as a strict requirement. The Security Rule designates encryption as an addressable specification, which means the covered entity must implement it or document a reasonable alternative that achieves equivalent protection. OCR guidance and breach settlements consistently treat unencrypted PHI transmission as a compliance failure. In practice, healthcare organizations encrypt PHI email or restrict PHI to encrypted channels like patient portals. Unencrypted email carrying PHI is one of the most common findings in OCR breach investigations.

What is the difference between email encryption software and a service? +

Encryption software installs on the mail client or gateway and handles the cryptographic operations locally. Examples include Gpg4win, GPG Suite, and enterprise gateway appliances from Fortinet or Cisco. An encryption service runs in the cloud and integrates with existing Gmail or Outlook accounts through connectors, SMTP relay, or add-ons. Services handle key management, portal delivery, and BAA administration on behalf of the customer. Small and mid-sized organizations favor services for the reduced operational load.

Can email encryption be bypassed? +

Yes, under specific conditions. If an attacker compromises the sender or recipient device, they can capture plaintext before encryption or after decryption. Phishing attacks that steal mail credentials bypass encryption by giving the attacker legitimate access to the inbox. Weak recipient portal passcodes can be guessed or intercepted through SIM-swap attacks. Encryption defends against interception in transit and provider-side access, but a full security posture also requires multi-factor authentication, endpoint protection, phishing training, and incident response procedures.

How do I know if my email was actually encrypted? +

In Outlook, an encrypted sent message shows a padlock icon in the message header inside the Sent Items folder, and the message properties confirm Rights Management protection. In Gmail with S/MIME, the compose window displays a green padlock next to the recipient before sending. In Confidential Mode, the sent message header shows the expiration date and access restrictions. Recipient-side confirmation appears as either a padlock icon in the received message or a portal link that requires sign-in.

Does email encryption slow down message delivery? +

End-to-end encryption adds negligible time to message delivery. S/MIME processing takes milliseconds on modern devices. TLS handshakes add a few hundred milliseconds during the server-to-server connection setup. Portal-based encryption slows recipient access, since the recipient must click a link and sign in before reading. That step adds seconds to minutes depending on network speed and authentication method. Sender workflow speed is essentially unaffected on any modern platform.

How to Encrypt Emails Safely

Email still powers most office and practice work. You send schedules, invoices, lab reports, contracts, and HR updates every day. Some of those messages carry details that really should stay private.

Encrypting email keeps those details safer. Doing it safely means more than just turning on a lock icon. You need the right method, the right habits, and a flow that your patients, clients, and staff can handle without stress.

If you want a simple overview of the bigger picture, you can read MailHippoโ€™s guide to encrypted email. The guide you are reading now focuses on how to use email encryption safely and practically.

What safe email encryption means

Safe email encryption means your messages are protected in a way that balances security and real-life use. The content is scrambled from prying eyes. The right people can still read and reply without a long setup.

In a safe setup, your email system hides the complex pieces. Keys, certificates, and passcodes all work in the background. You and your team see simple options such as โ€œsend secureโ€ or โ€œencrypt this emailโ€.

Safe encryption also respects peopleโ€™s limits. Patients or clients should not need to install strange software or jump through ten steps for each message. If the path feels smooth, they will keep using it. That keeps more of your sensitive email out of plain text.

Pick the right protection method.

Choosing the right method is the first step toward safe encryption. One size does not fit every practice or firm. Think about your current tools and the people you send to most often.

Many teams start with what they already have. Business email platforms often include built-in protection. Others add a secure portal or a specialist, encrypted email serviceโ€”some mix methods, such as protected attachments and secure file links.

The right choice lets you keep most of your current routines. You keep your inbox and addresses. You add just enough structure to send private information more securely.

Built-in email protection

Outlook, Gmail, and other business tools often have built-in secure send options. You may see a padlock icon, a โ€œconfidentialโ€ label, or a โ€œprotectโ€ menu.

These features can encrypt the message body and sometimes add rules such as โ€œdo not forwardโ€. Staff work inside their usual apps. Your IT partner or provider manages the settings in the background.

For many practices, this is the easiest starting point. It keeps training short and makes secure sending feel like a normal click.

Secure message portals

Secure portals keep messages inside a protected web page. The email in the inbox is only a short notice with a link. The real content never sits as plain text in a normal email.

This model suits patients and external clients who use multiple mail systems. They only need a browser and a simple code or password. You gain more control over who reads what and for how long.

PGP

PGP uses public and private keys for each user. It can give very strong privacy. Power users and small technical teams often like it.

Pure PGP needs more setup and care. People must manage keys and passphrases. Many clinics and offices find it too heavy on its own. Some specialist services run PGP behind the scenes and hide the hard parts from staff.

S MIME

S MIME uses certificates that link keys to people or roles. Outlook and Apple Mail already know how to use S MIME. Many large companies and health systems rely on it.

IT teams usually handle the certificate setup. Once done, staff see only small icons for โ€œsignโ€ and โ€œencryptโ€. For managed groups, this method can feel both strong and smooth.

Protected attachments

In some cases, you protect the file instead of, or in addition to, the message. You can add a password to a PDF, an office document, or a zip file. The file then asks for that password each time someone opens it.

This gives a lock that travels with the file. The file stays protected even if someone saves it outside the email thread. The price is that you must share the password safely, which this guide covers later.

Know what email encryption covers.

Safe use of encryption starts with clear expectations. You need to know which parts of each email gain strong protection and which do not.

Message encryption typically focuses on the body and attachments. Some fields around the message stay more open. When you understand those limits, you can avoid accidental leaks.

Keeping this picture in mind helps you write a safer email even before you click any secure send button.

Message body

The message body is the main text you type. In almost all encrypted email systems, this is the core thing that gets scrambled. That is where you want names, notes, and details to live.

When someone without access tries to read an encrypted body, they see only random data. Attackers who steal stored messages get the same junk. That is why moving private details into the body, not the subject, matters so much.

Attachments

Attachments often get the same protection as the body when you encrypt the message. The email service turns files into protected data for the trip and sometimes stores them.

Once the recipient saves a file outside the email, that extra layer can drop. To stay safe, you may add file-level locks, such as password-protected PDFs or zips. Safe attachment handling often requires both message- and file-level thinking.

Subject line limits

The subject line usually stays in plain text. Inboxes use it for lists and threads. Phones show it in alerts. Logs may keep it for a long time.

So even when you encrypt the message, a line like โ€œFull oncology report for Maria Lopezโ€ still leaks more than you want it to. Neutral subjects such as โ€œYour reportโ€ or โ€œRequested documentsโ€ work much better.

Metadata limits

Metadata includes who sent the email, who received it, and when it was sent. Email systems need this data to do their job. Encryption rarely hides it fully.

People with deep access can still see that your practice emails a law firm often, or that a staff member emails HR at odd hours. They cannot see the encrypted text from that alone. Still, it shows why you should keep truly private parts of the body and files only.

Steps before you send

A few checks before you click send make an encrypted email much safer. These checks cost very little time. They prevent many headaches.

Think of this as a short routine. Address, subject, files, and access. Once that rhythm feels normal, your risk drops without adding stress.

Check the recipient address.

One wrong letter in an address can send a private email to the wrong person. Autocomplete can also pick a similar but incorrect contact.

Read the To, Cc, and Bcc lines slowly. Make sure each address belongs to someone who should see the message. For new contacts, a quick plain test email before you send real data can help.

Review the subject line.

Keep the subject free of sensitive detail. No full names with diagnoses. No full account numbers. No staff review hints.

Use short labels only. Let the encrypted body and protected files hold the content that would cause harm if leaked.

Decide how files will be protected.

Look at each attachment you plan to send. Ask yourself how bad it would be if that file appeared in the wrong inbox.

For low-impact files, message encryption may be enough. For high-risk files, add passwords or move them to a secure portal. Make this choice before you attach anything, not as an afterthought.

Test access if needed

For a new method or a big change, test with a colleague or a second account. Send a sample encrypted email and open it on both desktop and mobile.

Watch how many clicks and screens the path needs. Fix any confusing steps before you involve patients or clients. That keeps trust high and support calls low.

How to encrypt emails safely, step by step

Once you have your method and pre-checks sorted, the send process itself can remain simple. Think in five steps. Write, attach, protect, set rules, and send.

These steps apply to built-in tools and many secure portals. PGP and S MIME follow the same spirit, with a bit more setup up front.

Write the message

Open a new email. Add the correct address. Type a neutral subject. Write the body in clear, plain language.

Move all private facts into the body. Names, dates, diagnoses, and money figures belong here, not in the subject. Mention that the email is secure if that helps set the tone for the reader.

Add files

Attach the files you need. Make sure you attach final, checked versions, not drafts. If you chose file-level protection for some items, lock those files first, then attach the protected copies.

Keep track of which files in your folder are protected. Names that include โ€œprotectedโ€ or โ€œencryptedโ€ can help staff pick the right one.

Turn on protection

Find the encryption or protection control in your email tool or portal. Turn it on for this message. Watch for a lock icon or banner that confirms the setting.

If your tool offers several levels, pick the one that clearly states content protection. For example, โ€œEncryptโ€ or โ€œEncrypt and prevent forwardingโ€.

Set access rules

Some systems let you set extra rules. You might limit forwarding, block printing, or set an expiry date in a portal. Pick rules that match the risk and the person.

For example, you might allow printing of a consent form the patient needs to sign, yet block forwarding of a one-off lab report.

Send the message

Do a final scan. Check addresses, subject, and attached files. Make sure protection is still turned on. Then send.

For very sensitive content, follow up with the person to confirm they received and opened the email. That extra check closes the loop.

How to share passwords and passcodes safely

Passwords and one-time codes often sit at the heart of safe email encryption. Sharing them badly can undo much of your hard work.

Never put a password in the same email as the protected file or link. That gives an attacker both parts at once. Use a different route.

A quick phone call works well. So does a text message to a known number or a secure chat app that your team approves. Password managers and secret-sharing tools can also send one-time views.

Aim for unique passwords per person or per case. Avoid reusing the same short code for months. Strong, fresh secrets keep leaked emails from turning into full-blown data losses.

Safer ways to handle attachments

Attachments can be both useful and risky. A few habits make them much safer when sent via an encrypted email.

PDFs

Use password-protected PDFs for reports, statements, and forms. Set a password in the PDF tool, save a new copy, and test it. Then attach that locked copy to your email.

PDFs with strong passwords stay protected in inboxes, on drives, and in backups. They give a simple, familiar, open flow for recipients.

Office files

Word and Excel can both lock documents with passwords. Use this for drafts or sheets that staff still edit. For final versions sent to clients or patients, many teams convert them to protected PDFs.

Remember that some older formats use weak locks. Use current file types and viewers whenever possible.

Zip files

Zip folders bundle several files into a single file with a password. This fits case bundles or image sets. Create a new encrypted zip with a strong password, test it, then attach it.

Recipients must have a zip tool that understands encrypted archives. For less technical people, a single locked PDF may feel easier to handle.

Large documents

Large imaging files and bulk exports often break email limits. Place them in a secure storage service and send a link instead of attaching them.

You can then control access without worrying about attachment size. The guide on how to send a secure link explains this route in more detail.

Common mistakes

Sending passwords in the same email

Putting the password in the same message as the file or link removes most of your safety. Anyone who sees that email gets everything.

Keep passwords and content in different channels. Make this a clear rule in your team.

Putting private details in the subject line

Even perfect encryption cannot hide a sensitive subject line. Many systems show subjects on phone screens and in logs.

Train staff to treat the subject as a label only. No diagnoses, no account numbers, no staff review hints in that line.

Using weak passwords

Short or simple passwords are easy to guess. Items like โ€œClinic2024โ€ or โ€œPatient1โ€ should never guard real data.

Use longer phrases or generated strings. Store them in a password manager if needed. Teach staff to avoid names and simple words.

Forgetting old unprotected copies

Plain drafts on desktops and shared drives can leak even when current sends are encrypted and locked. Staff may attach those by mistake later.

Clean up old loose versions when you move a document into protected use. Keep the locked copy in a clearly marked folder.

Assuming all recipients can open protected mail

Not everyone uses the same device or has the same skill level. A method that works well for staff may confuse a patient on an older phone.

Test your flow with people who match your real recipients. Adjust until they can open and read with one or two simple steps.

When a secure link is the better fit

Secure links work better than encrypted email in some cases. Files are huge. Many people need access. You want a clear log and the option to turn access off.

With a secure link, the file lives in one protected place. You control who reaches it and for how long. The email shrinks to a short notice.

For tasks like sharing master passwords, root keys, or very large record sets, secure links often beat both plain and encrypted email. The MailHippo guide on how to send a secure link gives simple steps.

How to check whether your email was protected

After you send, open the message in your Sent folder. Many platforms show a lock icon, a banner, or wording such as โ€œencrypted messageโ€ next to the subject or in the header.

You can also send yourself a test and then try viewing it from another account. Some admin panels show logs that mark which messages are left with protection on.

If you never see any sign of encryption, speak with your IT partner or provider. Ask them to show you a real protected message so you know what to look for in your own inbox.

Common questions

How do I encrypt emails safely?

Pick a method that fits your tools and your recipients. Move private details into the body and files, not the subject. Attach and protect files as needed. Turn on the encryption or protection setting. Share any passwords or codes through a separate channel. Test with a colleague before you rely on the flow with patients or clients.

For a very detailed walkthrough, read how to encrypt an email step by step. For a message focus, see how to encrypt email messages step by step.

Can encrypted emails still be risky?

Yes. Encryption lowers risk for content, yet it does not fix every problem. Weak passwords, lost devices, fake login pages, and detailed subject lines can all still cause trouble.

Think of encryption as one key tool in a wider set. Strong passwords, staff training, safe file habits, and good device care still matter.

What is the safest way to send files by email?

The safest path locks both the path and the file. That means encrypted email plus protected attachments or secure links. You keep subjects neutral and share passwords through another channel.

The exact mix depends on your work. For some, a locked PDF in an encrypted email is enough. For others, a secure link with tight rules is a better fit.

Can encrypted emails be forwarded?

People can forward almost any email. Forwarding a truly encrypted email may send only a link or shell. New readers often still need the right access to see content.

Suppose someone copies text from an open, encrypted email into a new plain message; that new email no longer has protection. Clear rules and quick training help staff avoid that step for private matters.

Read next

For a closer look at the nuts and bolts of a single encrypted send, read how to encrypt an email step by step. It links these ideas to real clicks and screens.

If you want more focus on the message content itself, open the “How to encrypt email messages” step-by-step guide. That guide stays with the text side of the story.

For tasks that should not live in email at all, see how to send a secure link. It shows how links can work with or instead of encrypted emails for your most sensitive data.