message encryption Archives | Page 2 of 2

March 9, 2026July 7, 2026

Encrypting Email in Outlook Using Native Tools and HIPAA Services

encrypting email outlook guide featured image

[mh_key_takeaways]

Outlook supports three built-in methods for encrypting email. Microsoft Purview Message Encryption, S/MIME certificates, and Sensitivity Labels each cover a different scenario. All three integrate with the standard Outlook compose experience.

This guide covers each method for encrypting email in Outlook, including the setup, the sender steps, and the recipient experience. It also covers when a separate HIPAA encrypted email service is a simpler fit.

The right method depends on plan level, recipient mix, and IT capacity. Read each section for the fit and pick the path that matches your practice.

Microsoft Purview Message Encryption Is the Default Path

Microsoft Purview Message Encryption is the default encrypted email path for Microsoft 365 Business Premium and higher plans. The sender uses the Encrypt button in the Outlook ribbon. Purview handles the encryption and delivery on the server side.

The sender opens a new message, clicks Options in the ribbon, clicks Encrypt, and picks either Encrypt-Only or Do Not Forward. Encrypt-Only allows the recipient to reply, forward, and print. Do Not Forward applies rights management and blocks those actions.

Purview supports recipients on Microsoft 365, Outlook.com, Gmail, and any other mail platform. External recipients on non-Microsoft platforms receive a notification email with a Read the message button. The button opens outlook.office365.com in a browser tab.

The recipient signs in with a Microsoft or Google account or requests a one-time passcode. The decrypted message displays inline with attachments listed below. Detailed sender instructions are in the Microsoft support guide for encrypted messages in Outlook.

The Encrypt Button Requires Business Premium or Higher

The Encrypt button in Outlook is not available on every Microsoft 365 plan. The required plans are Microsoft 365 Business Premium, Microsoft 365 E3, Microsoft 365 E5, Microsoft 365 Apps for Enterprise with Azure Information Protection Premium, or the standalone Azure Information Protection Premium license.

Business Basic, Business Standard, and Microsoft 365 Apps for Business do not include the Encrypt button. Adding it requires either an upgrade or a per-seat license add-on. The cost adds up quickly for practices with dozens of mailboxes.

Practices on lower Business plans have two options: upgrade every seat that needs to send encrypted mail, or use a separate HIPAA email service that works alongside Outlook without changing the license structure. The math depends on how many seats actually need to encrypt.

Front-desk staff sending appointment reminders may not need encryption. Clinicians sending patient records probably do. Map the actual send flow before committing to a plan upgrade.

encrypting email outlook in article illustration one

S/MIME Provides End-to-End Message Encryption

S/MIME is the older, standards-based encryption method for Outlook. It uses X.509 certificates issued by trusted authorities. The sender encrypts with the recipient public key. The recipient decrypts with the matching private key.

Setup happens in the Outlook Trust Center. Go to File, Options, Trust Center, Trust Center Settings, Email Security. Add the certificate under Digital IDs. Choose the encryption algorithm and hash. Enable digital signing and encryption on outgoing messages if you want defaults applied automatically.

Certificates come from DigiCert, Sectigo, IdenTrust, or an internal certificate authority in an Active Directory deployment. Cost runs from around fifty dollars per user per year for standard certificates to several hundred for enterprise deployments with automated renewal.

S/MIME works well when both parties have certificates. It does not work when the recipient does not. This limits S/MIME to internal use inside organizations with a managed PKI, or to external partners with a formal certificate exchange arrangement.

Sensitivity Labels Automate Encryption Decisions

Sensitivity Labels are the enterprise path to encrypted email in Outlook. Administrators define labels in the Microsoft Purview compliance portal and configure content-scanning rules that flag messages containing PHI, financial data, or other regulated fields.

Applied labels can require encryption automatically, restrict forwarding, block download of attachments, and apply retention rules. The sender does not have to decide. The label is applied by policy based on the content of the message.

Deployment requires Microsoft 365 E3 or E5 licensing and Microsoft Purview Information Protection configuration. The setup is significant. Content patterns, sensitive information types, and label rules all need to be defined and tuned to the practice.

