Email encryption: TLS, end-to-end and the GDPR

Emails are often compared to postcards: anyone reading along on the way sees everything. Email encryption decides whether that is true. This post describes what transport encryption and end-to-end encryption achieve, what courts and supervisory authorities have said about them and which technology makes the difference in practice.

The post takes into account court rulings, technology and the requirements of large mail providers up to the end of October 2026.

The structure of the post follows the route of an email. It starts with the legal standard and the terms, followed by case law and the view of the supervisory authorities. Then it turns to the technology: transport encryption, checking the mail header, protection against forged senders and end-to-end methods such as S/MIME and OpenPGP. At the end there is a decision aid showing which encryption suits which type of email.

Email encryption and the GDPR: what the standard is

Personal data must be processed in a way that protects it against unauthorised access. This is laid down in Art. 5(1)(f) GDPR. Under paragraph 2, the controller must also be able to demonstrate this. How the protection looks in concrete terms is governed by Art. 32 GDPR: measures must reflect the state of the art and be appropriate to the risk. The provision does not prescribe a specific method. Encryption is merely mentioned there as a possible measure.

Special categories of data such as health data fall under Art. 9 GDPR. There, the need for protection is higher from the outset. But even seemingly harmless emails contain personal data: the sender address with a real name is enough.

In 2026, the legal situation can be summarised as follows: there is no general obligation to use end-to-end encryption for every email. Nor is there a general green light for unencrypted emails. What matters is the risk to the data subjects and the question of what is reasonable according to the state of the art. Anyone who sends personal data by email therefore needs a reasoned decision that can be presented if in doubt.

Transport encryption, end-to-end encryption and signatures clearly separated

In everyday life, three things are mixed up that do different jobs.

Transport encryption secures the connection between two stations. It uses TLS (Transport Layer Security), the successor to SSL. On each leg, the content is transmitted in encrypted form. On the mail server itself, however, it is stored in plain text, because the server has to process and store the email.

End-to-end encryption (E2E) encrypts the content in the sender's mail client. Only the recipient can decrypt it. Servers in between only see data they cannot make sense of. S/MIME and OpenPGP have become established for this.

A signature is something else: it does not encrypt anything, but proves who an email comes from and that it was not altered on the way. It plays an important role in key exchange, because public keys are usually passed on via signed emails.

Both methods share one limitation: subject, sender and recipient usually remain readable. The guidance of the German Data Protection Conference points out that these circumstances of the communication may also need protection.

Case law on email encryption: when transport encryption is sufficient

German courts have ruled on the question several times in recent years, with seemingly contradictory results. On closer inspection, the rulings follow a common line: the greater the potential damage, the higher the requirements.

The oldest case in the series dates from 2020. On 17 December 2020, the Administrative Court of Mainz decided (case no. 1 K 778/19.MZ) whether a lawyer may send emails to clients with transport encryption only. The decision is classified under Art. 32 and Art. 5 GDPR. According to the headnote, transport encryption is sufficient for lawyers' email communication. End-to-end encryption is therefore only necessary in individual cases with increased risk.

Also frequently cited, but only of limited relevance, is the decision of the Federal Court of Justice of 22 March 2021 (AnwZ (Brfg) 2/20). It concerns the special electronic lawyers' mailbox (beA). Its security architecture is based on dedicated hardware security modules. There is no entitlement to end-to-end encryption there. The decision can hardly be applied to ordinary emails.

The case before the Higher Regional Court of Karlsruhe shows the line taken in business dealings. A hacker had taken over a car dealer's email account and sent the buyer a manipulated invoice with a different account number. The buyer paid into the wrong account. On 27 July 2023, the court ruled (case no. 19 U 83/22) that the necessary protective measures depend on the legitimate security expectations of the business partners. The payment to the fraudster did not discharge the buyer, who had to pay a second time. The Regional Court of Mosbach had decided differently at first instance.

The Higher Regional Court of Schleswig reached a different result in December 2024. This case also involved a manipulated invoice, this time to a consumer and for around 15,000 euros. According to the court's press release, the invoice should have been sent with end-to-end encryption, because a hacker attack is a foreseeable risk. The customer was able to set off a claim for damages against the payment claim and did not have to pay again. The court had allowed an appeal on points of law, but according to its press release the judgment is nevertheless final. An analysis of these decisions, including a ruling of the Administrative Court of Düsseldorf of 2 April 2026 (29 K 7351/23), can be found in the post Email security: protecting messages from dangers.

