Registered and encrypted email: how to balance confidentiality and content proof

5 min read

Registered email (ERDS, electronic registered delivery service according to eIDAS) seeks to provide conclusive evidence of the sending, delivery, and content of a digital communication. The way information is encrypted during transmission conditions what type of evidence can be issued.

In this article we compare two common models:

TLS (channel encryption): protects transmission and allows content certification.
E2EE (end-to-end encryption): maximizes confidentiality, but limits or prevents content certification without introducing “trust windows”.

What should a registered email prove?

For the communication to have probative validity:

Sending: who sends and to whom.
Delivery: when the destination server accepted the message.
Content: the exact text and attachments (integrity).
Time stamps: reliable dates/times.
(Optional) Reading: message opening by the recipient.

Without access to clear content (unencrypted content) at some controlled point, the trusted third party cannot calculate a verifiable hash of the content or sign and custody it with guarantees.

TLS model: security in transit with probative traceability

What it is

TLS (Transport Layer Security) encrypts the channel between email clients and servers: data travels encrypted in transit.

What it allows

The provider can receive and process the message in clear within its secure perimeter, calculate the hash of the content (text + attachments), timestamp it, sign it, and custody the evidence.

Advantages:

Confidentiality in transit and protection against manipulation.
Universal compatibility (requires nothing from the recipient).
Solid proof of content (verifiable hash + custody).

Result: balance between security and content proof.

E2EE model: absolute confidentiality, probative dilemma

How it works

The sender encrypts with the recipient’s public key; only they, with their private key, can decrypt. In theory, no one else (not even the provider) can read the message.

Consequence

The provider cannot see the content → cannot calculate the hash of clear content, nor include it in a certificate with content proof. They can certify sending/delivery of “something encrypted”, but not what was sent.

Authentic E2EE turns the provider into a witness of the envelope, not the letter.

Does hashing the encrypted DATA sent via SMTP work?

Hypothesis: “Even with E2EE, the provider could hash the DATA (ciphertext) that circulates via SMTP.” Would it serve as a representative element of sent content?

Key problems:

The hash would represent the ciphertext, not the clear content.
Modern encryption is probabilistic (uses IV/salt/nonce): the ciphertext changes even if the content is the same, so the ciphertext hash is not a stable identifier of the content.
Without the recipient’s private key, there is no publicly verifiable mechanism to link that ciphertext hash with the original text/attachments.

Conclusion: the encrypted traffic hash does not resolve content proof.

When talking about “content encryption”: options and sacrifices

To encrypt and certify content simultaneously, there are hybrid schemes that introduce trust windows. In all cases, we can no longer speak of “pure” E2EE.

Variant	Who can see the content?	How is content certified?	What is sacrificed?
Pure TLS (encrypted channel)	Provider (in controlled environment) and recipient	Hash of clear content + signature + timestamp + custody	Nothing essential: security/proof balance
Real E2EE	Only the recipient	Content cannot be proven without their cooperation	Content proof
Controlled internal decryption	Provider temporarily	Decrypted within perimeter to hash/sign and then re-encrypted	Authentic E2EE (access window appears)
Encrypted custody with provider key	Provider under conditions	Recoverable encrypted copy to certify content	Authentic E2EE (trust model in provider)
Delegated key management (frictionless)	Provider and recipient	Provider controls keys, certifies without recipient actions	Authentic E2EE (provider can read)

If no one except the recipient can access the content, the provider cannot certify the complete content by themselves. To do so, there must be some “window” (temporal or procedural) in which they can see it.

Frequently Asked Questions (FAQ)

Why doesn’t TLS “weaken” the proof?
Because it encrypts the transport and allows the provider, as a trusted third party, to verify clear content in a controlled environment to hash, sign and custody it. That strengthens the proof.

Does E2EE prevent all proof?
No. It allows certifying sending/delivery of a ciphertext, but not the content without recipient cooperation or without introducing an access window.

What exactly are “internal decryption” and “custody”?

Internal decryption: temporary opening of content within the provider’s perimeter to be able to hash/timestamp.
Custody: secure long-term preservation of evidence (hashes, timestamps, certificates and, according to model, content), with traceability and controls.

Is “reading” strong proof?
It’s an indication (based on opening signals), useful but not infallible. Strong proof focuses on content, sending and delivery.

When to choose each model?

I need to certify content (contracts, claims, notifications with deadline):
TLS + content certification → balance between confidentiality and proof.
Absolute confidentiality is paramount (health, banking, defense) and I can use other mechanisms to prove content (e.g., electronically signed document):
Real E2EE → maximum privacy, with probative limitation.

Conclusion

There is no “better” encryption in the abstract.

If the goal is to prove content, the model must allow the trusted third party to access the clear message at a controlled point to hash, timestamp and custody it. TLS offers that balance.

Authentic E2EE prioritizes privacy, but renounces content proof except with recipient cooperation or the introduction of trust windows, which by definition cease to be pure E2EE.

Table of contents