Sensitivity Labels pay back at enterprise scale. A health system with hundreds of users benefits from centralized policy. A small practice with ten users usually does not. The setup effort exceeds the value at that scale.

[mh_example]

The Recipient Experience Is the Real Differentiator

The recipient experience varies across the three Outlook encryption methods. Purview messages open in a browser tab after sign-in or one-time passcode. S/MIME messages open in the mail client if the certificate is installed. Sensitivity Label messages open based on the label configuration.

The choice affects patient and vendor communications. External recipients on personal Gmail or Yahoo accounts see the Purview browser tab. That works but adds a step. External recipients with S/MIME certificates see the message inline in their client, but very few personal accounts have S/MIME set up.

Practices sending mostly to external recipients on mixed platforms usually pick Purview or a HIPAA email service. Both handle the external case with a portal or link fallback that does not require recipient setup.

Practices sending mostly to internal or partner recipients with managed PKI usually pick S/MIME for the inline experience. The choice matches the recipient mix.

encrypting email outlook in article illustration two

Encrypting Attachments Follows the Same Method as the Body

Attachments in Outlook encrypt through the same method as the message body. Purview encrypts attachments in the message envelope. S/MIME wraps attachments inside the encrypted message. Sensitivity Labels can also apply protection to attachments as a separate policy layer.

The recipient experience for attachments varies by method:

Purview Encrypt-Only allows download of attachments after decryption
Purview Do Not Forward blocks download and shows preview only
S/MIME attachments decrypt in the client and save locally as normal files
Sensitivity Labels can persist protection on the attachment even after download

Attachment size limits follow the sender platform. Outlook and Purview handle standard mail attachment sizes up to 150 megabytes on Microsoft 365 plans. Very large files should use OneDrive sharing links with rights management or a dedicated HIPAA file transfer service.

PHI-containing attachments still fall under HIPAA once the recipient decrypts the file. Downloaded local copies need the same protection as any other patient record. The encryption ends at the mail client boundary.

The BAA With Microsoft Covers the Platform Side

Microsoft signs a business associate agreement covering the Microsoft 365 services under the standard Microsoft 365 BAA terms. The BAA covers Exchange Online, SharePoint, OneDrive, Teams, and the encryption services under Microsoft Purview.

The BAA is available at no extra cost. Administrators accept the BAA in the Microsoft 365 admin center under the compliance section. The BAA becomes effective immediately and covers the tenant.

The BAA covers the Microsoft side. The covered entity is responsible for configuring the tenant correctly, maintaining access logs, training staff, and applying encryption to regulated content. HIPAA compliance is a shared responsibility. Microsoft handles the platform. The covered entity handles the practice-level configuration.

The HHS guidance on business associate agreements outlines the specific terms required. Practices should review the Microsoft BAA against the HHS requirements before signing.

[mh_protip]

Common Errors Break the Encryption Flow

Encrypting email in Outlook works reliably when configured correctly. Common errors that break the flow include license mismatch, missing certificate, and policy misconfiguration.

The most common issue is missing licensing. The Encrypt button does not appear on lower plans. Users try to send encrypted mail and the option is not available in the ribbon. Fix by upgrading the plan or adding the Azure Information Protection license.

S/MIME errors usually trace to certificate problems. Missing certificate, expired certificate, or certificate from an untrusted authority all break the encryption. Fix by installing or renewing the certificate through the Trust Center.

Policy misconfiguration on Sensitivity Labels is subtler. A label may not apply if the content pattern does not match, or a label may apply incorrectly on non-regulated content. Fix by tuning the sensitive information types and label rules in the Purview compliance portal.

HIPAA Practices Often Add a Second Layer

Healthcare practices often run Outlook alongside a dedicated HIPAA email service. Outlook handles day-to-day mail. The HIPAA service handles patient-facing messages that require verified encryption and a signed BAA specific to healthcare.

The two-layer approach separates concerns. General staff mail stays inside Outlook. Regulated mail routes through a service designed for the HIPAA case. Compliance auditors see clear separation between general and regulated flows.

