Is Email Encrypted by Default: What TLS and End-to-End Encryption Actually Protect and Where the Security Gaps Remain

Most email providers encrypt messages in transit using Transport Layer Security (TLS), so the short answer to whether email is encrypted by default is a qualified yes. That default hides a dangerous gap. TLS encrypts the connection between mail servers, never the message itself, which means the provider can still read messages sitting on its servers.

According to the FBI Internet Crime Complaint Center's 2025 Internet Crime Report, phishing and spoofing generated 191,561 complaints, the highest number of reports of any category. The same encrypted connection that carries legitimate mail delivers those phishing emails, business email compromise (BEC) attempts, and credential-harvesting links just as reliably.

Encryption provides confidentiality. It does nothing to verify whether the person on the other end of an encrypted connection is who they claim to be. This guide covers:

• How TLS and opportunistic encryption determine whether email is encrypted by default, and where the silent fallback to plaintext happens,
• The critical difference between transport-layer encryption and end-to-end encryption when email is not encrypted by default end to end,
• What S/MIME and PGP actually protect, and how major providers from Gmail to Microsoft 365 handle default email encryption,
• Which compliance regulations mandate encryption, and why email is encrypted by default only in transit falls short of them,
• What encryption cannot stop, from phishing to human error, even when email is encrypted by default.

Most organizations assume in-transit encryption makes email private, leaving sensitive messages readable on third-party servers. Adaptive Security trains employees to recognize when a communication channel lacks the protection it appears to have.

Take a self-guided tour

What Default Email Encryption Is and How It Works

Email encryption encodes message content into ciphertext so that only the intended recipient with the correct decryption key can read it. When properly implemented, it renders intercepted messages useless to cyberattackers even if they gain access to the network or server where the message resides. Whether email is encrypted by default depends entirely on the provider, the method, and the state the message is in at any given moment.

Email was never designed with security in mind. The first email protocols, developed in the early 1970s on ARPANET, transmitted messages as plaintext across a network of trusted researchers. No one foresaw a medium that would carry financial instructions, medical records, and trade secrets across a hostile global internet.

That mismatch left the entire ecosystem retrofitting encryption onto a foundation that assumed every participant was friendly.

How Default Email Encryption Scrambles and Unscrambles Messages

Email encryption relies on two cryptographic approaches working together. Symmetric encryption uses a single shared key to both encrypt and decrypt a message; it is fast and efficient but creates a key-distribution problem, because both parties must possess the same secret before communication begins. Asymmetric encryption, also called public-key cryptography, solves this with mathematically linked key pairs: a public key that anyone can use to encrypt a message, and a private key that only the recipient holds to decrypt it.

In practice, modern email encryption combines both methods. The sender's system generates a one-time symmetric key to encrypt the actual message content, then encrypts that symmetric key with the recipient's public key. Only the recipient's private key can unlock the symmetric key, which in turn decrypts the message, delivering the speed of symmetric encryption with the key-distribution convenience of asymmetric cryptography.

The strength of this system rests on computational complexity. Algorithms like AES-256 and RSA-2048 rely on mathematical problems, brute-force key search for AES and integer factoring for RSA, that would take even the most advanced computers billions of years to solve. The ciphertext appears as random data, meaningless without the corresponding private key.

Encryption at Rest, in Transit, and in Use

Email encryption does not operate as a single on-off switch. It functions across three distinct states, and understanding where each one applies determines whether email is encrypted by default in any meaningful sense for a given organization.

Encryption at rest protects messages stored on servers, hard drives, or backup systems. When a provider offers encryption at rest, stored messages are scrambled on disk so that anyone with physical access to the server, or a cyberattacker who compromises the storage layer, cannot read them without the appropriate keys. Major providers including Google and Microsoft encrypt data at rest by default, though the provider itself typically holds the decryption keys.

Encryption in transit protects messages as they move between a device, a mail server, and the recipient's mail server using TLS. When TLS is active, anyone intercepting network traffic between these hops sees only encrypted data. According to the Google Transparency Report, Safer Email section, 88% of outbound email from Gmail is now encrypted in transit, up from 73% when the report launched in 2014.

Encryption in use protects data while it is actively being processed, read, composed, or searched in system memory. This remains the hardest state to secure and the one least commonly addressed by email providers. Without encryption in use, a compromised server process or memory-scraping cyberattack can extract email content even after it was encrypted at rest and in transit.

Transport-Layer vs. End-to-End: The Two Broad Categories

Email encryption falls into two fundamentally different categories, and conflating them is one of the most common and dangerous misunderstandings in organizational security. The distinction determines whether email is encrypted by default against network eavesdroppers only, or against every intermediary in the delivery path.

Transport-layer encryption (TLS) encrypts the connection between mail servers during delivery. When someone sends an email through Gmail or Microsoft 365, TLS establishes an encrypted tunnel between the sending provider's servers and the recipient provider's servers, protecting the message from eavesdropping on the network path.

The limitation is critical, because the message is decrypted at each server hop. The sending provider can read it, the recipient's provider can read it, and if either server is compromised, the message is exposed.

TLS also uses opportunistic encryption by default, so if the recipient's server does not support TLS, the message can fall back to plaintext delivery without alerting the sender.

The crucial distinction is that any email system involves more than the two endpoints. Intermediary mail servers sit in the middle of every exchange, and with TLS-encrypted email those intermediaries can read every message.

End-to-end encryption (E2EE), implemented through protocols like S/MIME and PGP, encrypts the message on the sender's device and keeps it encrypted until the recipient decrypts it on their device. No intermediary server ever possesses the unencrypted content, so even if a cyberattacker breaches the email provider's infrastructure, the stored messages remain unreadable ciphertext.

S/MIME relies on certificate authorities to verify identities and is commonly deployed in enterprise environments through Microsoft Outlook and Apple Mail. PGP instead uses a decentralized web-of-trust model and remains popular among security-conscious individuals and journalists. Both protocols encrypt only the message body and attachments, never metadata like sender, recipient, or subject lines.

The practical difference between TLS and E2EE determines whether sensitive data is genuinely protected or merely shielded from casual network eavesdroppers.

For routine correspondence, TLS provides reasonable baseline security. For regulated data, financial instructions, or confidential communications, the reality is that email is not encrypted by default end to end, leaving messages readable on third-party servers, accessible to administrators, discoverable in legal proceedings, and vulnerable in a breach.

According to the FBI Internet Crime Complaint Center's 2025 Internet Crime Report, business email compromise remains the persistent risk at the costly center, accounting for $3.046 billion in losses across 24,768 incidents, averaging $123,000 per case. Organizations that handle protected information need to understand exactly which encryption state applies to each message type and close the gaps that plaintext-era architecture left behind.

Security teams that treat in-transit encryption as end-to-end privacy expose regulated data to provider access and legal discovery. With Adaptive Security, recognizing when a communication lacks real protection becomes a reflex employees carry into every inbox.

Explore the platform

Is Email Encrypted by Default? Understanding TLS and Opportunistic Encryption

Yes, most major email providers encrypt email in transit using TLS, but this default is opportunistic rather than guaranteed. TLS encrypts only the connection between mail servers; it does not encrypt the message itself end to end, and it does not protect the content once it lands in the recipient's inbox. If the receiving mail server does not support TLS, the email may be delivered in plaintext with no warning to either party, and the sender will never know it happened.

The Short Answer: Email Is Encrypted by Default in Transit, and Only Opportunistically

The question of whether email is encrypted by default really bundles three separate questions together, and the answer is different for each. Separating them is the only way to move from a comforting assumption to an accurate picture of risk.

The first question is about encryption in transit, what happens while the message travels across the internet between mail servers. On this front, the answer is a qualified yes, because the vast majority of email traffic between major providers now uses TLS during the server-to-server hop.

This is a dramatic improvement from the report's 2014 launch, when only about 73% of outbound and 61% of inbound Gmail messages were encrypted in transit. Today the default posture has flipped, with TLS on by default and plaintext the exception.

