Why Email Is Not a Secure Way to Transmit Data

Email is the most widely used communication tool in professional life – and one of the least protected. Anyone sending confidential documents, credentials, contracts or personal data by email is relying on a method designed in the early 1980s, long before confidentiality was a technical requirement. The result is a system that delivers reliably but says nothing, by default, about who can read, store or alter a message along the way. This article explains why email is not a secure way to transmit data, where its contents become visible, which protective mechanisms exist – and where their limits lie.

• How an Email Is Actually Transmitted
• Transport Encryption: What TLS Does – and Does Not
  • Opportunistic Encryption and Its Gaps
• Data at Rest: Servers Can Read Along
• Metadata Stays Visible
• Points of Attack Along the Path
• End-to-End Encryption: PGP and S/MIME
  • Why End-to-End Encryption Rarely Works in Practice
• Email and the GDPR
• Common Misconceptions in Practice
• Checklist: When Email Is Not Enough
• Secure Alternatives to Email Transmission
• Frequently Asked Questions
• Conclusion

#How an Email Is Actually Transmitted

The common assumption that an email travels "directly" from sender to recipient is technically incorrect. In reality it is a relay process based on the "store and forward" principle. A message typically passes through several stages: the sender's outgoing mail server, possibly intermediate relays, the recipient's incoming mail server and finally the recipient's mailbox. The underlying protocol is SMTP (Simple Mail Transfer Protocol), and it describes only how messages are transported from one server to the next – not how they are protected.

At each of these stages the message is received in full, stored temporarily and then passed on. Every server involved therefore has, in principle, the ability to read its contents. A fitting analogy is the postcard: it arrives reliably, but everyone whose hands it passes through can read it. A letter in an envelope would be the opposite model – and that envelope is precisely what email lacks in its basic form.

There is a further point: the sender has no control over the route a message takes or which systems it passes through. In communication between two organisations, service providers, spam filters, archiving systems and cloud platforms are often involved, all invisible to the sender. Security cannot be guaranteed for a path you do not even know.

#Transport Encryption: What TLS Does – and Does Not

Modern mail servers usually encrypt the connection between two stages using TLS (Transport Layer Security), often negotiated via the STARTTLS command. This is genuine and important protection: while the message travels from one server to the next, it is shielded against eavesdropping on that segment. Yet this is where a widespread misunderstanding arises.

TLS protects the connection, not the message. It only ever secures the segment between two directly adjacent servers. As soon as the message arrives, it sits on that server in decrypted form before being encrypted again for the next segment. This is known as hop-to-hop encryption, as opposed to continuous end-to-end encryption. Between the stages, the content is available in plain text.

#Opportunistic Encryption and Its Gaps

In the classic email world, transport encryption is also "opportunistic": servers attempt to use TLS but fall back to an unencrypted connection if the other side does not support it. The sender has no way of knowing whether a particular message was in fact encrypted across every segment. An attacker positioned in between can exploit this flexibility and force a so-called downgrade, in which encryption is dropped – without either party noticing.

Mechanisms such as MTA-STS and DANE were developed to make such downgrades harder by mandating encrypted connections. However, they are not universally implemented and do nothing to change the fundamental problem: even perfectly continuous transport encryption protects the message only while it is moving, not at its resting points.

#Data at Rest: Servers Can Read Along

The greatest weakness is not on the wire but at the stations. At every mail server involved – and especially in the destination mailbox – the message sits in plain text unless end-to-end encryption is used. In principle, that gives access to:

• the email providers of both sender and recipient,
• administrators with the relevant permissions,
• backup systems that regularly write mailboxes into backups,
• archiving solutions that retain messages for the long term in an audit-proof manner,
• and potentially attackers who have compromised one of these systems.

These plaintext copies often persist for years. A confidential piece of information, once sent, can practically never be recalled or reliably deleted, because it is stored in places the sender does not control. It is precisely this persistence that distinguishes the risk of email from that of a fleeting transmission error.