The setup keeps Outlook simple. Users continue to send general mail through Outlook. They send patient records through the HIPAA service either from a browser interface or from an Outlook plugin. The audit trail comes from the HIPAA service.

This approach fits practices that use Outlook for scheduling, internal communication, and vendor mail, but need a dedicated tool for patient-facing PHI. It matches the workflow more closely than forcing every message through the Purview Encrypt button.

Mailhippo Fits Alongside Outlook for HIPAA Sends

Mailhippo secure email service works with existing Outlook accounts and adds a HIPAA-compliant encryption path without changing the Microsoft 365 plan. The signed BAA is included in the base plan. Recipients open messages through a one-click link with no account creation.

The sender uses Outlook for general mail. When a message contains PHI, the sender routes it through Mailhippo either from a browser interface or from an add-in. The message encrypts, delivers to the recipient link, and logs the send in the audit trail.

This split fits small and mid-size practices that already run Microsoft 365 Business Basic or Business Standard and do not want to upgrade every seat to Business Premium just to enable the Encrypt button. The Mailhippo per-seat rate covers the HIPAA-critical mail without disrupting the base Outlook plan.

The broader compliance picture also includes healthcare website security features and patient portal configuration. Encrypted email is one layer. The full stack covers websites, forms, and internal systems together.

[mh_faqs]

February 13, 2026July 7, 2026

How Do I Send Encrypted Email in Outlook, Gmail, and Yahoo

how do i send encrypted email guide featured image

[mh_key_takeaways]

Sending encrypted email is straightforward once you know which method your client supports. Outlook 365, Outlook 2010 through 2016, Gmail, and Yahoo each handle encryption differently, and the right method depends on both your sender platform and your recipient.

This guide walks through each client step by step, then compares the methods. If you need a service that layers on top of any of these clients with a signed business associate agreement, see the overview of encrypted email options.

The audience assumed here is a business user or clinician who wants to send an encrypted message today, not a developer building an integration.

How to send encrypted email in Outlook 365

Outlook 365 on Business Premium, Enterprise E3, or Enterprise E5 includes the Encrypt button in the Options ribbon. This is the fastest path if your account is on a qualifying plan.

Compose a new message. Click Options in the ribbon. Click Encrypt. Choose Encrypt-Only for a message the recipient can reply and forward. Choose Do Not Forward for a message where you want to restrict sharing.

Send the message. The recipient on your own tenant sees the message inline in Outlook with a lock icon. External recipients see a notification email with a Read the message button. Clicking the button opens the Office 365 message encryption portal in a browser.

Setup requires an admin to enable Azure Rights Management on the tenant. Full guidance is published by Microsoft in the Microsoft Purview Message Encryption reference. If Encrypt is missing from your ribbon, your tenant or license does not have Purview enabled.

How to send encrypted email in Outlook 2010, 2013, and 2016

These versions do not include the modern Encrypt button that appears in Outlook 365. Encryption uses S/MIME certificates and works well for organizations where both sender and recipient have certificates issued through corporate PKI or a public certificate authority.

Import your certificate through File, Options, Trust Center, Trust Center Settings, Email Security. Click Import Export and load your certificate file. Enter the password and complete the import. Outlook now has your certificate bound to your mailbox.

Compose a new message. In the message window, click Options in the ribbon, then click the small dialog launcher in the More Options group. In the Properties dialog, click Security Settings. Check Encrypt message contents and attachments. Click OK. Send.

The recipient needs a matching certificate to decrypt. This is where S/MIME breaks down for ad hoc external mail. For enterprise-to-enterprise and government correspondence, S/MIME works well. For consumer mail, use portal-based encryption instead. The how do I send an encrypted email in Outlook guide covers additional edge cases.

how do i send encrypted email in article illustration one

How to send encrypted email in Gmail

Gmail on Google Workspace offers two paths. Gmail on a personal account has no HIPAA-grade encryption option at all.