The second question concerns what TLS actually protects. TLS creates an encrypted tunnel between two mail servers for the duration of delivery, preventing anyone monitoring the network path, an internet service provider, a compromised router, or a Wi-Fi eavesdropper, from reading the message content as it passes through. What TLS emphatically does not do is encrypt the message on either end, so once the email arrives at the recipient's mail server, it sits in the clear on that server's storage, fully readable by the provider.

The third question is what happens when TLS negotiation fails. Because the default mode across all major providers is opportunistic TLS, the sending server attempts encryption but silently falls back to an unencrypted connection if the recipient's server cannot negotiate it.

The email is still delivered, no error message appears, and the sender receives no bounce notification. This silent fallback is the architecture's defining vulnerability, and it is the reason "we use TLS" is never a complete answer to whether email is encrypted by default.

How TLS and STARTTLS Actually Work

Default email encryption is fragile because of what happens mechanically between the moment someone clicks send and the moment the message lands in a recipient's inbox. Each step introduces a point where encryption can succeed, degrade, or fail without notice.

When an email leaves the outbox, the mail client hands it to the organization's outgoing mail server using the Simple Mail Transfer Protocol (SMTP). That server looks up the recipient's domain via DNS to find the MX (Mail Exchange) record, which tells it where to deliver the message. The sending server then opens a connection to the recipient's mail server, and this is where STARTTLS enters the picture.

STARTTLS is not a separate protocol. It is a command issued within SMTP that says, in effect, that the connection began on a plaintext channel but should be upgraded to an encrypted one if the receiving server supports it. The two servers then perform a TLS handshake, a multi-step cryptographic negotiation in which they agree on a cipher suite, exchange digital certificates to verify identity, and establish a shared session key for the rest of the conversation.

If the handshake succeeds, the email body travels through an encrypted tunnel invisible to anyone sniffing the network between those two servers. If the handshake fails, because the recipient's server is misconfigured, does not support TLS, or is running an incompatible version, the sending server reverts to plaintext delivery. This STARTTLS mechanism is conceptually identical for IMAP connections, where it upgrades the channel between a mail client and a server, while POP3 clients use the functionally similar STLS command to switch from plaintext to an encrypted session.

The industry has begun addressing this gap with two complementary standards. MTA-STS (Mail Transfer Agent Strict Transport Security) lets a domain publish a policy declaring that it only accepts email over TLS, instructing sending servers to refuse plaintext delivery.

DANE (DNS-based Authentication of Named Entities) goes further by allowing a domain to specify exactly which TLS certificate sending servers should expect, preventing certificate spoofing. Together they convert email encryption from a hope to a requirement, but both require explicit configuration and neither is on by default.

Opportunistic vs. Enforced TLS and What Happens When Encryption Fails

The difference between opportunistic and enforced TLS is the difference between preferring encryption and demanding it, and the gap has real security consequences. It is also the practical line between an environment where email is encrypted by default in name only and one where encryption is provable on every message.

Opportunistic TLS, the universal default, operates on a deliver-at-all-costs philosophy that prioritizes message delivery over confidentiality. When the sending server finds that the recipient's server cannot negotiate TLS, it delivers the email anyway, in plaintext, and logs the event. A cyberattacker who can interfere with DNS resolution, hijack BGP routes, or sit on the same network segment as either mail server can exploit this fallback to read email content, harvest credentials, or map organizational communication patterns.

Enforced TLS (also called forced or mandatory TLS) inverts those priorities. If the TLS handshake fails for any reason, incompatible versions, certificate mismatch, or an active downgrade cyberattack, the email is not delivered.

The sending server returns a bounce message and the message remains queued until the connection can be secured or the retry window expires. This is the approach used by healthcare organizations transmitting protected health information under HIPAA, by financial institutions exchanging transaction data, and by any organization that has configured connectors or mail flow rules to require TLS for specific partner domains.

In opportunistic mode, which covers virtually all everyday email between unrelated domains, a message to a server that does not support TLS crosses the internet as readable text, as legible as a postcard. The sender never knows, the recipient never knows, and neither IT team receives an alert. Any ISP, network operator, or surveillance apparatus positioned along the route can capture and read it.

For organizations that handle sensitive data, this is not a theoretical concern. Opportunistic TLS offers better-than-nothing protection but provides no guarantee of privacy, because email can fall back to plaintext without either party being explicitly aware. For compliance-focused environments, healthcare under HIPAA, finance under PCI DSS, or any organization subject to GDPR, this gap between preferred encryption and proven encryption is where audit findings originate.

For security leaders the lesson is straightforward: TLS encrypts the pipe rather than the payload, and opportunistic delivery means encryption cannot be proven on any given message without configured enforcement, monitoring, and reporting. For routine communication this may be an acceptable risk, but for sensitive data it is not. What lands in an inbox travels through a channel the organization does not fully control, and every employee who opens an email needs the instincts to recognize when that channel has been weaponized against them.

Opportunistic TLS lets messages fall back to plaintext silently, so a compliance team can believe data was encrypted when it never was. The human judgment that catches what a misconfigured mail server silently passes is exactly what Adaptive Security builds.

Book a demo

TLS vs. End-to-End Encryption: The Critical Gap When Email Is Not Encrypted by Default

When a provider says messages are encrypted, the word conceals a canyon-sized distinction. Most users hear "nobody can read my email," while the provider means "nobody can read your email while it travels between our servers." Those are not the same thing, and the difference sits between TLS and E2EE. Misunderstanding it creates a false sense of security, because email is not encrypted by default against provider-side access, metadata harvesting, or server-side cyberattacks that all sit outside the network path TLS protects.

TLS encrypts the connection between two servers or between a client and a server, so the pipe is secure. The message itself is decrypted and stored in plaintext on every server it touches along the way. E2EE encrypts the message itself so that only the sender and the intended recipient hold the keys to decrypt it, and not even the email provider can read the contents.

Both protocols serve legitimate purposes, yet TLS protects against network eavesdroppers while E2EE protects against everyone in the middle, including the service provider.

TLS Protects the Connection, Not the Message

Transport Layer Security is the default encryption protocol that protects virtually all modern email in transit, which is why email is encrypted by default in the narrow, connection-level sense. When a message is sent through Gmail, Outlook, or any major provider, TLS establishes an encrypted tunnel between the device and the mail server, and then between that server and the recipient's mail server. As the Google Transparency Report documents, the large majority of Gmail traffic in both directions now travels over TLS-encrypted connections, a genuine security achievement, because without TLS any actor on the network path could read email content in plaintext.

The problem is what happens when the message arrives. TLS is hop-to-hop encryption, so at each server along the delivery chain the TLS session terminates, the message is decrypted, and it sits on disk in readable form.

According to the Canadian Centre for Cyber Security's Email Security Best Practices (ITSM.60.002) 2025, the sending and receiving servers can still access the plaintext message even though it was encrypted during transmission, which means TLS does not offer end-to-end confidentiality. When a Gmail user sends to a Yahoo Mail user, both Google and Yahoo can read the full message body on their respective servers.

Server-side encryption at rest does not change this equation, because the provider holds the keys. When law enforcement arrives with a valid legal order, the provider can decrypt and hand over the data, and when an insider cyberattacker or a sophisticated external adversary compromises the server, encryption at rest provides no barrier because the running server already has the keys loaded into memory.

TLS plus encryption at rest is a meaningful defense against physical drive theft and decommissioning mistakes. It does not protect against the cyber threat categories that most concern security-conscious organizations: provider access, legal compulsion, and server compromise.

End-to-end encryption solves these problems by shifting the encryption operation to the client side. With E2EE, the message is encrypted on the sender's device using the recipient's public key before it ever leaves the outbox, travels across every TLS hop and intermediate server in its encrypted state, and can be decrypted only by the recipient's private key, which never leaves their device.

The distinction between server-side and client-side encryption is the deciding factor. In one model the provider holds the keys and the user trusts them. In the other the user holds the keys, and the provider only transports encrypted data it cannot read.