How does this fit together? Apparently, the need for protection and the potential damage are decisive. Between businesses, the courts have so far tended to accept standard measures. Where a consumer transfers a large sum to an account that was named only in an unprotected email, more is required. The name of the method is secondary. What matters is that the measure actually reduces the specific risk. It remains open, for example, whether the recipient's consent to weaker encryption is sufficient. There is no reliable decision on this yet.

DSK guidance and BSI: the standard of the supervisory authorities

On 27 May 2021, the Conference of the Independent Data Protection Supervisory Authorities of Germany (DSK) adopted the guidance "Measures to protect personal data when transmitted by email", as of 16 June 2021. Bavaria voted against it. The paper is publicly available (in German) and draws a clear distinction.

At normal risk, the guidance requires mandatory transport encryption based on the BSI Technical Guideline TR-03108-1. At high risk, controllers should as a rule use end-to-end encryption together with qualified transport encryption, for example with DANE or DNSSEC. Professional secrecy is regarded as an indication of high risk, which must be assessed in each individual case.

Fines for unencrypted emails are rare; the supervisory authorities act less through sanctions than through papers like this one. Nevertheless, the guidance carries weight as a benchmark: in the disputes over manipulated invoices, the question was discussed whether the authorities' guidance can be applied. The Higher Regional Court of Karlsruhe considered it not relevant in its case. The guidance is not binding. Anyone who departs from it should, however, be able to justify doing so.

In TR-03108, the German Federal Office for Information Security (BSI) describes secure email transport for providers, including certification. For mail server operators, it is the technical benchmark. In addition, TR-03182 contains a recommendation on email authentication.

Implementing transport encryption properly: TLS 1.3, port 465, MTA-STS and DANE

Mail clients and servers speak several protocols. SMTP (Simple Mail Transfer Protocol) has been in use since 1982 and transmits emails. ESMTP is the extended variant. The abbreviations in the mail header show what happened on each leg: ESMTPS means that TLS was negotiated. ESMTPSA additionally means that the sender logged in with a username and password.

There are two ways of negotiating. With implicit TLS, the connection is encrypted from the start. For sending mail from the client, RFC 8314 provides port 465 for this, and for retrieval IMAP on port 993 or POP3 on port 995. With STARTTLS, the connection starts unencrypted and both sides only negotiate the switch afterwards. Attackers can interfere with this step. The study "Why TLS is better without STARTTLS" (USENIX Security 2021) describes downgrade and injection attacks. Implicit TLS is therefore considered the better choice, even though port 587 with STARTTLS is still offered in parallel in many places.

As for versions: TLS 1.0 and 1.1 have been officially deprecated since RFC 8996 (March 2021). TLS 1.2 is the minimum, TLS 1.3 the goal, as also stated in the BSI Technical Guideline TR-02102-2.

One problem remains between the servers. There, encryption usually runs via STARTTLS and is often only opportunistic: if it fails, the connection falls back to unencrypted. Many mail servers offer a mode that rejects delivery if no TLS connection is established. This, too, usually runs via STARTTLS and is not implicit TLS.

Two methods close the gap:

• MTA-STS (RFC 8461): The recipient domain publishes a policy stating that TLS with a valid certificate is mandatory. Sending servers comply with it. No DNSSEC is required. There are the modes testing and enforce. Reports on problems are provided by TLS-RPT.
• DANE: A TLSA record in the DNS specifies which certificate the recipient server uses. This requires DNSSEC. DANE secures the authenticity of the recipient server against downgrade and man-in-the-middle attacks.

According to Microsoft, inbound SMTP with DANE has been generally available for Exchange Online since 22 October 2024, but is switched off by default. MTA-STS is supported according to Microsoft's documentation. Online tools can check whether your own domain publishes such policies; more on this in the next section.

Checking email encryption: reading the mail header and testing the recipient server

Whether an email actually arrived encrypted is shown in the mail header. In classic Outlook versions, double-click the email, then File, Properties, and look at the Internet headers field. In the new Outlook and in webmail, the path is different. The menus change from version to version, so it is worth looking at the help of the respective program.