Confidential mode is available on every Gmail account. Click the padlock and clock icon in the compose window, set an expiration and a passcode option, and send. This restricts forwarding, printing, downloading, and copying. It does not encrypt content at rest inside Gmail systems.

Google Workspace client-side encryption applies true end-to-end encryption for qualifying tiers. An admin configures a client-side encryption identity for the account. Once configured, the sender can toggle client-side encryption on a message. Recipients must also be configured for client-side encryption to decrypt.

For the widest recipient reach and healthcare use, a dedicated secure email service that installs as a Gmail add-on gives you a Send Encrypted button that routes the message through the vendor. The recipient reads it in a portal. This is the simplest path for a solo practice or small clinic.

How to send encrypted email in Yahoo Mail

Yahoo Mail does not offer a built-in message encryption feature. There is no Send Encrypted button in Yahoo, and Yahoo does not sign a business associate agreement for HIPAA use.

Yahoo servers use TLS between mail servers, which protects messages in transit when the receiving server supports TLS. This is a baseline measure that any modern mail provider offers. TLS alone is not equivalent to end-to-end or message-level encryption.

To send encrypted email from a Yahoo address, you have two practical options. Use a third-party encryption service that can send on your behalf and reply through a portal. Or move the encrypted correspondence to a provider that supports encryption natively.

Yahoo is not a supported platform for HIPAA-covered mail. A therapist or medical office running client communications through a Yahoo address is not compliant regardless of what encryption is added on top of the sending experience. Change providers first.

[mh_example]

Comparing the encryption methods across clients

The methods trade off between ease of use, recipient reach, and compliance strength. This table lays out the practical differences.

Method	Sender platform	Recipient reach	Compliance-grade
Outlook 365 Encrypt button	Business Premium and up	Any recipient via portal	Yes with BAA on tenant
S/MIME certificate	Outlook 2010 to 2016 and 365	Recipients with certificates	Yes when configured
Gmail confidential mode	Any Gmail account	Any recipient	No, not on its own
Gmail client-side encryption	Qualifying Workspace tiers	Workspace with CSE identity	Yes with BAA on tenant
Yahoo native	None available	Not applicable	No
Dedicated encrypted email service	Any client with plug-in or web	Any recipient via portal	Yes with vendor BAA

Portal-based methods reach any recipient. Certificate-based methods only work between correspondents with matching PKI infrastructure. Choose based on who you actually send to.

For solo practices sending to patients on consumer email, portal-based encryption is the reliable default. The how to send encrypted email guide covers the sender workflow in more detail.

how do i send encrypted email in article illustration two

Choosing between Encrypt-Only and Do Not Forward in Outlook

Outlook’s Encrypt button gives two options that trip up new users. The right choice depends on how much control you need after the message leaves your outbox.

Encrypt-Only encrypts the message content and attachments. The recipient can reply and forward. Any forwarded copy remains encrypted. This is the right choice for a normal sensitive message where the recipient may legitimately need to share it with a colleague.

Do Not Forward encrypts the message and also blocks forwarding, reply-all, printing, copying, and attachment download. This is the right choice for a legal notice, an executive communication, or a message where you want tight distribution control.

Both options use Microsoft Purview Message Encryption underneath. The distinction is in the rights template applied to the message. Guidance on rights templates is in the Microsoft Azure Rights Management documentation.

Recipient experience across encryption methods

The sender picks the method. The recipient lives with it. Understanding the recipient experience for each method helps a sender choose the right one for the audience.

Portal-based encryption gives the recipient a notification email with a link. The recipient clicks, signs in with a one-time passcode or a linked account, and reads the message in a browser. First-time recipients often need a short explanation of the flow.

S/MIME opens the message inline in the recipient mail client once the recipient certificate is installed. There is no portal step. If the certificate is missing, the message body appears garbled or refuses to open.

Confidential mode from Gmail sends the recipient a link to a Google-hosted view where the message opens after optional passcode verification. Downloads and forwarding are blocked but the underlying storage is not encrypted at rest.

[mh_protip]

When each method is the right choice

