🔑 Key Takeaways
- Encrypted email means ciphertext in transit and at rest, decoded only by the recipient's key.
- Gmail auto-encrypts transport via TLS, but true content encryption needs S/MIME on Enterprise Plus.
- S/MIME forwards re-encrypt per recipient; portal messages usually can't be forwarded at all.
- You get encrypted mail when a provider, lawyer, or insurer applies encryption to protect the thread.
- Encryption stops interception, not phishing or malware. Layer MFA and endpoint protection on top.
Encrypted emails are messages you cannot read without the right key or credential. The concept is simple. The specific methods, recipient experiences, and edge cases behind it are where confusion starts.
This guide covers what encrypted emails actually are, how Gmail and Outlook handle them, whether they can be forwarded, and how to tell a legitimate encrypted message from a phishing attempt. For senders evaluating an encrypted email service, the recipient experience is often more important than the technical specs.
Read the sections in order. Each one covers a specific question users typically ask.
Encrypted Emails Turn Message Content Into Unreadable Ciphertext
An encrypted email is a message where the content has been transformed into ciphertext that only the intended recipient can decode. Encryption applies at one or more layers of the email delivery path.
Transport encryption using TLS protects the message between mail servers. The message body is readable at the servers themselves but not on the network between them.
Content encryption using S/MIME or PGP protects the message body itself. The message stays encrypted at the recipient mail provider until decrypted by the recipient with a matching key.
Portal-based encryption stores the message on a vendor server and delivers a sign-in link. The recipient authenticates to the vendor portal and reads the message in a browser.
Each method covers different threats. Best practice layers TLS with content or portal encryption rather than relying on transport alone.
Gmail and Encrypted Email Behavior
Gmail encrypts messages automatically for transport but not for content by default. Understanding the difference clears up common questions about Gmail encryption.
Google Workspace uses TLS 1.2 or 1.3 when connecting to receiving servers that support it. Standard consumer Gmail does the same. This transport encryption prevents interception on the network path.
Content encryption in Gmail requires Google Workspace Enterprise Plus for S/MIME. The administrator provisions certificates for users and enables encrypted sending inside the workspace policy.
Add-ons like FlowCrypt and Mailvelope bring PGP-based encryption to any Gmail account. The user installs the browser extension, generates a key pair, and encrypts messages one at a time.
Google Confidential Mode is not content encryption. It adds expiration and access controls but Google retains access to the underlying content. Practices should not treat Confidential Mode as HIPAA-compliant encryption.

Outlook and Encrypted Email Behavior
Outlook supports S/MIME natively across Microsoft 365 Business Premium and higher tiers. The certificate installs into the local certificate store and enables signed and encrypted sending.
Microsoft Purview Message Encryption adds a policy-based layer that triggers on rules configured by the administrator. External recipients receive a portal link and sign in with Microsoft, Google, or a one-time passcode.
Third-party add-ins from Virtru, Mailhippo, and other vendors add another encryption path that works across Microsoft 365 tiers without requiring Business Premium.
Outlook shows encrypted messages with a padlock icon in the header. The message properties confirm the encryption method and certificate details.
Users can verify a sent message was encrypted by checking the Sent Items folder for the same padlock indicator. Related coverage in encrypted emails Outlook covers the specific configuration steps.
Forwarding Encrypted Emails Changes the Encryption Context
Encrypted emails can sometimes be forwarded but the encryption context often changes depending on the method and sender policy.
S/MIME messages forwarded from Outlook typically get decrypted with the original recipient key and re-encrypted for the forward recipient if forwarding is permitted. The forward recipient must have a matching certificate or the message will not decrypt on their end.
Portal-based encrypted messages usually cannot be forwarded because the recipient holds a portal access link, not the underlying content. Some vendors allow the recipient to share the portal link with another user, subject to sender policy.
Sender-set rights management controls decide what forwarding is allowed. Microsoft Purview Message Encryption supports Do Not Forward as a rights template that blocks forwarding entirely.
Practices sending regulated content should default to Do Not Forward and enable forwarding only when the sender explicitly permits it. Blanket forwarding permissions undermine the sender control that encryption otherwise provides.
Encrypted Email Comparison Across Common Methods
The table below compares four common encryption methods across the fields that decide recipient experience and security posture.
| Method | Recipient Steps | Content Encrypted at Rest | Forwarding Behavior | Typical Use |
|---|---|---|---|---|
| TLS Transport Only | None | No | Freely forwardable | Standard business email |
| S/MIME | Certificate installed | Yes | Re-encrypted per recipient | Enterprise between certificate holders |
| PGP | Key installed | Yes | Re-encrypted per recipient | Technical users, journalists |
| Portal Encryption | Click link, sign in | Yes on vendor server | Usually blocked | Healthcare, finance to external recipients |
Real-world deployments often layer TLS with either content or portal encryption. The layered approach covers more threats than any single method alone.
Why You Might Be Getting Encrypted Emails
Recipients often receive encrypted emails without expecting them. The reasons are usually straightforward.
A healthcare provider sending PHI encrypts to protect patient information under HIPAA. Test results, appointment details, and billing statements often arrive encrypted.
A financial services firm sending account details encrypts to protect against fraud and to meet GLBA requirements. Statements, tax documents, and account changes often arrive encrypted.
A legal counterparty sending privileged material encrypts to protect attorney-client privilege. Settlement documents, court filings, and case correspondence often arrive encrypted.
An employer sending HR content encrypts to protect employee records. Offer letters, tax forms, and performance reviews often arrive encrypted.
Legitimate encrypted messages come from known senders and route through recognizable vendors like Microsoft, Google, Mailhippo, Virtru, or Barracuda. Suspicious encrypted messages from unknown senders should be treated as potential phishing.