#Metadata Stays Visible

Even when the content of a message is encrypted, a substantial amount of accompanying information remains exposed. This includes sender and recipient, the time of sending, the subject line and technical headers that document the message's path across the servers involved. This metadata often reveals more than people assume: who communicates with whom, when and how often allows inferences about business relationships, negotiations, legal matters or health-related circumstances.

The subject line is a particularly underrated case. Even with end-to-end encryption via PGP or S/MIME it is, by default, not encrypted and remains in plain text. A subject such as "Termination of employment, Smith" or "Oncology results" already discloses the confidential nature of the message before it is even opened.

#Points of Attack Along the Path

The following overview maps the typical weaknesses to their respective stages:

The table makes clear that there is not one single weak spot but a chain of points where confidentiality can be lost. Securing only the transmission ignores most of the risks.

#End-to-End Encryption: PGP and S/MIME

The obvious objection is: can email not be secured with genuine end-to-end encryption? In principle, yes. Methods such as OpenPGP and S/MIME encrypt the message content on the sender's device so that only the intended recipient can read it again. The intermediate stages then see only unintelligible data. Where this is applied consistently, email is in fact confidential.

#Why End-to-End Encryption Rarely Works in Practice

The decisive issue is practicality. Both methods require sender and recipient to use the same system, to have generated and exchanged cryptographic keys, and to keep those keys secure. This raises several hurdles:

• A mutual prerequisite. You can only encrypt if the other side is prepared. In spontaneous communication with clients, authorities or new business partners, that is rarely the case.
• Key management. Keys must be generated, distributed, verified, revoked when lost and renewed regularly. These tasks overwhelm many organisations in day-to-day operations.
• Unencrypted metadata. As noted, the subject line and headers remain exposed, which noticeably limits the protective effect in practice.
• Susceptibility to error. A message accidentally sent without encryption, or a key sent to the wrong person, undermines the protection without anyone noticing.

End-to-end encryption is therefore not a myth, but it is demanding, dependent on both sides, and barely sustainable for broad, spontaneous communication. Readers who want to understand the distinction in detail will find a deeper comparison in End-to-End vs. Transport Encryption.

#Email and the GDPR

Sending personal data unencrypted is not categorically prohibited, but it is legally risky. Article 32 of the GDPR obliges controllers to implement technical and organisational measures appropriate to the risk. The benchmark is therefore not a fixed ban but a risk-based assessment: the more sensitive the data – health data, financial information, or data concerning particularly vulnerable individuals – the higher the requirements for its protection.

In practice this means that for an everyday, low-sensitivity message, transport encryption may suffice. For confidential or particularly sensitive content it is regularly insufficient, because plaintext storage at the intermediate stages and the absence of continuous encryption do not reflect the state of the art for such data. Supervisory authorities take a correspondingly critical view of sending sensitive data unencrypted.

The GDPR sets an international framing here; specific national supervisory expectations and sector rules may add further requirements. What matters across jurisdictions is a demonstrable and appropriate level of protection rather than a particular technology. A structured approach to compliant transmission is described in Transmitting Personal Data in a GDPR-Compliant Way.

#Common Misconceptions in Practice

Three assumptions lead to poor decisions especially often. First, the idea that a padlock symbol in the mail program means the message is secure. In reality it signals, at most, an encrypted connection to one's own mail server, not continuous protection all the way to the recipient. Second, the assumption that sending internally within the same organisation is uncritical. There too, the message passes through servers, backups and archives and is readable by administrators. Third, the belief that a password-protected ZIP attachment solves the problem. If the password is sent over the same or a similarly insecure channel, the protection is largely ineffective, and weak passwords can additionally be cracked by machine.

A typical scenario illustrates the consequences. A law firm sends a brief containing personal data to a client. The transmission goes over TLS, and the subject line names the client and the matter in dispute. Even if no one reads along in transit, the message then sits permanently in plain text in the client's mailbox, in their backups and in the firm's archive. If one of these mailboxes is compromised or a device is stolen, the entire matter is exposed – possibly years later, and without the original sender noticing anything.