Method choice comes down to who you send to and what compliance obligation applies. The following patterns match methods to typical use cases.

Sending to patients on any consumer email: portal-based encryption from Outlook 365 or a dedicated encrypted email service
Sending to another business on Microsoft 365: Outlook 365 Encrypt button, message opens inline for the recipient
Sending to a corporate or government recipient with existing S/MIME: import certificates and use S/MIME
Sending non-PHI internal-sensitive mail inside Google Workspace: Gmail confidential mode is acceptable for the sensitivity but not for HIPAA
Sending high-volume transactional email programmatically: a HIPAA-eligible email API through a vendor with a BAA

Match the method to the strictest requirement in the message flow. A healthcare practice that sends both internal-sensitive and patient-covered mail needs the patient-covered method for both, not the internal-sensitive method for the mix.

Practices with a website that also collects sensitive information should align their web infrastructure with the email choice. Redefine Web covers relevant patterns in the overview of healthcare website security features.

Troubleshooting common send failures

Encryption send failures usually trace back to configuration rather than the message itself. The following symptoms map to specific fixes.

Missing Encrypt button in Outlook 365 means the account is not on a qualifying plan or the tenant has not enabled Azure Rights Management. The fix is either a license upgrade or an admin action on the tenant.

S/MIME send fails with a certificate error means the recipient certificate is not available. Outlook cannot encrypt to a recipient whose public certificate has not been previously received. Ask the recipient to send you a signed message first so their certificate is captured.

Recipient reports the portal login fails with a one-time passcode. Passcodes expire after fifteen minutes. Ask the recipient to request a fresh code and use it immediately. Some corporate spam filters delay the passcode delivery past the expiration window, in which case an alternate email address is needed. The National Institute of Standards and Technology publishes recommended email security guidance in NIST SP 800-177 Rev. 1.

Setting up encrypted email once so future sends are easier

Sending encrypted email should not be a per-message decision. Configure the account once so the workflow is consistent across all correspondence.

For Outlook 365, ask your admin to set default encryption on messages to certain external domains through a mail flow rule. This means messages to patient addresses or partner accounts are always encrypted without the sender toggling the button.

For dedicated encrypted email services, install the Gmail or Outlook plug-in on every workstation used by clinical or administrative staff. Enable the default-encrypt behavior in the service settings so no untrained sender accidentally sends plain text.

Document the workflow in a one-page internal reference. Include screenshots of the Encrypt button, the confidential mode toggle, or the plug-in send button as appropriate. New staff can then reach compliant sending on their first day rather than after weeks of trial and error.

[mh_faqs]

February 2, 2026July 7, 2026

How to View Encrypted Emails in Outlook, Gmail, and Web Portals

how to view encrypted emails guide featured image

[mh_key_takeaways]

Encrypted email arrives in one of three formats, and the format determines the steps to view it. Portal-based delivery uses a notification with a secure link. S/MIME uses certificates that decrypt inside the mail client. Purview and Google client-side encryption open natively for recipients on the same platform.

This guide covers how to view encrypted emails across Outlook desktop, Outlook on the web, Gmail, Chrome, mobile clients, military OWA, and HCL Notes. Both consumer and enterprise scenarios are included. If you are sending rather than receiving, see the practical setup guides on encrypted email options.

The goal is to give a recipient the exact steps for their specific situation without wading through vendor documentation for a client they do not use.

Identifying which encryption method the sender used

Before opening the message, identify the encryption method. Every method looks slightly different in the inbox, and the visual cue is usually enough to pick the right steps.

Portal-based encryption arrives as a short notification email with a Read the message or View secure message button. The body contains no message content. The sender is usually a service address such as no-reply at the vendor domain.

S/MIME-encrypted messages arrive with a lock icon in the mail client if the client supports S/MIME. The body may show garbled text if the client cannot decrypt the message because the certificate is missing.

Microsoft Purview and Google client-side encryption messages open like normal messages inside Outlook or Gmail when the recipient is on the same platform. A lock icon and a note explaining the encryption appear at the top of the message body.

How to view an encrypted email in Outlook on the desktop

