🔑 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.
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.
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.
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.
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
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.
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.
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.
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.
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.
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.
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.
