[mh_key_takeaways]
Reading an encrypted email is not one process. The steps depend on how the sender encrypted the message. Portal encryption, S/MIME, and PGP each require a different action on the recipient side.
The most common encrypted email in healthcare is portal-based delivery from a HIPAA-compliant encrypted email service. The recipient sees a notification, clicks a link, and authenticates in the browser. S/MIME and PGP require more setup on the recipient device and produce more support tickets when something goes wrong.
This guide walks through each format, the specific steps in Outlook, Gmail, and iPhone Mail, and the common failure modes. Sibling coverage of how a recipient reads encrypted email supplies the recipient-perspective overview.
Identify the encryption method before opening the message
Every encrypted email has a signature that identifies the method. The subject line, sender name, and body preview usually contain enough information to route the message to the right decryption workflow.
Portal-based encrypted email usually arrives with subject lines like Secure Message From, Encrypted Message, or You have a secure message. The body contains a short paragraph and a button or link labeled Read the message or View secure message. No attached ciphertext is visible.
S/MIME encrypted email arrives with a lock icon in Outlook or Apple Mail. The message body appears blank in a client that lacks the certificate, or shows a warning like Unable to decrypt or Missing certificate. There is no portal link.
PGP encrypted email arrives with an attachment or inline block of ciphertext that starts with BEGIN PGP MESSAGE. The recipient needs a PGP client such as GPG Suite on macOS, Kleopatra on Windows, or a PGP-aware mail plugin.
Reading a portal-based encrypted email in any browser
Portal-based encryption is the pattern used by Microsoft Purview Message Encryption, most HIPAA email vendors, and healthcare-specific secure messaging platforms. The workflow is identical across desktop and mobile clients because the actual message content is displayed in a browser rather than the mail client.
The steps to open a portal-based encrypted email:
- Open the notification email in your inbox
- Tap or click the Read the message or View secure message link
- Sign in with Microsoft, Google, or a one-time passcode delivered to your email
- The decrypted message displays in the browser session
- Reply from within the browser to keep the message thread encrypted
One-time passcode flow is worth noting. The passcode arrives as a separate email, typically from a service address at the sender domain. Recipients sometimes assume the passcode message is a phishing attempt because it arrives right after the encrypted notification, and they delete it. Watch the inbox for the passcode message specifically.
The session expires after a period defined by the sender policy, usually between fifteen minutes and one hour of inactivity. Closing the browser tab ends the session and requires a new sign-in to reopen the message.
Reading encrypted email in Outlook desktop
Outlook desktop on Windows and macOS handles both portal-based and S/MIME encrypted email. The behavior depends on the message type and on how the client is configured.
Portal-based messages appear in Outlook with an embedded Read the message button. Clicking the button opens the default browser and follows the portal authentication flow described above. Outlook 365 running in the same tenant as the sender can display the decrypted message inline without leaving the client, using a preview pane provided by the encryption service.
S/MIME messages require a certificate installed in the Windows Certificate Store under Personal, Certificates. Outlook automatically detects the matching certificate and decrypts the message when it is opened. If the certificate is missing, Outlook displays a red banner and the message body remains blank.
To check installed certificates in Outlook, open File, Options, Trust Center, Trust Center Settings, and Email Security. The Digital IDs section lists the certificates available for encryption and signing. If nothing is listed, the certificate has not been installed on this profile.
Reading encrypted email in Outlook on the web
Outlook on the web at outlook.office.com and outlook.live.com handles portal-based Microsoft Purview messages natively. When the notification arrives, the message opens in a special decryption pane inside the Outlook interface without requiring a separate browser tab.
The message displays with a banner at the top identifying it as a protected message and listing any usage restrictions like Do not forward or Do not print. Attachments can be downloaded, viewed, and re-encrypted on save depending on the sender policy.
Outlook on the web does not natively support S/MIME on all account types. Outlook.com consumer accounts do not support S/MIME. Microsoft 365 business and enterprise accounts support S/MIME through a browser extension that must be installed separately. Encrypted messages that require the S/MIME extension display a prompt to install it before showing the decrypted content.
Session behavior in the browser matches the desktop client. The decrypted message content is retained in the browser tab, and closing the tab ends the session. Reopening the message requires re-authentication with the identity provider.
[mh_example]
Reading encrypted email in Gmail
Gmail on the web and mobile handles encrypted email in one of two ways depending on the source. Portal-based messages from Microsoft-based senders and from HIPAA email vendors arrive as standard notification emails with a link to the sender portal, and the recipient authenticates in the browser exactly as described above.
Google Workspace Enterprise Plus and Education Plus tiers support client-side S/MIME encryption. When both sender and recipient are on those tiers and have S/MIME configured through the admin console, encrypted messages decrypt inline in Gmail with no external portal. The lock icon in the message header indicates S/MIME encryption is active.
Consumer Gmail addresses at gmail.com do not support opening S/MIME encrypted messages. Any S/MIME message sent to a consumer Gmail address arrives as an attachment with a .p7m extension that Gmail cannot decrypt. This is a common source of confusion when a healthcare provider tries to send S/MIME to a patient at a personal address.
The workaround is to use portal-based encryption for external recipients. A HIPAA-compliant secure email service that delivers messages through a portal removes the requirement for the patient to have any specific email client or certificate. This mention concludes the product context for this article.
Reading encrypted email on iPhone and iPad
Apple Mail on iPhone and iPad handles portal-based encrypted email through Safari and supports S/MIME natively when a personal certificate is installed as a configuration profile.
Portal messages behave identically to any other email with a link. Tap the Read the message link, complete the browser sign-in, and view the decrypted content in Safari. The session ends when the browser tab is closed, and the message is not stored decrypted in the Mail app.
S/MIME on iPhone requires the certificate to be installed and the correct account settings enabled. The steps to configure S/MIME on iPhone:
- Email the .p12 certificate file to yourself and open it on the device
- Install the profile through Settings, General, VPN and Device Management
- Enter the certificate password when prompted
- Open Settings, Mail, Accounts, select the account, tap Advanced
- Enable S/MIME and select the installed certificate under Sign and Encrypt by Default
Once configured, Apple Mail decrypts inbound S/MIME messages automatically. The lock icon appears in the message header, and the content displays inline. Sibling coverage on how to send encrypted email in iPhone covers the outbound side.
Handling TLS-encrypted email that shows as unreadable
TLS is a transport-layer protocol that encrypts email in transit between sending and receiving mail servers. Once the message arrives at the recipient mail server, it is stored decrypted in the mailbox. TLS-encrypted email should never appear as unreadable ciphertext to the recipient because the decryption happens automatically at the mail server layer.
When users search for how to read TLS encrypted email, they are usually looking at a message that was encrypted with a different method and mislabeled. TLS does not require any recipient-side action to read. If a message appears as ciphertext, check for S/MIME headers, PGP block markers, or a portal notification pattern instead.
One edge case does exist. Enforced TLS with a specific recipient domain can cause a message to bounce rather than deliver in plaintext, and the bounce notification sometimes describes the message as encrypted or protected. The sender needs to resolve the TLS negotiation failure with the receiving mail server rather than the recipient attempting to decrypt anything.
The Microsoft Exchange mail flow rules documentation covers the specific enforcement conditions that produce this behavior in enterprise environments.
[mh_protip]
Reading old encrypted email after a device or account migration
Historical S/MIME encrypted email requires the historical private key that was used to encrypt those specific messages. A new certificate issued after the messages were received cannot decrypt them. The old certificate has to be recovered from backup or exported from the previous device before the migration.
On Windows, export the certificate from certmgr.msc as a .pfx file including the private key. On macOS, export from Keychain Access as a .p12 file. Import the file on the new device using the same tool. Outlook and Apple Mail then automatically use the imported certificate to decrypt historical messages.
Portal-based encrypted email that has passed its retention window cannot be read regardless of what the recipient does. The message content is deleted from the portal after expiration, and the sender must resend from the original source if the content is still needed.
Journaling and archive systems that captured the messages at the sender side may still have decrypted copies available for the sender to retrieve. This is a recovery path for the sending organization but not for the individual recipient.
Common decryption errors and how to resolve them
Decryption failures cluster around a small number of root causes. Working through them in order usually resolves the issue without contacting the sender.
- Missing certificate. Install the personal S/MIME certificate on the device and reopen the message
- Expired portal link. Contact the sender and request the message be resent
- Wrong browser session. Open the portal link in a browser where you are already signed in to the identity provider
- Passcode not received. Check spam folders for the one-time passcode message
- Client does not support the encryption method. Open the message in a different client that supports the method
- Certificate on wrong device. Export the certificate from the correct device and import on the current one
If none of these resolve the issue, the message may have been encrypted with a method the recipient environment cannot support. The sender should be asked to resend using portal-based encryption, which works across every mail client and every operating system with no recipient setup. Sibling coverage of how to troubleshoot encrypted email walks through the diagnostic sequence in more detail.
The Google Workspace S/MIME documentation and the Microsoft Purview Message Encryption documentation are the canonical references for platform-specific errors.
Encrypted email in a healthcare context requires reliable recipient experience
Patients receiving encrypted email from a healthcare provider do not have IT support and cannot install certificates or configure profiles. Any encryption method that requires recipient-side setup produces a support burden that falls on the practice front desk.
Portal-based delivery removes almost all of that friction. The patient receives a notification, clicks a link, authenticates with a passcode or existing Microsoft or Google account, and reads the message. No installation, no certificate management, no client-specific instructions.
Practices sending test results, appointment reminders, and billing statements should default to portal-based encryption for external recipients. Sibling coverage of how to send encrypted email covers the sender side of the same workflow.
Related healthcare marketing coverage is available at Redefine Web healthcare website security features and the healthcare marketing hub for practices coordinating email compliance with website and portal security.
[mh_faqs]