In the headers, the Received lines are of interest. Every server that passes the email on adds one. Modern servers enter the protocol version and cipher there, such as TLSv1.3 and TLS_AES_256_GCM_SHA384. The excerpt below is reconstructed, with placeholders instead of real addresses.

However, the header is not complete proof within the meaning of Art. 5(2). It only covers the legs on which a server added the line. Where forwarding or gateways are involved, a gap remains. It is still useful as one element of documentation.

Before sending, you can test what a recipient server supports. CheckTLS queries the capabilities without sending an email and shows, among other things, whether TLS is offered and whether a TLSA record for DANE exists. The result "no TLSA" is common for many domains. The service internet.nl checks STARTTLS, DANE as well as SPF, DKIM and DMARC. According to its documentation, MTA-STS is not part of the assessment.

If the TLS result is negative, notifying the recipient helps. Alternatively, a portal or an encrypted attachment can be used; more on this below. For your own website and its protective measures, the GDPR website check offers initial guidance. Security checks for domains, including email authentication, are available in the Web Security Checks.

SPF, DKIM and DMARC: protection against forged senders

Encryption protects against eavesdropping, not against forgery. That is exactly what the invoice cases were about: an attacker sends an email that looks as if it came from the genuine sender, or uses a hijacked mailbox. Three methods that work together help against forged senders.

Recently, the pressure to introduce them has come from the large providers. Since 1 February 2024, Google and Yahoo have required all senders to use, among other things, SPF or DKIM, TLS and a low spam rate. Anyone who sends more than 5,000 emails a day to Gmail addresses needs SPF, DKIM and at least a DMARC policy. Microsoft introduced similar requirements for high-volume senders to Outlook.com, Hotmail and Live from 5 May 2025. The rules in detail can be found in Google's documentation.

The DSK guidance provides that DKIM and DMARC are checked on receipt. A trend is emerging here that controllers would do well not to ignore. More background on forged messages is available in the post Emails, phishing and the authenticity of electronic messages (in German). There is a separate post (in German) on dealing with unknown senders and attachments.

End-to-end encryption with S/MIME and OpenPGP: the state of play in 2026

Anyone who wants or needs to go beyond transport encryption has two established methods. Both encrypt the content in the mail client. Both require keys to be exchanged beforehand. The DSK guidance calls end-to-end encryption the "most thorough protection", because it also protects data at rest.

S/MIME

S/MIME works with certificates issued by a certification authority. They can be used directly in Outlook, Apple Mail and many other programs. The sender usually obtains the recipient's public key from a signed email, from which the certificate can be imported.

A lot has changed regarding certificates since 2021. The classes 1 to 4 that used to be common are outdated. Since 1 September 2023, the Baseline Requirements of the CA/Browser Forum have applied, with four types that differ in the scope of validation: mailbox-, organization-, sponsor- and individual-validated. The forum itself publishes the current version of the requirements.

OpenPGP

OpenPGP works without a central certification authority. Everyone generates their own key pair. Authenticity is checked via fingerprints or certification by third parties. The DSK explicitly points out that merely publishing a key on a key server is no indication of its authenticity. The Web Key Directory is practical, as it lets a domain provide its keys itself. An introduction to signing can be found in the post Sign and send emails with PGP.

The standard has changed: RFC 9580 (July 2024) replaces RFC 4880. It brings new key formats, modern algorithms such as X25519 and Ed25519, and authenticated encryption. In parallel, the GnuPG project maintains a diverging line called LibrePGP. This complicates matters. Thunderbird uses its own library called RNP instead of GnuPG, and Mozilla documents problems with keys that have features RNP does not support. So keys do not always move smoothly between programs.

In practice with Outlook and Thunderbird

In practice, there is often a difference between using one account and several. The GpgOL plugin from the Gpg4win package can be set up in Outlook and works with one account. With several accounts, however, a prompt appears every time you send, and the assignment of keys can get mixed up. For environments with many accounts, this is an obstacle.

Gpg4win is currently available in version 5.1.1 (released on 23 September 2026), as the project page shows. GpgOL runs in classic Outlook. Whether and when it will support the new Outlook is open, according to a post in the GnuPG forum. OpenPGP has been built into Thunderbird since version 78, so no add-on is needed. It is set up in the account settings under end-to-end encryption. Anyone using only one account will get there quickly.