Encryption and authentication protocols were bolted onto email long after its plaintext-era foundations were set. That retrofit architecture explains why TLS became universal while E2EE adoption has languished for three decades.

TLS requires no user action and works automatically. E2EE requires key generation, key exchange, key verification, and compatible software on both ends, a usability burden that the seminal 1999 study Why Johnny Can't Encrypt documented and that decades of subsequent research confirm remains unsolved for most users.

What Metadata, Subject Lines, and Forwarded Emails Reveal

Even when email content is encrypted, metadata tells a detailed story, which is a core reason email is not encrypted by default in the way most users imagine. TLS protects metadata from passive network eavesdroppers during transit but does not hide it from the mail servers, which need sender and recipient addresses, timestamps, IP addresses, and routing information to deliver messages. Every server in the delivery chain logs this metadata and retains it indefinitely.

E2EE improves the picture but does not fully solve it. In both S/MIME and PGP implementations the message body is encrypted while the email headers remain in plaintext.

According to the Canadian Centre for Cyber Security's Email Security Best Practices (ITSM.60.002) 2025, S/MIME improves email security but email headers remain unencrypted, so threat actors could still access certain information about the sender and recipient. The subject line, widely assumed to be protected when an email is encrypted, almost never is, and for many threat profiles metadata is more valuable than content.

Forwarding introduces an additional breakdown. When an email protected by TLS is forwarded by the recipient, the original TLS protection is irrelevant, because the forwarded message creates an entirely new SMTP transmission that may or may not use TLS depending on the recipient's mail server configuration.

Even if that new hop uses TLS, the forwarding provider now holds a fully readable copy of the message. It has transmitted that copy to a third domain the original sender never authorized.

E2EE fares slightly better only if the forwarding user re-encrypts the message for the new recipient using that recipient's public key, a manual step almost no one performs.

A VPN adds another common layer of confusion. A VPN encrypts the connection between a device and the VPN server, protecting traffic from a local ISP or coffee-shop Wi-Fi operator.

Once the email leaves the VPN server and enters the public SMTP relay system, it continues exactly as it would without the VPN. It is protected by opportunistic TLS between mail servers, decrypted at each hop, and readable by every provider along the path.

Using a VPN while believing email is end-to-end encrypted is like locking the front door and leaving every window open.

Who Can Actually Read Emails Under Each Model

The question of who can read email collapses into a simple diagnostic, and it is the clearest way to see why email is not encrypted by default against the parties that matter most. Under TLS alone, the readers include the sending provider, the recipient's provider, any intermediate relay operators, anyone who compromises those servers, anyone who obtains a valid legal order served on those providers, and any network-level adversary who successfully executes a TLS downgrade.

Gmail's AI features, spam filtering, and malware scanning all operate by reading message content on Google's servers. These capabilities are only possible because TLS terminates at the server boundary. The lock icon in a browser means the pipe was encrypted; it does not mean the contents are private from the company that owns the pipe.

Under E2EE with S/MIME or PGP properly implemented, only the sender and the intended recipient can read the message body. The email provider stores an encrypted blob it cannot decrypt. Spam filters and malware scanners must operate on metadata and sender reputation alone, and server-side search becomes impossible.

Password loss also means permanent data loss, because the provider cannot reset a key it never possessed. These trade-offs explain why E2EE email has remained a niche tool for the three decades since PGP was first released.

For most organizations, TLS protects effectively against the most common cyber threat, passive network surveillance. E2EE protects against a narrower but more consequential set of threats: provider-side access, insider risk, and legal compulsion.

Understanding the gap determines whether an email containing a merger term sheet, a patient diagnosis, or a whistleblower report is genuinely private or merely looks like it. That same distinction shapes every decision about which phishing simulations and CAT content will actually change employee behavior before a cyberattack lands.

When email is not encrypted by default end to end, a single forwarded message can expose regulated data to a domain no one authorized. Adaptive Security teaches employees to handle sensitive communications according to the protection each channel actually provides.

Take a self-guided tour

S/MIME and PGP: The Two Standards Behind Default Email Encryption End to End

While TLS encrypts email in transit between mail servers, true end-to-end encryption requires standards that protect message content from the sender's device all the way to the recipient's inbox. Because email is not encrypted by default at that level, two protocols have filled the gap for decades. S/MIME relies on a centralized certificate authority (CA) model in which trusted third parties issue and validate identity certificates, while PGP uses a decentralized web-of-trust model in which users vouch for each other's keys directly.

S/MIME ships built into major email clients including Outlook, Apple Mail, and Gmail for Google Workspace, making enterprise deployment administratively manageable but dependent on CA infrastructure. PGP requires users to generate, exchange, and manually verify public keys, giving individuals full control at the cost of significant operational complexity.

PGP's cryptographic design remains sound after more than three decades, yet its key-management overhead has kept it confined to security professionals, journalists, and privacy advocates instead of reaching mainstream enterprise adoption. The choice between them is rarely about cryptographic strength; it is almost always about tolerance for administrative burden versus appetite for decentralized trust.

How S/MIME Works and Where It Is Used

S/MIME encrypts email by binding a digital certificate to the sender's identity through a certificate authority, a model nearly identical to how TLS certificates secure websites. When someone sends an S/MIME-encrypted message, the client fetches the recipient's public certificate from a CA-issued directory or a previous signed exchange, encrypts the message with that public key, and only the recipient's corresponding private key can decrypt it. The CA vouches for identity, so a valid S/MIME signature tells the recipient both that the message was not tampered with and that the sender is who they claim to be.

Major email platforms have embedded S/MIME support for years. Microsoft Outlook, Apple Mail, and Google Workspace for business all include native S/MIME capabilities, with Google Workspace Enterprise Plus offering hosted S/MIME that manages certificate provisioning and encryption behind the scenes without end-user involvement. For Google Workspace administrators, hosted S/MIME automates the entire certificate lifecycle through the admin console, dramatically lowering the deployment barrier compared to self-managed PKI.

Organizations in regulated industries gravitate toward S/MIME because the centralized trust model maps cleanly to compliance requirements. Certificate authorities must adhere to baseline requirements established by the CA/Browser Forum, and certificates can be revoked instantly when an employee leaves the organization.

The tradeoff is real. A USENIX Security '25 study that analyzed 38 million S/MIME certificates found that a large share lack the policy identifiers signaling compliance with baseline requirements. A significant portion also fail basic linting checks, with missing fields, weak cryptography, or broken trust chains, so most organizations cannot audit which certificates are in circulation or explain why a signature failed until a message goes undeliverable.

A less common but important variant is client-side encryption (CSE) in Gmail, where the encryption keys are generated and held client-side instead of being managed by Google's servers. Under the hosted S/MIME model, Google holds the keys and performs the encryption on the user's behalf; under CSE, the keys never leave the user's device. This distinction matters for organizations subject to data-sovereignty requirements or those that want to eliminate the cloud provider from the trust boundary entirely.

How PGP/OpenPGP Works and Why Usability Remains a Challenge

Phil Zimmermann released Pretty Good Privacy in 1991 as a response to a proposal that would have required communications providers to build government-access surveillance backdoors, and the protocol's political DNA shaped its decentralized architecture. PGP uses a hybrid model: it generates a one-time symmetric session key to encrypt the message body, then encrypts that session key with the recipient's public key, and the recipient uses their private key to recover the session key and decrypt the message. No third party ever touches the keys.

The web-of-trust model replaces centralized CAs with peer validation. Users sign each other's public keys after verifying identity in person or through a trusted channel, building a distributed network of cryptographic attestations that in theory eliminates the single point of failure inherent in any CA hierarchy. In practice, it places extraordinary demands on users who are not cryptographers.

The landmark study that crystallized PGP's usability problem came from Carnegie Mellon University in 1999. Researchers Alma Whitten and J.D. Tygar conducted laboratory user testing of PGP 5.0 and found that most participants failed to send an encrypted and correctly signed email within 90 minutes.