The lesson is organisational in nature. Security does not arise from individual staff remembering to encrypt in particular cases, but from confidential sending running over a protected route by default. A method that only works when everyone involved applies it correctly and voluntarily is not reliable in daily practice. This is precisely why responsibility shifts from the individual decision towards a process that makes the secure route the default.

#Checklist: When Email Is Not Enough

The following list helps with classification. If any of these points apply, confidential content should not be sent by ordinary email:

• The message contains special categories of personal data (health, religion, trade union membership, sex life, biometric data).
• It concerns credentials, passwords, keys or tokens.
• Contracts, financial documents or client data are involved.
• The set of recipients is uncertain, or the message could reach third parties by accident.
• There is a contractual or statutory duty of confidentiality.
• You cannot reliably ensure that the other side supports end-to-end encryption.
• The content should no longer be accessible after a certain period.

The more of these points apply, the clearer the answer: email is the wrong tool here.

#Secure Alternatives to Email Transmission

The conclusion to draw from these weaknesses is not to abandon digital communication, but to use a purpose-built method for confidential content. Instead of sending a file or message through a chain of foreign servers, the confidential content is stored in a protected place; the recipient retrieves it through a secured access route. The email then carries only a link – not the content itself.

Useful properties of such a method are:

• End-to-end protection based on the zero-knowledge principle, where even the provider cannot decrypt the content. A detailed explanation is offered in Zero-Knowledge Explained.
• One-time links that automatically expire after the first retrieval, preventing an intercepted link from being used more than once.
• Self-destructing content that is no longer retrievable after a set period, addressing the problem of persistent plaintext copies.
• A secure inbox through which third parties can also send you confidential information without having to set up encryption themselves.

Crymbl is built precisely on these components: secure sharing of files and messages, one-time links, self-destructing content and a zero-knowledge concept that does not make confidentiality dependent on the technical preparation of the other side. How to transmit confidential files in concrete terms is shown in Secure File Sharing and One-Time Links.

#Frequently Asked Questions

Is an ordinary email encrypted? The content itself usually is not. What is encrypted, where available, is the connection between two mail servers. At the stations and in the mailbox, the message sits in plain text.

What good is transport encryption, then? It protects the message against eavesdropping on the respective segment, which is worthwhile. But it protects neither the content at rest on the servers nor the metadata, and it does not guarantee that every segment was actually encrypted.

What is the difference between transport and end-to-end encryption? Transport encryption secures the connection segment by segment; between the segments the content is exposed. End-to-end encryption secures the content continuously from sender to recipient, so that intermediate stages cannot read it.

May I send personal data by email? There is no blanket prohibition, but Article 32 of the GDPR requires measures appropriate to the risk. For sensitive data, ordinary email is regularly insufficient.

Are PGP and S/MIME a sufficient solution? Technically yes, in practice only to a limited extent. Both sides must master them, manage keys and live with unencrypted subject lines. For spontaneous, broad communication they are hard to sustain.

How should I send confidential content securely instead? By storing the content in a protected place and having it retrieved through secured access – for example via zero-knowledge services with one-time links and self-destructing content. Only the link is then sent, not the information.

#Conclusion

Email is an excellent tool for reliable delivery – but not a tool for guaranteeing confidentiality. The method was designed for reachability, not for protection. Transport encryption mitigates part of the problem but leaves plaintext storage at the stations, exposed metadata and the absence of continuous encryption untouched. End-to-end methods solve this in principle but fail at scale because of their lack of practicality.

For confidential and personal data, the robust answer is therefore not to configure email better, but to separate the content from the email: only a link travels through the open system, while the protected content stays in a controlled place. Implementing this separation consistently also satisfies the requirements of Article 32 of the GDPR and significantly reduces the risk of accidental disclosure.