In December 2025, the BSI examined twelve free email programs. According to its press release (in German), the programs differ in their support for end-to-end encryption. Security features are often not enabled by default.

A side issue is the Efail attack from 2018. It exploited active HTML content in emails to leak decrypted texts. Countermeasures are up-to-date programs and disabling HTML rendering for encrypted emails. The website efail.de provides an explanation. There is no need to panic, but the example shows that even good cryptography can fail because of its implementation.

Portals, gateways and Microsoft encryption as alternatives

The biggest obstacle to end-to-end encryption is exchanging keys with every correspondent. That is why many organisations rely on solutions in which the effort lies with the sender.

• Gateway encryption: A server within the company handles S/MIME or PGP. The protection then extends to the recipient's gateway. Depending on the setup, the email is stored decrypted in the mailbox. The question of trust shifts to the operator of the gateway.
• Portal: The email only contains a notification. The message is collected in the browser after logging in. The DSK guidance also mentions a web portal as a communication channel with data subjects.
• Microsoft Purview Message Encryption: Usable in the new Outlook with a suitable licence. Recipients outside Microsoft receive instructions on how to open the message. It cannot be combined with S/MIME on the same message.
• Password-protected attachment: An archive with AES-256, created with 7-Zip for example, serves as an envelope. The password is sent via a different channel, for example by phone (channel separation). SMS is controversial as a channel and should only be used with reservations.

Anyone who operates a gateway or portal through a service provider usually concludes a data processing agreement under Art. 28 GDPR. Risks to the account itself associated with Microsoft 365 are described in the post on token spraying.

The trade-off is a sober one: anyone who shies away from key management gets a practical middle way with a portal or gateway. It involves compromises compared to genuine end-to-end encryption, but is significantly better than a plain-text email with sensitive content.

Post-quantum cryptography for email: what already counts today

End-to-end encryption has a property that is often overlooked: it does not offer perfect forward secrecy by design. The DSK writes that intercepted emails can be stored and decrypted later if the private key is disclosed. With future quantum computers, this scenario could also occur without a key being lost.

Standardisation is under way. With RFC 9936 (March 2026), there is a standard for ML-KEM in CMS, the basis for S/MIME. For TLS 1.3, BSI TR-02102-2 provides for hybrid methods that combine classical and post-quantum algorithms. For everyday use, this does not create any need for action. Anyone who sends content that must remain confidential in 15 years' time should keep an eye on the topic, though.

Misdirected emails, data breaches and fax: the limits of encryption

One drawback of transport encryption still applies today: it is of no use if the recipient address is wrong. The email arrives encrypted on the wrong server and is stored there in plain text. End-to-end encryption is different, provided that it was addressed to the intended recipient. The DSK explicitly mentions individual addressing as a measure.

That is why the organisational side matters. This includes switching off autocomplete for sensitive recipients, a four-eyes principle for delicate content and checking the address before sending. Whether a misdirected email must be reported as a data breach depends on the risk and belongs in a separate procedure.

Fax also comes up in this debate. The Bremen State Commissioner for Data Protection and Freedom of Information compared fax with unencrypted emails on a page on guidance (in German). In a 2020 decision (11 LA 104/19), the Higher Administrative Court of Lüneburg considered an individual assessment necessary for particularly sensitive data.

Which encryption for which email: a decision aid

A rule of thumb can be derived from the rulings and guidelines. The higher the potential damage and the need for confidentiality, the more likely end-to-end encryption or a portal should be considered. For invoices, an additional rule applies: a change of bank details is confirmed via a second channel, for example by phone.

The table is intended as guidance and is not legal advice. Assessing the risk is the controller's responsibility and should be documented. A short check helps: what would be the worst realistic damage for the data subjects? How likely is it? Which measure noticeably reduces it?

Conclusion

Transport encryption is mandatory and, according to the DSK and case law, usually sufficient at normal risk, provided it is set up consistently and in line with the state of the art. This includes TLS 1.2 or, better, 1.3, implicit TLS in the mail client and MTA-STS or DANE on the server side. At high risk, end-to-end encryption or an equivalent solution is expected.

Email encryption remains a topic of trade-offs. Key management is tedious, portals are a pragmatic middle way, and against fraud SPF, DKIM, DMARC and a second channel for payment details help at least as much as cryptography.