Some accidentally sent plaintext messages they believed were encrypted, and others published their private keys to public key servers.

As Whitten and Tygar concluded in their paper Why Johnny Can't Encrypt, the user interface design generally does not enable someone who is not knowledgeable about security to operate PGP correctly.

More than two decades later, these problems persist. Key generation remains confusing, key distribution has no universal directory equivalent, and key revocation is notoriously difficult, because informing every contact who holds a corresponding public key after a private key is lost or compromised is a manual process with no guaranteed delivery mechanism. Complex key management and the absence of automated revocation workflows continue to create communication gaps and operational risk for organizations that attempt enterprise-scale PGP deployment.

The OpenPGP standard, formalized in RFC 4880 and maintained by the IETF, has modernized the protocol itself, and tools like GnuPG have improved the command-line experience. The fundamental social problem has no technical fix, because the web of trust requires human diligence at every link in the chain.

Encryption vs. Digital Signing: Confidentiality and Authentication Are Not the Same

Both S/MIME and PGP serve two distinct cryptographic functions, and conflating them creates dangerous gaps in an organization's email security posture. Encryption provides confidentiality by scrambling the message body so that only the intended recipient can read it, while digital signing provides authentication and integrity by proving the message came from the claimed sender and that its contents were not altered since signing. They are independent operations that can be used separately or together.

A digitally signed but unencrypted message tells the recipient who sent it and confirms nothing was changed in transit, yet anyone who intercepts it can read the plaintext. An encrypted but unsigned message keeps the content private but gives the recipient no cryptographic assurance of who sent it. A cyberattacker who compromises a sender's account could send encrypted mail from that account, and the recipient would have no way to detect the impersonation without a signature check.

The most secure workflows use both, signing first and then encrypting the signed message. Signing first binds identity to content before the content is locked, and encrypting afterward ensures that even the signature metadata stays protected. Client implementations typically handle this sequencing automatically when both parties have certificates or keys configured.

For cybersecurity awareness training programs, this distinction matters because employees need to understand what a signed-email badge actually means and what it does not. A valid S/MIME signature in Outlook or a PGP signature check confirms authenticity and integrity; it does not confirm that the signer's account was uncompromised at the moment of sending, nor does it guarantee that the content is truthful. Building this nuance into cybersecurity awareness training helps employees treat email signatures as one signal among many, never as a binary trust indicator, which is exactly the mindset that resists the multi-channel deception techniques modern cyberattackers deploy.

A valid email signature confirms a message was not altered, yet employees routinely read it as proof the request itself is safe to act on. Before anyone approves a sensitive action on the strength of a signature, Adaptive Security has trained them to weigh it against other signals.

Explore the platform

How Major Email Providers Handle Default Email Encryption

Every major email provider now enables TLS by default, but the depth of protection varies dramatically depending on which service is used and what tier is paid for. As established earlier, connection-level encryption does not stop a provider from reading stored messages or shield against a downgraded connection. What each provider delivers under the encrypted label determines whether email is encrypted by default against casual eavesdropping, determined cyberattackers, or the provider itself.

Gmail: TLS Defaults, Lock Icons, and Confidential Mode

Gmail encrypts all messages with TLS automatically, regardless of whether the account is a free consumer account or a paid Google Workspace subscription. When both the sender's and recipient's mail servers support TLS, the connection is encrypted in transit and Gmail displays a gray lock icon, which Google calls standard encryption. This is the baseline for nearly all Gmail-to-Gmail communication and for messages exchanged with other major providers like Outlook.com and Yahoo Mail.

The lock-icon system in Gmail provides a visual audit of what encryption was negotiated for a given message. A gray lock means TLS was used, so the message was encrypted between servers but Google holds the decryption keys and can access the content. A green lock indicates S/MIME encryption is active and the sender was verified through a digital certificate, with Google securely managing a copy of the key under its hosted S/MIME model available to Google Workspace Enterprise Plus customers.

A blue shield appears when client-side encryption (CSE) is enabled, so the organization holds the only copy of the key and Google cannot decrypt the message.

A red open lock means the recipient's server did not support TLS at all and the message traveled across the internet in plaintext.

Google Workspace administrators can enforce TLS compliance policies that require specific domains to use TLS or reject messages from non-compliant senders. For organizations handling regulated data, S/MIME adds message-level encryption that TLS cannot provide, because the message is encrypted before it leaves the sender's client, so even a compromised mail server yields unreadable contents.

Gmail's Confidential Mode is often mistaken for encryption, but it is not. Confidential Mode lets senders set expiration dates, require SMS passcodes for access, and disable forwarding, copying, printing, and downloading of messages and attachments. These controls create friction against casual forwarding but contain no cryptographic protection, so Google retains full access to the message content, recipients can still take screenshots or photos of the screen, and anyone with malicious software on their device may capture message contents.

According to Google's own support documentation, Confidential Mode does not prevent recipients from taking screenshots or photos of messages or attachments; it is a recipient-control feature, and encryption is not part of it.

Google ended the practice of scanning consumer Gmail for ad personalization in 2017, but the company's broader data-collection infrastructure continues to process email content for spam filtering, malware detection, and Smart Features like Smart Compose. For organizations that require zero provider access, Google Workspace's client-side encryption is the only Gmail option that puts the organization in control of the encryption keys instead of Google.

Outlook and Microsoft 365: S/MIME and Message Encryption

Microsoft 365 and Outlook.com enable TLS by default for all outbound email, matching the industry baseline, so email is encrypted by default in transit here as well. Where Microsoft diverges is in the breadth of encryption options available to paying subscribers. Outlook supports S/MIME natively on both desktop and web clients, and users can configure S/MIME certificates to encrypt individual messages or set Outlook to encrypt all outgoing messages automatically.

For organizations that need to send encrypted messages to external recipients who may not have S/MIME configured, Microsoft provides Microsoft Purview Message Encryption, the successor to legacy Office 365 Message Encryption, which was deprecated in July 2023. Purview Message Encryption allows senders to encrypt any message with a single click. Recipients authenticate through a one-time passcode or their existing Microsoft, Google, or Yahoo credentials to read the message in a secure web portal, with no special software or certificate required.

Microsoft Purview Message Encryption also includes Advanced Message Encryption for organizations with E5 licenses, adding message revocation, expiration, and integration with Data Loss Prevention (DLP) policies. Administrators can create transport rules that automatically encrypt messages matching specific patterns, such as any message containing credit-card numbers or sent to a particular external domain.

The critical distinction between Microsoft's approach and Gmail's is that Purview Message Encryption encrypts the message at the content level using Azure Rights Management rather than at the transport level alone. Even after delivery, the encrypted message remains protected on the recipient's mail server.

For organizations in regulated industries, this satisfies data-residency and protection requirements that TLS alone cannot meet. Like Google's hosted S/MIME, however, Microsoft retains the ability to decrypt Purview-encrypted messages when served with a lawful request, because the keys are managed within Microsoft's infrastructure, so the customer does not hold them exclusively.

Yahoo, Mobile, and Free Providers: What Is Available

Yahoo Mail, like Gmail and Outlook, enables TLS by default for all messages sent through its infrastructure, so a Yahoo-to-Yahoo or Yahoo-to-Gmail exchange negotiates TLS when both servers support it. Where Yahoo falls short is in anything beyond TLS, because Yahoo Mail does not include built-in end-to-end encryption, native S/MIME support, or any equivalent to Gmail Confidential Mode or Purview Message Encryption.

For users who need message-level encryption on Yahoo, the practical path is a browser extension such as Mailvelope, which layers OpenPGP encryption on top of Yahoo's webmail interface. Mailvelope works across Chrome, Firefox, and Edge and supports Gmail, Outlook.com, Yahoo, and most other webmail providers.

The user generates a PGP key pair, exchanges public keys with recipients, and encrypts message content in the browser before it touches Yahoo's servers. The trade-off is usability, because both sender and recipient must have compatible PGP software and exchange keys in advance.