Outlook desktop handles two scenarios. Messages encrypted with Microsoft Purview from another Microsoft 365 sender open automatically inside Outlook when the recipient is signed into a compatible account. No extra steps are needed.

Messages encrypted with S/MIME require the recipient certificate installed in the Outlook Trust Center. Open File, Options, Trust Center, Trust Center Settings, then Email Security. The Import button loads a certificate from a file, and the certificate is then available for decryption.

Messages that arrive as a notification with a Read the message button use portal-based encryption. Clicking the button launches a browser window from Outlook. The browser handles the sign-in and decryption, not Outlook itself. How to view an encrypted email in Outlook covers the button-click flow in more detail.

Microsoft’s own documentation for Purview Message Encryption is published in the Microsoft Purview Message Encryption reference.

how to view encrypted emails in article illustration one

How to view an encrypted email in Outlook on the web

Outlook on the web behaves similarly to Outlook desktop for Purview-encrypted messages. The message renders inline for Microsoft 365 recipients. External recipients receive a notification with a link that opens the Office 365 message encryption portal.

The portal offers three sign-in methods. A Microsoft account, a Google account, or a one-time passcode sent to the recipient email address. Choose the method that matches the account associated with the receiving mailbox.

The one-time passcode option is the fallback when the recipient does not have a Microsoft or Google account tied to the address. Microsoft sends the passcode to the same email address that received the notification. Passcodes expire after fifteen minutes, so request a new one if the sign-in fails.

After sign-in, the portal displays the message content and offers Reply, Reply All, and Forward. Replies from the portal are also encrypted, which preserves the security of the conversation even when the recipient does not have their own encryption setup.

How to view encrypted email in Gmail on desktop and mobile

Gmail supports two encryption paths for reading messages. Google Workspace client-side encryption opens automatically for Workspace users whose account has a client-side encryption identity configured. Personal Gmail accounts do not support this feature.

For portal-based encrypted messages from other vendors, the notification arrives in the Gmail inbox with a link. Clicking the link opens a browser tab with the vendor portal. Sign in with a passcode you set on first access, or with a linked account.

The Gmail mobile app on iOS and Android opens the notification link in a mobile browser or in-app browser. The vendor portal loads the same as on desktop. Some portals detect the mobile view and adjust the layout.

Google publishes client-side encryption setup guidance in the Google Workspace admin help. The article covers admin configuration for enabling the feature in a Workspace tenant.

[mh_example]

Comparing native, portal, and certificate-based viewing

The three approaches trade off between recipient convenience, sender flexibility, and administrative complexity. This table lays out the differences.

Method	Recipient experience	Setup on recipient side	Best fit
Portal-based encryption	Click link, sign in, read	None	External recipients on any platform
Microsoft Purview native	Opens inline in Outlook	Microsoft 365 mailbox	Business-to-business Microsoft users
Google client-side encryption	Opens inline in Gmail	Workspace with CSE identity	Workspace-to-Workspace
S/MIME certificate	Opens inline once certificate installed	Certificate import required	Enterprise, government, military

The choice of method usually comes from the sender, not the recipient. Understanding what each method looks like on the receiving side helps a recipient troubleshoot correctly when a message will not open.

Practitioners sending encrypted email to clients on any platform usually pick portal-based encryption for the reach, then add S/MIME or Purview for specific counterparties who prefer native inline viewing.

How to view encrypted military email through OWA

Military recipients accessing DoD email through Outlook Web Access need a Common Access Card and a reader. The card holds the certificates that decrypt encrypted email arriving at the military mailbox.

On a government workstation, the reader and middleware are pre-installed. Insert the CAC, sign in with the PIN, and the encrypted message opens inside OWA the same way as a normal message.

On a personal computer, the setup is more work. Install the DoD root certificates through the InstallRoot utility, connect a compatible CAC reader, and install middleware such as ActivClient. Once the browser recognizes the card, OWA works.

Encrypted messages will not open in a browser that cannot access the card, which is the source of most home-computer OWA issues. If the browser prompts for a certificate but no options appear, the card reader is not connected correctly or the middleware is not installed.