Phishing Increasingly Mimics Encrypted Email Delivery
Phishing campaigns increasingly use fake encryption portals to harvest credentials. Recognizing the pattern reduces the risk of falling for one.
Fake encrypted email notifications typically arrive from unfamiliar senders and reference a document you did not expect. The link goes to a domain that looks similar to a real vendor but does not match.
The fake portal asks for the email password or a Microsoft account sign-in. Legitimate portals ask for a one-time passcode sent to your address or a sign-in with an existing account you recognize.
The CISA phishing guidance covers common patterns and what to do if you suspect a phishing attempt.
Best practice verifies the sender through a separate channel before clicking any encrypted email link from an unfamiliar source. A phone call to a known number is worth thirty seconds of caution.
Are Encrypted Emails Actually Safe
Encrypted emails are safer than unencrypted emails against interception and provider-side access. They do not defend against every threat.
Phishing attacks that steal mail credentials bypass encryption by giving the attacker legitimate access to the inbox. The attacker sees the plaintext through the same interface as the real user.
Malware on the sender or recipient device captures plaintext before encryption or after decryption. Keyloggers, screen scrapers, and clipboard monitors all bypass the encryption layer.
Weak recipient portal passwords make encryption meaningless. A message encrypted with AES-256 protected by a password of qwerty is not protected in any meaningful sense.
Real security posture layers encryption with multi-factor authentication, endpoint protection, phishing training, and incident response. Each layer covers threats the others miss.
Shared Mailboxes and Encrypted Messages
Shared mailboxes complicate encrypted email handling. The complications matter more for regulated content than for general business email.
S/MIME-encrypted messages in a shared mailbox require the mailbox owner or delegated user to have a matching certificate. If the certificate is tied to an individual account, other delegates cannot decrypt.
Portal-encrypted messages in a shared mailbox arrive as notification emails. Anyone with credentials to the portal can sign in and read the content. This model preserves recipient anonymity at the cost of audit clarity.
Best practice restricts encrypted PHI or sensitive content to named individual mailboxes rather than shared ones. The audit trail stays clean, and inadvertent access by delegated users does not happen.
Practices with shared inboxes for reception or billing should route PHI through a named clinical inbox and reserve the shared inbox for non-PHI communication.
Related Encrypted Email Reading
Encrypted emails cover multiple adjacent topics. The companion guides below add depth on specific questions.
Users trying to open a specific encrypted message can review how to open encrypted emails in Outlook and how to view encrypted emails. Both guides cover the recipient-side workflow across common vendors.
Senders configuring encrypted sending in Outlook benefit from encrypting emails in Outlook. The guide covers S/MIME setup and the ribbon controls.
Users comparing encryption providers can review ProtonMail encrypted email for a specific vendor deep-dive. ProtonMail illustrates a pure E2EE approach.
Broader coverage of whether standard email is encrypted at all lives in are emails encrypted. The guide covers the transport-only default across major providers.
Where Redefine Web Fits the Healthcare Email Stack
Encrypted email covers the message pipeline. Website contact forms, patient portals, and marketing platforms carry PHI that must reach the same encryption controls.
A contact form on the practice website that emails PHI to a generic Gmail address bypasses every encryption control the practice buys. The submission arrives unencrypted, and the audit trail does not exist.
Redefine Web builds HIPAA-aware healthcare websites and integrates the forms with encrypted delivery paths. Details on the healthcare marketing agency practice cover the surface area that sits alongside encrypted email.
A closed-loop review across website, forms, email, and portal reduces the risk that a PHI leak lands in an unencrypted channel by mistake.
Mailhippo fits senders that want encrypted email delivery with the BAA, audit logging, and simple recipient experience in one product. The service integrates with existing Gmail or Outlook accounts and keeps the recipient path to a single click for most messages, whether the recipient is on Gmail, Outlook, or another provider. Understanding what encrypted emails are makes the vendor conversation shorter and the buying decision more defensible.