Free email providers broadly follow the same pattern of TLS by default and no end-to-end encryption. AOL Mail, GMX, and similar free services encrypt messages in transit but store them unencrypted on their servers, with no built-in mechanism for message-level encryption. Any user who needs true end-to-end protection must adopt the same third-party PGP workflow via Mailvelope or a desktop client like Thunderbird with the OpenPGP add-on.

On mobile devices, encryption setup follows the operating system. iOS supports S/MIME natively through the Settings app, where users install a certificate profile, enable S/MIME for their mail account, and can send signed and encrypted messages from the native Mail app, a process that is straightforward to deploy across an enterprise using MDM profiles. Android does not include native S/MIME support in the Gmail app, but the OpenKeychain app combined with K-9 Mail provides a comparable OpenPGP workflow, and both approaches require certificate or key management.

The pattern across all providers is consistent: encryption in transit is now universal, encryption at rest is provider-controlled by default, and true end-to-end encryption remains a premium, opt-in feature that most users never configure. Gaps persist when messages travel to smaller domains or legacy mail infrastructure, so understanding exactly what each provider's lock icon means, and what it does not protect, is the difference between informed risk acceptance and a false sense of security.

Every provider's lock icon signals a different level of protection, and employees rarely know which one leaves a message readable on a third-party server. Adaptive Security turns those visual cues into decisions employees can actually make under pressure.

Book a demo

What Email Encryption Does Not Protect Against, Even by Default

Email encryption, even end-to-end encryption, provides confidentiality rather than content verification. An encrypted phishing email arriving over a perfectly secured TLS connection is still a phishing email.

Encryption scrambles the message so only the intended recipient can read it, but it cannot judge whether the sender is genuine or whether the content is malicious. Organizations that treat default email encryption as a phishing defense are protecting the pipe while ignoring the payload, and encryption alone has never stopped a credential-harvesting link or a business email compromise (BEC) attempt.

Encryption Does Not Stop Phishing or Social Engineering

The fundamental misunderstanding about email encryption is that it secures the channel rather than the judgment of the person reading the message. A phishing email delivered over TLS 1.3 looks identical in the recipient's inbox to one delivered unencrypted, and the lock icon confirms the message was not tampered with in transit rather than confirming it is trustworthy. Cyberattackers exploit this confusion deliberately.

Spear-phishing campaigns increasingly originate from compromised but legitimate accounts on encrypted mail servers, so the email passes both SPF and DKIM checks and arrives behind a valid TLS handshake, right up until the recipient clicks a link to a credential-harvesting page.

According to Verizon's 2026 Data Breach Investigations Report, stolen credentials accounted for 13% of breaches as an access vector, and those credentials are the payoff that encrypted phishing pages are built to capture.

Social engineering cyberattacks operate entirely above the transport layer that encryption protects. Vishing calls, smishing texts, and deepfake video requests arrive through channels that email encryption never touches. An organization with mandatory S/MIME encryption on every internal message is no less vulnerable to a finance employee receiving a phone call from an AI-cloned CFO voice demanding an urgent wire transfer.

Encryption provides one narrow guarantee, that the ciphertext was not read in transit, and zero guarantees about the intent, identity, or safety of the communicator, so security teams that conflate encryption coverage with phishing protection create a blind spot cyberattackers are actively exploiting.

Searchability, Backups, and Deliverability Challenges

Encrypted emails cannot be searched within most inbox environments after receipt, because the message body remains ciphertext indexed only as an opaque blob. For employees who rely on inbox search to find past conversations, invoices, or contract terms, this creates daily friction that often leads to workarounds such as forwarding decrypted copies to personal accounts or pasting sensitive content into unencrypted notes. Usability degradation is not theoretical; it is the reason many organizations that pilot mandatory E2EE quietly roll it back within months.

Cloud backup services introduce a separate exposure. Backup platforms encrypt data at rest using AES-256, but the decryption architecture depends entirely on who controls the keys.

If a backup service ingests email from a Microsoft 365 or Google Workspace tenant where encryption is applied at the server level rather than on the client, the backup copy can be stored in decrypted form. This happens because the cloud provider already holds the keys necessary to present plaintext to the backup API.

Organizations that enable third-party backup without auditing the encryption boundary between the mail server and the backup target can discover during an incident that their encrypted email archive exists as searchable plaintext in a secondary location.

Deliverability is another underappreciated variable. S/MIME-signed messages generally transit without issue because the signature is an attachment and leaves the message body unmodified, but enforced TLS policies combined with misconfigured DKIM or DMARC records can trigger rejection at the receiving gateway.

Google and Yahoo began requiring SPF, DKIM, and DMARC alignment for bulk senders in February 2024. If an organization enforces mandatory TLS on outbound mail while its DMARC policy is set to p=reject and its DKIM signing is broken, legitimate encrypted messages can be silently dropped.

POP3 and IMAP also behave differently under encryption. POP3 connections protected by STLS download messages and typically delete them from the server, so the local device becomes the sole repository of that encrypted content. If the device is lost or the local mail store is corrupted, the encrypted messages are gone.

IMAP syncs across devices and retains mail on the server, which preserves availability but also means the encrypted corpus remains accessible to anyone who compromises the account credentials. The protocol choice determines which risk an organization accepts by default.

Legal Access: Subpoenas, Discovery, and Who Holds the Keys

Encrypted emails are not immune to legal process. If a cloud provider holds the decryption keys, which is the default architecture for TLS-based email services like Gmail and Microsoft 365, that provider can be compelled by subpoena to produce both the ciphertext and the keys necessary to decrypt it. When the provider controls the keys, the encryption is effectively transparent to a court order, so default email encryption offers no shield against lawful compulsion.

The distinction between TLS-model encryption and true client-side E2EE becomes legally decisive here. With client-side encryption, where the organization rather than the provider holds the private keys, a subpoena served on the email provider yields only ciphertext that is cryptographically useless without the recipient's cooperation. This architecture introduces a different legal dynamic, because the court must then compel the key holder directly, which in most jurisdictions triggers Fifth Amendment considerations, attorney-client privilege review, or at minimum a separate legal fight that buys time.

Organizations operating in regulated industries or handling sensitive intellectual property should understand that their choice of encryption architecture is also a choice about who can be compelled to unlock their email, and how easily that compulsion succeeds. Recognizing what encryption cannot solve is the foundation for building defenses around the human decisions that sit beyond any cryptographic control.

An encrypted inbox still delivers a flawless deepfake wire-transfer request that passes every authentication check. The behavioral red flags no cryptographic protocol can surface are the ones Adaptive Security prepares employees to catch.

Take a self-guided tour

Compliance Regulations That Mandate Email Encryption

No single US federal law explicitly requires every business to encrypt all email communications. Instead, sector-specific regulations create a patchwork of requirements that collectively make email encryption a practical necessity for any organization handling regulated data. Under HIPAA, encryption is technically an addressable specification, so covered entities that choose not to implement it must document an equivalent alternative, and proposed 2025 updates to the Security Rule would eliminate the addressable distinction entirely.

Regulators across healthcare, finance, defense, and education increasingly treat encryption as the baseline for data protection, no longer an optional control, which means relying on default email encryption in transit rarely satisfies them on its own.

Healthcare, Finance, and Education: HIPAA, FTC Safeguards, and FERPA

HIPAA treats email encryption as an addressable implementation specification under the Security Rule for protecting electronic protected health information (ePHI) in transit. A covered entity can technically decline to encrypt, but only by documenting an equivalent safeguard and justifying why encryption is not reasonable and appropriate. With the Department of Health and Human Services proposing to eliminate the addressable-versus-required distinction in its January 2025 Notice of Proposed Rulemaking, encryption is rapidly becoming a de facto mandate, so organizations handling patient data without transport-layer encryption are betting against both the regulatory trajectory and the enforcement pattern.

