Registered mail,for email.
With registered post the recipient signs. With email their server acknowledges, and legally that is what counts. SecureMail records that acknowledgement, along with hash values, the type of connection and every opening in the message portal, in a log that cannot be smoothed over after the fact.
- Recipient
- kanzlei@example.de
- Handover
- mx01.example.de
- Response
- 250 2.6.0
- Their queue ID
- 67057324398940
- Connection
- DANE, TLSA verified
- Opened in portal
- 2026-09-12 16:37 UTC
- Hash of bytes
- 4ed514cab04b137d050d895804aad3d7
8c6fab84cc8aff0f0458fb55c65f8f6d
Registered mail for email: proof of delivery that holds
Electronic registered mail is not a postal product but a question of logging. Anyone who has to prove a message arrived needs the receiving server’s response, the hash of the content handed over and a log that cannot be altered afterwards. That is what Conbool SecureMail produces for every message, without the recipient having to do anything.
Why the usual routes do not hold.
The screenshot of the sent folder
Proves you sent it. It says nothing about arrival, which is precisely the question in a dispute.
The read receipt
Only arrives if the recipient sends it. They may decline, many clients never send one, and you will not even learn that they declined.
No error message received
Is not proof. A message can sit in a filter, land in quarantine or be moved by a rule without the sender ever finding out.
The server log file
Often holds the right details, but can be edited afterwards. That objection arrives reliably once it matters.
Three points that make the difference, and that explain what a usable proof has to aim at. German law; the picture differs elsewhere.
The mail server is the recipient’s sphere
In business-to-business dealings under German law, an email is deemed received once it is available on the recipient’s mail server during normal business hours. Whether it was read does not matter.
German Federal Court of Justice, 6 October 2022, VII ZR 895/21
The burden of proof is on the sender
Whoever relies on receipt has to prove it, in full. Sending alone is not enough.
Section 130(1) German Civil Code
No prima facie evidence for a plain email
For a plain email without confirmation there is no prima facie evidence of receipt, not even when no non-delivery notice came back.
Higher Regional Court Rostock, 3 April 2024
This page gives a general overview and is not legal advice. How a court weighs a given piece of evidence depends on the case.
How the evidence is created
Four steps, three of which the sender never notices.
Send as usual
From Outlook, from any client, through the gateway. No extra software for the sender, no account for the recipient.
The handover is acknowledged
The receiving server accepts the message and responds with a status code and a queue identifier of its own. Both are recorded, along with the time, the type of connection and the hash of the bytes handed over.
Opening is logged
If the message runs through the message portal, every opening and every attachment download is recorded with time and IP address. The recipient cannot decline it, because it is not their client reporting but the portal logging.
Produce the evidence
From the chain, an evidence document is produced as a PDF, on demand in message tracking or automatically by email, immediately or as a daily summary.
What the evidence document contains
Not a note, but the details from which the event can be reconstructed.
The message
Sender, recipient, subject, size, time and the method by which it was secured: S/MIME, OpenPGP, password-protected PDF or the message portal.
The handover
Name of the receiving server, SMTP response code, enhanced status code, time and the queue identifier the receiving server itself assigned.
The connection
TLS, MTA-STS or DANE, stating whether encryption was mandatory and whether the target was verified through its TLSA record.
Integrity
SHA-256 of the bytes handed over, of the stored message and of every single attachment.
The history
Every event with time, actor and the hash of the chain entry: acceptance, delivery, opening in the portal, attachment downloads, administrative access.
The chain check
The document recomputes the entire chain and states the result, along with the time of the last seal. A later change would show up here.
A log that can be edited is open to attack in a dispute. That is why it is chained and sealed.
Every entry knows its predecessor
Each entry carries the hash of the previous one. Change an entry afterwards and every following entry becomes arithmetically invalid, and the check fails.
The head is sealed
Every fifteen minutes the head of the chain is recorded and the seal stored immutably. That rules out rewriting the whole chain as well.
Nothing is overwritten
The log only accepts entries; it does not change or delete them. Administrators cannot remove an entry either, only add a new one.
Retention governed separately
The chain is not subject to the retention period of the messages. For ongoing litigation you set a legal hold, which suspends deletion for a given period.
What it is not
Three boundaries, so nobody expects more than the evidence carries.
Not postal registered mail
There is no courier and no recipient signature. What is proven is the handover to their mail server, and in the message portal the opening as well.
Not a qualified timestamp
Times come from the operation of the service, not from a qualified trust service provider under eIDAS. Anyone who needs that needs a trust service in addition.
Not a qualified signature
The evidentiary force of private documents under section 371a of the German Code of Civil Procedure requires a qualified electronic signature. Proof of delivery does not replace it.
No proof of opening in the mailbox
If a message goes straight to the mailbox via S/MIME or OpenPGP, delivery is provable but the opening is visible to no one, ourselves included.
Frequently asked questions
Is registered mail by email legally valid?+
The question usually covers two things. First, form: where the law requires written form, an email will not do, regardless of the evidence. Second, receipt: under German law an email in business-to-business dealings is deemed received once it is available on the recipient’s mail server during normal business hours. That is exactly the moment the proof of delivery documents, with the receiving server’s acknowledgement.
How is this different from a read receipt?+
A read receipt is sent by the recipient’s mail client, voluntarily. They can decline, and many clients never send one. Proof of delivery is created on our side, from the receiving server’s response. It needs no cooperation from the recipient.
Does the recipient have to install or register anything?+
No. For proof of delivery the recipient does nothing at all. If the opening is to be proven as well, the message runs through the message portal: the recipient opens a link there, with no account and no registration.
What does a single proof cost?+
Nothing extra. The evidence is created for every message that runs through SecureMail and is part of the module. There is no per-item charge as with registered post.
Can we enable it for selected senders only?+
Yes. The logging always runs; sending the evidence automatically can be narrowed down to selected sender addresses or to groups, for instance the legal department only. The timing is selectable too: immediately after the event or as a daily summary.
How does this differ from De-Mail?+
De-Mail is a statutory German procedure with accredited providers and dedicated mailboxes on both sides. SecureMail’s proof of delivery requires no special procedure at the recipient: it works towards any ordinary email address, but it also lacks the statutory effects attached to De-Mail.
How long does the evidence remain available?+
The evidence chain is not subject to the retention period of the messages themselves, so it survives once the content had to be deleted. For ongoing litigation you additionally set a legal hold, which suspends deletion for a given period or for given addresses.
Does it cover encrypted messages too?+
Yes, and there it matters most. The document states the method by which the message was secured, whether the connection was enforced through DANE or MTA-STS and the hash of the bytes handed over. With delivery through the message portal, the logged opening is added.
Test it on your own case
Tell us what you need to prove. We will show you, on a real message, what the evidence document looks like, and say plainly where it reaches its limit.