how to view encrypted emails in article illustration two

How to view encrypted email in HCL Notes and legacy Lotus Notes

HCL Notes, formerly Lotus Notes, handles S/MIME-encrypted messages through the Notes ID file. Import the recipient certificate into the ID file, and Notes decrypts the message when opened.

Import the certificate through File, Security, User Security, Your Identity, and Your Certificates. Choose the option to import an internet certificate and select the certificate file. The certificate is then bound to the Notes ID.

For portal-based encrypted messages, click the notification link. Notes opens the link in the default browser. Notes itself does not render the portal inline. This is the same experience as any modern mail client receiving a portal notification.

Users on older Notes versions who cannot import certain modern S/MIME certificates should raise a support ticket with the Notes administrator. Some newer certificate formats are not supported on very old Notes releases.

Why cannot view encrypted emails in Outlook and how to fix it

Recipients who see an encrypted message in Outlook but cannot open it usually run into one of a few specific problems. The fixes are targeted rather than general.

Missing S/MIME certificate: import the certificate through Trust Center, Email Security
Expired certificate: request a new certificate from the sender or the certificate authority
Email address mismatch on the certificate: the certificate must match the mailbox address exactly
Notification message in the junk folder: check junk and mark the sender safe
Browser cookies disabled for the portal domain: enable cookies for the vendor portal
Corporate proxy blocking the portal: ask IT to allowlist the vendor portal domain

The most common single cause is the notification message landing in junk. Many recipients assume the message never arrived when the notification was filtered before they saw it.

A recipient who has followed the steps above and still cannot open the message should reply to the sender through a separate channel and request the message be resent, potentially with a different method. Vendor differences matter here. The how to open encrypted emails in Outlook guide covers vendor-specific patterns.

[mh_protip]

Mobile viewing on iOS and Android

Portal-based encryption works well on mobile. Tap the notification link, and the vendor portal opens in the mobile browser. Sign-in works the same way as on desktop.

S/MIME on iOS requires the recipient certificate installed through Settings, General, VPN and Device Management. The certificate is delivered as a profile file. Once installed, iOS Mail decrypts S/MIME messages automatically.

Android S/MIME support depends on the mail app. Gmail on Android supports S/MIME for Workspace accounts with the S/MIME setting enabled. Outlook Mobile on Android supports S/MIME through corporate deployment. Third-party mail apps vary.

CAC-encrypted mail on mobile requires a card reader accessory that connects through Lightning or USB-C. Personal use of CAC on mobile is rare, but government-issued mobile deployments configure it directly. Guidance on federal mobile security is published by CISA cybersecurity best practices.

Best-practice recipient workflow for repeated encrypted senders

When a recipient regularly gets encrypted messages from the same sender or vendor, a small amount of setup work removes friction from every future message.

Save the vendor portal in bookmarks. Enable cookies for the portal domain permanently rather than accepting them each time. Set a memorable passcode on first access so return visits use the account credential rather than a one-time code.

For S/MIME, keep the certificate current. Certificates typically expire after one to three years. Renew before expiration to avoid a gap where new encrypted messages cannot be decrypted.

For clinicians and practices that regularly receive encrypted email from patients or insurers, a dedicated secure email service account gives one interface for both sending and receiving instead of managing multiple portal logins.

When to ask the sender to switch encryption methods

Not every encryption method works for every recipient. If a certain vendor portal is unreliable in your environment or a certificate model does not fit, ask the sender to switch.

Senders using Microsoft Purview can send to any recipient email address through the portal fallback. Senders using Google client-side encryption can only reach recipients whose Workspace account is also configured for client-side encryption.

A recipient who consistently cannot open Purview messages because of a proxy or filter should ask the sender to send through a different method. Most senders can send through both Purview and a dedicated encrypted email service depending on the recipient.

Healthcare providers running their own secure communication workflow can align their own patient-facing website security decisions with what their patients experience, guided by principles in Redefine Web’s overview of healthcare website security features.

[mh_faqs]