The FTC Safeguards Rule, codified at 16 CFR § 314.4(c)(3), takes a harder line by requiring financial institutions under FTC jurisdiction to protect by encryption all customer information held or transmitted both in transit over external networks and at rest. There is no addressable loophole, and encryption in transit is a flat requirement, with the sole exception being when the institution's Qualified Individual determines encryption is infeasible and approves effective alternative compensating controls in writing. This covers a surprisingly broad set of entities, including mortgage brokers, tax preparers, auto dealers that lease, check cashers, and investment advisors not registered with the SEC.

The updated rule clarifies that encryption must cover data both in transit and at rest, closing ambiguity that previously allowed some institutions to claim partial compliance.

In education, FERPA does not explicitly mandate encryption in its statutory text, but the Department of Education has long interpreted its general security requirements to include encryption as a reasonable safeguard, and state laws have stepped into the gap. New York Education Law § 2-D requires contractors and educational agencies to use encryption technologies to protect student personally identifiable information (PII) both in transit and at rest.

It specifies that safeguards including encryption, firewalls, and password protection must be in place when student data is stored or transferred. As education technology adoption accelerates, encryption requirements are materializing at the state level faster than federal guidance can keep pace.

Defense and Law Enforcement: CMMC 2.0, ITAR, and CJIS

The defense industrial base faces some of the most specific encryption mandates in US regulation. CMMC 2.0 Level 2 requires contractors handling Controlled Unclassified Information (CUI) to implement all 110 security controls from NIST SP 800-171 Revision 2, including encryption of CUI during transmission. The requirement is not negotiable, third-party assessment organizations validate compliance, and failure means loss of contract eligibility, so for the thousands of companies in the Defense Department supply chain, sending unencrypted CUI over email amounts to a contractual breach.

ITAR governs the export of defense-related technical data and adds a unique twist through the encryption carve-out codified at 22 CFR § 120.54. Under this provision, transmitting unclassified ITAR-controlled technical data outside the US is not considered an export, provided the data is encrypted end to end using a FIPS 140-2 validated cryptographic module.

The encryption must be applied before data leaves the originator's security boundary and must remain undisturbed until it arrives within the intended recipient's boundary. This creates a binary choice for defense contractors: implement FIPS 140-2 compliant email encryption, or treat every email containing technical data as a controlled export subject to licensing requirements.

The CJIS Security Policy governs how criminal justice agencies handle criminal justice information (CJI). It mandates that when CJI is transmitted outside the boundary of a physically secure location, the data must be immediately protected through encryption.

It requires FIPS 140-2 validated encryption, aligning with the same federal cryptographic standards that anchor ITAR and CMMC requirements. For any law enforcement agency, court system, or contractor that touches CJI, sending unencrypted email is a direct policy violation with no gray area.

GDPR and the Global Regulatory Landscape

GDPR Article 32 lists encryption as an appropriate technical and organizational measure for ensuring a level of security appropriate to the risk, but stops short of explicitly mandating it for email. That phrasing gives supervisory authorities wide latitude, so organizations that suffer a breach involving unencrypted personal data face a significantly heavier enforcement burden because they must explain why encryption was not implemented given the nature of the data processed. Under GDPR, failure to implement encryption when data sensitivity warrants it can be treated as an aggravating factor in penalty calculations, which can reach €20 million or 4% of annual global turnover.

This pattern repeats across jurisdictions. Regulators may not write an explicit email-encryption mandate into statute, yet they build enforcement frameworks where the absence of encryption becomes indefensible after a breach. When a breach occurs and data was unencrypted in transit, supervisory authorities increasingly view that as a failure of reasonable care, regardless of whether the statute used the word encryption explicitly.

Organizations that train employees to recognize phishing attempts and handle sensitive data appropriately close the gap between a technical control and its real-world effectiveness, because even the strongest encryption can be bypassed when an employee is tricked into sending sensitive information through an unencrypted channel. Cybersecurity awareness training mapped to these regulatory frameworks ensures that encryption policies are not just configured on servers but understood and followed by the people who handle regulated data every day.

A breach involving unencrypted personal data forces an organization to justify the gap to regulators who increasingly read it as negligence. Adaptive Security aligns compliance training to the frameworks that govern how employees handle regulated data.

Take the guided tour

Automating Email Encryption for Organizations

Moving from manual encryption to automated protection means three things: deploying a gateway appliance at the email boundary, configuring DLP policies that detect sensitive patterns and trigger encryption automatically, and standardizing on an encryption method that minimizes recipient friction. Automating email encryption eliminates the gap between policy and practice, which is where most data leaks occur. It also forces a deliberate weighing of portal-based convenience against the deliverability and usability trade-offs that can undermine adoption, so default email encryption becomes a consistent outcome instead of a per-message gamble.

1. Gateway Appliances and Policy-Based Encryption

A gateway encryption appliance sits at the organization's email boundary, positioned between the internal mail server and the public internet, and inspects every outbound message before it leaves the perimeter. End-user-driven encryption requires employees to remember to click encrypt or apply a sensitivity label. A gateway instead enforces encryption policy automatically, evaluating each message against a ruleset and applying the appropriate method without any sender decision-making.

Policy conditions can include the recipient's domain, the presence of a sensitivity label or classification tag, the sender's department or role, or the detection of regulated data in the message body or attachments. A gateway can route all outbound email to a law firm through enforced TLS while applying S/MIME to financial reports and diverting anything containing patient data into a secure portal. This granularity matters because a single encryption method rarely suits every recipient, and forcing the wrong method creates the friction that drives employees toward workarounds.

2. DLP Keyword Detection and Automated Triggers

Data loss prevention (DLP) engines embedded in modern encryption gateways scan outbound email content and attachments for sensitive patterns before the message reaches the wire. When the engine detects a Social Security number pattern, a credit-card number matching a Luhn algorithm check, or a custom keyword such as attorney-client privileged, it can trigger encryption automatically, regardless of what the sender intended.

DLP policies can also inspect attachments, including a spreadsheet containing customer PII, a PDF with protected health information, or a document tagged with an internal classification label. Once a violation is detected, the gateway can apply encryption, quarantine the message for manual review, or block it outright and alert the security team.

The highest-maturity organizations configure DLP to encrypt by default for any message that trips a sensitive-data rule, then train employees to expect the automated enforcement, so encryption stops being optional. According to Verizon's 2026 Data Breach Investigations Report, 62% of confirmed incidents involve a human element, which means DLP that waits for a manual encryption click from the same people it is meant to protect against closes very little.

3. The Recipient Experience: PGP, S/MIME, and Portal-Based Encryption Compared

The encryption method an organization automates determines whether external recipients comply with the secure workflow or abandon it. Each approach presents a different recipient experience, and the hidden cost of getting it wrong is measurable in resends, workarounds, and lost mail.

PGP-encrypted email requires the recipient to possess a private key and enter a passphrase to decrypt the message. If the recipient has never used PGP, they must first install compatible software, generate a key pair, and exchange public keys with the sender, a sequence that makes PGP impractical for most external communication. Even among technically literate users, key-management errors and setup complexity have suppressed adoption for decades.

S/MIME-encrypted email is transparent when both sender and recipient have S/MIME certificates configured, because the client handles encryption and decryption silently and the message appears as a normal email. The catch is that if the recipient lacks a certificate or their client does not support it, the experience degrades unpredictably, anywhere from an unreadable attachment to an outright bounce. S/MIME works best within closed ecosystems where certificate distribution can be centrally managed.

Portal-based encrypted email presents the most friction. The recipient receives a notification with a link, clicks through to a web portal, and must either create an account or enter a one-time passcode to view the message in a browser.

Recipients cannot search portal-encrypted messages from their own inbox, and messages viewed in a portal are not stored in the recipient's email archive. That exact problem cost the Iowa Department of Human Services 432,000 emails after it switched encryption vendors in 2018, an inaccessibility that became public in 2022. That level of friction reliably produces the same outcome, where recipients call the sender and ask them to resend the message unencrypted.

Deliverability adds another layer of consideration. TLS and S/MIME-encrypted messages generally pass through spam filters without issue, because they follow standard SMTP behavior.

