Registered Email Service Models: Direct Intermediary vs Copy-to-Third-Party

Registered email (ERDS, or electronic registered delivery service under the eIDAS Regulation) provides conclusive proof of sending, content, and delivery of a digital communication.

There are two common technical architectures for delivering this service:

1. The direct intermediary model, where the service provider acts as the central channel for transmission.
2. The copy-to-third-party model (CC/BCC), where the provider receives the communication as a copy and certifies it afterwards.

In this article we analyze how each model works, their pros and cons, and which one provides stronger legal and technical assurance.

1. Direct intermediary model

Flow: the sender does not send the email directly to the recipient, but to the service provider. The provider receives it, generates the technical evidence (timestamp, cryptographic hash, traceability) and then forwards the message to the final recipient.

Pros:

• Full provider control: the provider sees and certifies the exact content delivered, with integrity guarantees.
• Strong traceability: easily meets eIDAS trust requirements (integrity, timestamp, proof of transmission and receipt).
• User simplicity: the client only needs to send to the provider, which manages the entire delivery process.
• Transparency for the recipient: they receive a standard-looking email in their inbox, without the provider’s intervention being necessarily apparent.
• Deliverability and security assurance: the need to comply with DMARC raises the level of authenticity and protection against spoofing, while also ensuring deliverability.
• Clear legal compliance: the certification is robust and difficult to challenge, as the provider controls the full flow.

Cons:

• Provider dependency: all traffic flows through the provider. If its infrastructure is not properly dimensioned, it can create bottlenecks or service interruptions.
• Requires DNS adjustments (SPF, DKIM): to comply with DMARC, the client must correctly configure their DNS records, which adds some initial complexity.

2. Copy-to-third-party model (CC/BCC)

Flow: the sender sends the email directly to the recipient and includes the provider in copy (CC or BCC). When the provider receives the message, it validates it, generates the proof, and resends it to the recipient as confirmation.

Pros:

• Lower initial friction: it only requires adding the provider in copy.
• Partial decoupling: communication between sender and recipient continues even if the provider is inactive (though without certification).

Cons:

• Weaker legal robustness: the provider does not control the original transmission, so proof of effective delivery is weaker.
• Provider as sender in forwarded copy: the re-sent email comes from the provider’s address, making the communication less natural and potentially raising doubts, while also conflicting with strict email security policies.
• Message duplication: the recipient receives two emails (the original and the provider’s re-sent version), which can cause confusion.
• Validation complexity: the provider certifies after the fact, which can be more legally questionable.
• Risk of discrepancies: in theory, the client could send one version to the recipient and another to the provider, undermining trust.

3. Risk of divergent messages

In the copy-to-third-party model, a client could use SMTP connections to send two different messages: one to the recipient and another to the provider.

This creates a critical issue:

• The essence of a registered email service is to ensure that the certified message is the same one the recipient actually receives.
• If two different versions exist, the certification loses probative strength and could even be invalidated in court.

Conclusion: which model is more solid?

• The direct intermediary model best meets the requirements of the eIDAS Regulation and legal expectations: full provider control, complete traceability, and strong probative value.
• The copy-to-third-party model may be useful for lightweight traceability or internal certification, but it is legally weaker and opens the door to inconsistencies that may undermine the service.

In short: If the objective is a registered email service with full legal validity, the most reliable model is the direct intermediary architecture, ensuring that the certified message is exactly the same one delivered to the recipient.