Portal-based encrypted messages often arrive instead as notification emails with unfamiliar links, a structure that spam and phishing filters are trained to flag. The most accessible encryption method for heterogeneous recipients is also the one most likely to be blocked or ignored.

Organizations that get the automation architecture right remove the decision from individual senders entirely, so the encryption happens or the message does not leave the building, and that is the standard enforcement must meet before any discussion of which protocol to use even becomes relevant.

Manual encryption fails at the exact moment an employee is rushed, distracted, or unsure which button to click. Automated controls only protect regulated data when human habits hold, and reinforcing those habits is what Adaptive Security does.

Explore the platform

The Future of Email Encryption: Post-Quantum, DANE, and AI

The future of email encryption is being reshaped by three converging forces: the cyber threat of quantum computers that can break today's cryptographic foundations, a push to close downgrade vulnerabilities in server-to-server delivery, and AI-driven threat detection that works without breaking encryption. Each addresses a structural weakness in how email is encrypted by default, and each is moving from research to deployment faster than most security leaders realize.

Post-Quantum Cryptography and the Threat to Current Standards

The encryption that protects email today is built on mathematical problems that quantum computers will solve with ease. RSA and elliptic curve cryptography (ECC), which underpin TLS and S/MIME, rely on factoring and discrete logarithms.

A sufficiently powerful quantum computer running Shor's algorithm would reduce these problems to trivial computation. When that machine arrives, encrypted emails intercepted and stored today become readable retroactively, a harvest-now-decrypt-later cyber threat that is not theoretical.

The National Institute of Standards and Technology (NIST) finalized its first three post-quantum cryptography standards in August 2024, capping an eight-year global effort. ML-KEM handles general encryption, while ML-DSA and SLH-DSA handle digital signatures, and all three are built on lattice-based and hash-based math that resists both classical and quantum cyberattack. NIST is urging system administrators to begin transitioning immediately because full integration into protocols like TLS and S/MIME will take years.

As NIST mathematician Dustin Moody, who heads the post-quantum cryptography standardization project, put it, the agency needs to be prepared in case a cyberattack defeats the algorithms in these three standards, but for most applications the new standards are the main event.

DANE, STARTTLS Everywhere, and Closing the Downgrade Gap

Opportunistic TLS, the mechanism that encrypts most server-to-server email today, has a fatal flaw. A cyberattacker positioned between two mail servers can strip the STARTTLS negotiation and force the connection to fall back to plaintext. The downgrade happens silently: the sender's server still delivers the message, and neither party knows it was intercepted.

DNS-based Authentication of Named Entities (DANE), defined in RFC 7672, eliminates this vulnerability. A domain publishes a TLSA record in its DNSSEC-signed DNS zone that specifies exactly which TLS certificate the receiving mail server must present, and a sending server that supports DANE checks this record before transmitting. If the certificate does not match, the connection is refused outright, so no downgrade is possible because there is no plaintext fallback.

Microsoft announced general availability of Inbound SMTP DANE with DNSSEC for Exchange Online in October 2024, with outbound SMTP DANE having been available since 2022. The EFF's STARTTLS Everywhere initiative, launched in 2018, pioneered the model of publishing encryption policy for email domains.

The project wound down in 2020, but its architecture directly influenced MTA-STS (RFC 8461), which publishes TLS policies over HTTPS rather than DNS. MTA-STS and DANE together form a layered defense, because MTA-STS provides a deployable first layer requiring no DNSSEC infrastructure while DANE delivers cryptographically stronger guarantees for domains ready to implement DNSSEC.

Both standards reject the encrypt-if-possible-deliver-anyway model that has defined email transport for decades.

AI-Driven Threat Detection in Encrypted Email Traffic

The encryption that protects email in transit creates a detection blind spot, because traditional security tools cannot inspect encrypted content for phishing links, malicious attachments, or business email compromise indicators. AI-driven anomaly detection changes that equation by analyzing encrypted email metadata, communication patterns, timing, header anomalies, and sender-recipient relationships without ever decrypting the message body.

Machine-learning models establish behavioral baselines for every sender and recipient in an organization. When an encrypted message arrives from what appears to be the CFO's domain but originates from an unusual IP range, at an atypical time, or with header discrepancies inconsistent with prior traffic, the model flags it. These signals are invisible to content filters but unmistakable to behavioral analysis, and a 2025 bibliometric review published in Frontiers in Artificial Intelligence confirmed that AI techniques, particularly deep learning and natural language processing, are increasingly applied to phishing detection at the metadata and traffic-pattern level, achieving high accuracy without requiring content access.

This capability matters because cyberattackers are encrypting their own phishing infrastructure with valid TLS certificates, so encryption alone does not equal safety and only conceals the cyber threat. AI-driven anomaly detection restores visibility by separating legitimate encrypted traffic from malicious encrypted traffic based on how it behaves, without needing to read what it contains. The standards that govern how email moves between servers are being rewritten to close gaps that cyberattackers have exploited for years.

Cyberattackers now wrap their phishing infrastructure in valid TLS certificates, so encryption ends up concealing the cyber threat. Behavioral awareness that turns encrypted mail from a blind spot into a detectable signal is what Adaptive Security adds.

Book a demo

Beyond Encryption: The Human Layer When Email Is Not Encrypted by Default

Email encryption protects data confidentiality in transit, but it was never designed to protect human judgment. Even a perfectly encrypted email thread cannot prevent an employee from clicking a malicious link, responding to a hyper-personalized spear-phishing message, or being deceived by a deepfake voice call that references an encrypted conversation. Social engineering targets the one blind spot no cryptographic protocol can close, human decision-making under pressure, which is why email is not encrypted by default against the attacks that most often lead to a breach.

Encryption answers whether data can be intercepted in transit; it leaves entirely unanswered whether the person receiving that data will be tricked into acting on it.

Why Encryption Cannot Protect Against Human Error

Encryption is a mathematical guarantee of confidentiality rather than a behavioral safeguard. It ensures that an email's contents remain unreadable to anyone without the correct decryption key, yet it cannot tell whether the request is legitimate, whether the sender is genuine, or whether the attachment is safe to open. Those judgments happen entirely in the mind of the recipient.

The gap between encryption's technical promise and real-world security widens through human error in operating the controls themselves. Misconfigured email authentication settings, expired certificates, and ignored browser warnings are common failure points that render encryption moot, and these are ordinary gaps in how people configure and manage systems rather than sophisticated cryptographic cyberattacks. Employees also routinely bypass encryption under pressure by forwarding sensitive documents through personal email, using unencrypted messaging apps, or disabling security features to meet a deadline, and none of these behaviors are malicious even as every one opens a door that encryption was supposed to keep closed.

Key management introduces additional human vulnerability. Private keys stored in unprotected locations, shared among team members, or left on devices without password protection become access points that cyberattackers can exploit without ever touching the encrypted message. The technical control is only as strong as the human practice surrounding it.

How Social Engineering Circumvents Technical Email Controls

Social engineering does not attack encryption; it sidesteps it entirely by targeting the person at the endpoint, the one place where all technical defenses converge on a single decision made under cognitive and emotional pressure. An encrypted email from a compromised vendor account still looks authentic, and an encrypted thread referencing a real project still carries the weight of legitimacy, so cyberattackers exploit this trust architecture deliberately.

Modern social engineering operates across multiple channels simultaneously, a tactic that overwhelms the single-channel protection model encryption represents. A finance employee receives an encrypted email from what appears to be the CFO requesting an urgent wire transfer, and minutes later a phone call follows in which the CFO's AI-cloned voice confirms the request and references details from the encrypted thread. In 2024, a finance employee at multinational engineering firm Arup approved a $25.6 million transfer after joining a video call where every participant, including the CFO, was a deepfake, with Hong Kong police confirming the cyberattackers used AI-generated video and audio to impersonate multiple executives.

According to Sumsub's 2025–2026 Identity Fraud Report, deepfake attacks increased 2,100% globally, and sophisticated fraud combining deepfakes, synthetics, and telemetry tampering surged 180% year over year. The Arup case is an early example of that rapidly scaling pattern rather than an outlier.

The same dynamic applies to spear phishing, business email compromise, and vendor impersonation, because these cyberattacks arrive as legitimate encrypted messages from previously trusted correspondents. No email security gateway blocks them, since they meet every technical authentication check, and the only defense that catches them is a trained employee who recognizes the behavioral red flags: unusual urgency, out-of-pattern requests, or subtle inconsistencies in communication style that an AI-generated message cannot perfectly replicate.

According to the CrowdStrike 2026 Global Threat Report, the average adversary breakout time, the window between initial access and lateral movement, dropped to 29 minutes, with the fastest measured at just 27 seconds, which leaves almost no margin for a delayed human response once a cyberattacker is inside.

Building a Complete Email Security Strategy with Both Encryption and Awareness

Encryption and cybersecurity awareness training address fundamentally different layers of risk, so an organization that invests in only one leaves the other exposed. Encryption protects data confidentiality during transmission and storage, while cybersecurity awareness training protects the decision-making capacity of every employee who interacts with that data once it arrives. Neither layer alone is sufficient in an environment where cyberattackers freely combine technical exploitation with psychological manipulation.

Organizations that pair strong email encryption with continuous, adaptive cybersecurity awareness training close the gap that either approach leaves open. Employees learn to recognize the social engineering patterns that encryption cannot filter: the pressure to bypass standard procedures, the request that arrives through one channel and is reinforced through another, and the slight dissonance in tone that signals an impersonation. According to IBM's Cost of a Data Breach Report 2025, employee security training ranked among the top factors reducing average breach costs, saving organizations roughly $190,000 per incident, which quantifies the return on treating the human layer as a control rather than an afterthought.

The two controls reinforce each other, because a trained employee compensates for the moments encryption cannot cover and encryption limits the damage when judgment fails. Whether or not email is encrypted by default in any given configuration, the question that determines breach outcomes is not simply whether the message was encrypted but whether the recipient knew what to do with it. Answering that question requires investment in both the cryptographic layer and the human one, treating employee judgment as a detection layer the organization can strengthen through training, one capable of catching what no protocol ever will.

Encryption secures the data in a wire-transfer email while doing nothing to stop the employee from approving a fraudulent one. Adaptive Security builds the human layer that catches multi-channel deception no cryptographic control can filter.

Take a self-guided tour

How Adaptive Security Closes the Gap When Email Is Encrypted by Default

Encryption keeps a message unreadable in transit, yet the most damaging cyberattacks arrive as flawlessly encrypted mail that passes every authentication check, which is exactly the gap Adaptive Security is built to close. Its Cloud Email Security layers AI-powered detection on top of Google and Microsoft through an API with no MX record changes, catching the AI-generated phishing and business email compromise that native filters miss and remediating similar messages across every inbox it reached. Because email is encrypted by default only at the connection level, this detection layer restores visibility into the malicious intent that ciphertext conceals.

Every detected cyberattack feeds directly into personalized cybersecurity awareness training and dynamic risk scoring, so the cyber threat that reaches an employee becomes the lesson that changes their behavior. The same platform extends into AI Governance, surfacing shadow AI use and the sensitive-data exposure that occurs when employees paste confidential content into unmonitored tools, and into Compliance training that maps audit-ready modules to frameworks like HIPAA, GDPR, and the FTC Safeguards Rule. Rather than bolting these functions onto separate vendors, one platform ties email detection, human risk, and regulatory readiness together.

The result is defense in depth that treats encryption as the floor rather than the ceiling. Where transport-layer encryption protects the pipe and end-to-end encryption protects the payload, Adaptive Security protects the person, closing the human-decision gap that no cryptographic protocol was ever designed to address.

Encrypted phishing and deepfake fraud slip past technical controls because they exploit the employee rather than the protocol. Adaptive Security unifies email detection, human risk scoring, and compliance training so the gap closes on every front.

Book a demo

Frequently Asked Questions About Whether Email Is Encrypted by Default

Is Email Encrypted by Default on All Email Providers?

No. Most major email providers encrypt email in transit using TLS by default, but this protection is opportunistic and not guaranteed across every provider. When a recipient's server does not support TLS, the message may be delivered in plaintext. The vast majority of Gmail traffic now uses TLS in transit, yet smaller providers, legacy systems, and misconfigured servers may still lack TLS support. Even when TLS is active, it encrypts only the connection between mail servers while leaving the message itself readable, so the email provider can still read the message on its own servers. Organizations handling regulated data should verify counterparty TLS support and evaluate whether end-to-end encryption is necessary for sensitive communications.

Can Encrypted Emails Still Be Intercepted or Read by Cyberattackers?

Yes. TLS-encrypted emails can be intercepted through several vectors. A man-in-the-middle cyberattack can decrypt traffic if TLS certificates are compromised or if a cyberattacker positions themselves between mail servers during transmission. Downgrade cyberattacks, specifically STARTTLS stripping, force the connection to fall back to plaintext by removing the TLS upgrade request, allowing a cyberattacker to read the message in transit. Additionally, TLS only protects the message while it moves between servers; once delivered, the email sits decrypted on the recipient's mail server, where it becomes vulnerable to account compromise, insider threats, or server breaches. Even end-to-end encrypted emails can be compromised if a cyberattacker gains access to the recipient's device or private key through malware or credential theft.

What Percentage of Emails Are Encrypted with TLS When Email Is Encrypted by Default?

According to the Google Transparency Report, Safer Email section, roughly 88% of emails sent to and from Gmail are encrypted in transit using TLS. Adoption has risen since the report launched in 2014, when about 73% of outbound and 61% of inbound Gmail messages were encrypted. However, this statistic applies specifically to Gmail traffic and not the entire global ecosystem. Independent measurement of the broader mail ecosystem has repeatedly found that a substantial share of smaller domains and legacy systems still send and receive email without transport-layer encryption. The gap means that while major providers have largely adopted TLS, messages traveling to less-maintained infrastructure remain exposed during transmission, so email is not encrypted by default in every path a message may take.

Is Gmail Confidential Mode the Same as True End-to-End Encryption?

No. Gmail Confidential Mode is not end-to-end encryption. It provides information-rights-management controls, including message expiration dates, SMS passcodes, and restrictions on forwarding, copying, downloading, and printing, but Google retains full access to message content on its servers. According to Al Qahtani, Javed, and Shehab's User Perceptions of Gmail's Confidential Mode, published in the Proceedings on Privacy Enhancing Technologies 2022, confidential-mode emails are not end-to-end encrypted and do not prevent recipients from taking screenshots or photos, and Google does not market Confidential Mode as encryption. True end-to-end encryption ensures that only the sender and intended recipient can decrypt the message, with no third party, including the email provider, able to read it. Organizations requiring genuine message confidentiality should implement S/MIME, PGP, or client-side encryption instead of relying on Confidential Mode's access controls.

Do Compliance Regulations Like HIPAA Require End-to-End Encryption, or Is TLS Sufficient?

Under HIPAA, encryption is an addressable implementation specification rather than an absolute requirement. TLS 1.2 or higher is generally considered sufficient for protecting electronic protected health information in transit, provided it is properly implemented and enforced. If a covered entity determines encryption is not reasonable and appropriate, it must document the rationale and implement an equivalent alternative safeguard. The Department of Health and Human Services has signaled in proposed rulemaking that encryption requirements may shift from addressable to required. Other frameworks impose stricter standards, because the FTC Safeguards Rule mandates encryption for customer information in transit and ITAR requires FIPS 140-2 validated encryption. Even full regulatory compliance cannot protect against phishing attacks that target employees directly, making cybersecurity awareness training an essential complement to technical email controls.

Understanding whether email is encrypted by default is only useful when employees can act on it under pressure from a convincing cyberattack. Adaptive Security turns that understanding into behavior that protects regulated data every day.

Take a self-guided tour