eidas.pt

Guide

Electronic registered delivery

What eIDAS says — and does not say — about email, which presumption each qualified service gives, and what is proven at each step of a qualified registered delivery.

ERDS = electronic registered delivery service (Art. 3, point 36) · QERDS = the same, qualified (Art. 3, point 37).

eIDAS and email

eIDAS does not require any particular mechanism for email in general. It does not oblige anyone to use SPF, DKIM, S/MIME, a qualified signature or registered delivery to communicate by email. An ordinary email remains a valid electronic document.

The Regulation does two things:

  1. It bans discrimination against electronic form. Legal effect and admissibility as evidence cannot be denied solely because something is electronic or not qualified: electronic documents (Art. 46), signatures (Art. 25(1)), seals (Art. 35(1)), time stamps (Art. 41(1)) and data sent by registered delivery (Art. 43(1)). Outside qualified services, the weight of evidence is assessed under each Member State’s procedural law.
  2. It gives legal effects to qualified services. Qualified signatures, seals, time stamps, registered delivery and electronic archiving each have their own legal effect, and qualified status is recognised in every Member State (Art. 24a). That is what changes: whoever relies on one of these services starts with the law on their side.

Where a law, regulation or contract requires a specific form — notice, registered letter, signature — that rule defines what satisfies it. eIDAS does not say registered email replaces registered post; it says what effects a qualified registered delivery has.

“Registered email” is a commercial name. Only a service listed on the trusted list (Art. 22) as a qualified electronic registered delivery service on the date of sending benefits from Art. 43(2).

One service, one presumption

eIDAS has no “general presumption of validity”. Each of these qualified services has its own effect, and each covers something different. A legal presumption relieves whoever relies on it from proving the presumed fact; whoever contests it has to show otherwise, under the applicable procedural law. eIDAS does not say whether or how it can be rebutted.

Qualified electronic signature

“A qualified electronic signature shall have the equivalent legal effect of a handwritten signature.”Art. 25(2)

Covers

  • The natural person being bound by the content, as with a handwritten signature
  • Through the nature of advanced signatures, detection of later changes

Does not cover

  • Sending, receipt, the addressee
  • The date and time, without a qualified time stamp
  • Legal persons: they use seals

Qualified electronic seal

“A qualified electronic seal shall enjoy the presumption of integrity of the data and of correctness of the origin of that data to which the qualified electronic seal is linked.”Art. 35(2)

Covers

  • Integrity of the data
  • Origin: the legal person that sealed it

Does not cover

  • The will of a natural person
  • Sending, receipt, timing

Qualified electronic time stamp

“A qualified electronic time stamp shall enjoy the presumption of the accuracy of the date and the time it indicates and the integrity of the data to which the date and time are bound.”Art. 41(2)

Covers

  • The data existed at that date and time
  • It has not changed since

Does not cover

  • Who the author is
  • Whether and when it was sent or received

Qualified electronic registered delivery

“Data sent and received using a qualified electronic registered delivery service shall enjoy the presumption of the integrity of the data, the sending of that data by the identified sender, its receipt by the identified addressee and the accuracy of the date and time of sending and receipt indicated by the qualified electronic registered delivery service.”Art. 43(2)

Covers

  • Integrity of the data
  • Sending by the identified sender
  • Receipt by the identified addressee
  • Date and time of sending
  • Date and time of receipt

Does not cover

  • The sender signing the content
  • The addressee reading or agreeing
  • The truth of what it says

Qualified signature or registered delivery?

They answer different questions. A qualified signature answers “who is bound by this content?”. Qualified registered delivery answers “who sent what to whom, and when?”.

Qualified electronic signature

  • It sits in the document itself and travels with it.
  • It identifies the signer through a qualified certificate (Art. 3, point 12).
  • It is equivalent to a handwritten signature (Art. 25(2)).
  • It knows nothing about how the document travelled, who received it or when.
  • A signed email sent over ordinary SMTP still has no proof of delivery.

Qualified electronic registered delivery

  • It sits in the transport: the evidence describes what happened to the message.
  • It identifies sender and addressee (Art. 44(1)(b) and (c)).
  • It presumes integrity, sending, receipt and the times (Art. 43(2)).
  • It does not make the content “signed” by the sender. The evidence is sealed by the provider, not the sender.
  • An unsigned offer sent by QERDS proves it was sent and received, not that the sender subscribed it in the form a written contract may require.

The two combine: a contract signed with a qualified signature and sent by QERDS carries both the signer’s commitment and proof of delivery.

Evidence matrix, aspect by aspect

What is proven about each aspect of a delivery, depending on the means used. Every row has its own link (for example #m-addressee).

  • Presumption or legal effect set by eIDAS and recognised across the EU
  • Requirement the qualified service must ensure it (Art. 44 or the reference standards of Implementing Regulation (EU) 2025/1944), but it is not a presumption
  • Evidence only cannot be refused for being electronic, but no presumption: weighed case by case
  • Not covered this means says nothing about this aspect
AspectOrdinary emailSMTP with TLS, SPF, DKIM, DMARCSigned emailqualified electronic signature or seal, e.g. S/MIMEQualified time stampapplied to the message or attachmentRegistered deliverynon-qualified ERDS, Art. 43(1)Sooma Email Registadonon-qualified ERDS with a qualified time stampsooma.comQualified registered deliveryQERDS, Arts 43(2) and 44
Senderwho sent itNot coveredThe “From” field is declared by the sender. SPF, DKIM and DMARC authenticate the domain, not the person.Evidence onlyProves who signed the content, not who sent it.Not coveredIdentifies no one.Evidence onlyIdentification under the provider’s policy. Cannot be refused as evidence solely for not being qualified (Art. 43(1)), but no presumption.Evidence onlyValidated through an S/MIME certificate: qualified (Portuguese Bar lawyers) or advanced (Certum). No presumption of sending.PresumptionPresumption of sending by the identified sender (Art. 43(2)). Identification with a high level of confidence (Art. 44(1)(b)).
Addresseewho received itNot coveredThere is only an address. Nobody checks who is behind the mailbox.Not coveredA signature says nothing about the recipient.Not coveredIdentifies no one.Evidence onlyUnder the provider’s policy, no presumption.Not coveredThe email address is recorded; the person is not identified.PresumptionIdentification before delivery (Art. 44(1)(c)) and presumption of receipt by the identified addressee (Art. 43(2)). The reference standards of Implementing Regulation (EU) 2025/1944 call for a very high level of confidence.
Integritythe content was not changedEvidence onlyDKIM detects changes while the domain’s public key remains published. No legal presumption.PresumptionQualified seal: presumption of integrity (Art. 35(2)). Qualified signature: detecting changes is a requirement of advanced signatures (Art. 26(d)).PresumptionPresumption of integrity of the data bound to the date and time (Art. 41(2)).Evidence onlyThe definition requires protection against unauthorised alteration, but no presumption.PresumptionMulticert qualified time stamp on the message: presumption of integrity (Art. 41(2)). Sender’s S/MIME signature. Evidence sealed by Sooma (Multicert seal certificate, key in an HSM).PresumptionPresumption of integrity (Art. 43(2)). Sending and receiving secured by the provider’s advanced signature or seal (Art. 44(1)(d)).
Authorship of the contentwho is bound by what it saysNot coveredNothing links the text to a person.PresumptionQualified signature: legal effect of a handwritten signature (Art. 25(2)). Qualified seal: presumption of the origin of the data (Art. 35(2)).Not coveredA date and time are not authorship.Not coveredNot covered.Evidence onlyWith a Bar qualified certificate on a qualified device, the effect of a handwritten signature (Art. 25(2)). With an advanced certificate, no presumption.Not coveredProves that the identified sender sent the data. It is not the same as signing the content.
Date and time of sendingNot coveredThe “Date” header is written by the sender’s software. “Received” headers are technical server logs.Not coveredThe signing time is declared by the signer. Without a time stamp it is not reliable.PresumptionPresumption that the date and time are accurate: proves the data existed at that moment, not that it was sent (Art. 41(2); Art. 3, point 33).Evidence onlyPer the provider’s records.Evidence onlySubmission evidence with a qualified time stamp: the time is presumed accurate (Art. 41(2)), but the sending itself is not presumed.PresumptionPresumption that the date and time of sending are accurate (Art. 43(2)), indicated by a qualified time stamp (Art. 44(1)(f)).
Date and time of receiptNot coveredRead receipts are optional and controlled by the recipient.Not coveredNot covered.Not coveredOnly if the recipient applies the stamp, and then it proves existence, not receipt.Evidence onlyPer the provider’s records.Evidence onlyDelivery evidence with a qualified time stamp: the time is presumed accurate, the receipt is not.PresumptionPresumption that the date and time of receipt are accurate (Art. 43(2)), with a qualified time stamp (Art. 44(1)(f)).
Proof of deliveryit reached the addresseeNot coveredA “250 OK” from the receiving server only proves that server accepted the message, not that the addressee received it.Not coveredNot covered.Not coveredNot covered.Evidence onlyProof of sending and receiving is part of the service definition (Art. 3, point 36), but without a presumption.Evidence onlyEvidence sealed by Sooma of delivery to the destination server; of delivery to the mailbox or collection where the flow allows. Cannot be refused solely for not being qualified (Art. 43(1)); no presumption.PresumptionPresumption of receipt by the identified addressee. eIDAS does not define the moment of receipt; ETSI EN 319 522 evidence records the event that occurred: content made available in the service (consignment) or handed over to the recipient’s application (handover).
Refusal or not collectedNot coveredDoes not exist.Not coveredNot covered.Not coveredNot covered.Evidence onlyIf the service records it.Evidence onlyEvidence of non-delivery: refusal, bounce or failure.Evidence onlyETSI EN 319 522 provides evidence for acceptance, rejection and expiry. The legal effect of refusing or not collecting depends on the applicable law, not on eIDAS.
Changes in transitformat conversion, anti-virusNot coveredServers and filters can change the message without telling anyone.Evidence onlyYou can detect that something changed, but not who changed it or why.Evidence onlyDetects changes made after the stamp.Evidence onlyPer the provider’s policy.Evidence onlyThe S/MIME signature and the time stamp make any change detectable.RequirementAny change needed for sending or receiving must be clearly indicated to both parties (Art. 44(1)(e)) and dated with a qualified time stamp (point (f)).
Reading the contentthe addressee opened and read itNot coveredRead receipts and tracking pixels are not reliable evidence.Not coveredNot covered.Not coveredNot covered.Evidence onlySome services log access.Evidence onlyWhen the addressee collects the message, collection is recorded; reading is not.Evidence onlyThe presumption covers receipt, not reading. Some services log access to the content (optional evidence in ETSI EN 319 522), but that is not covered by Art. 43.
ConfidentialityNot coveredNot guaranteed: TLS between servers is usually opportunistic.Not coveredSigning does not encrypt. S/MIME can encrypt, but that is a separate operation.Not coveredNot covered.Not coveredThe definition mentions protection against loss, theft, damage or unauthorised alteration (Art. 3, point 36), not confidentiality.Not coveredTLS in transit where the destination server supports it. The TLS version used is recorded in the evidence; confidentiality is not part of what the service proves.RequirementProvided for in the reference standards of Implementing Regulation (EU) 2025/1944 while the content is handled by the service (ETSI EN 319 521, REQ-ERDS-5.1.1-01). Not part of the presumption.
Recognition in other Member StatesEvidence onlyCannot be refused solely for being electronic (Art. 46).PresumptionArt. 24a(1).PresumptionArt. 24a(6).Evidence onlyCannot be refused solely for not being qualified (Art. 43(1)).Evidence onlyCannot be refused solely for not being qualified (Art. 43(1)); the qualified time stamp is recognised across the EU (Art. 24a(6)).PresumptionArt. 24a(8).
Who keeps the evidenceEvidence onlyEach party keeps its own copy. Server logs belong to the email providers and are deleted under their policies.Evidence onlyThe signed document is the evidence. To validate it years from now, use qualified preservation (Art. 34) or qualified electronic archiving (Art. 45i).Evidence onlyThe stamp travels with the data.Evidence onlyPer the contract.Evidence onlySooma keeps the evidence and makes it available to the parties, for the period in the service policy.RequirementUnder the reference standards, the provider makes the evidence available to legitimate parties (REQ-ERDS-5.4.1-06) and archives it or its digests (REQ-ERDS-5.4.1-07).

Anatomy of a qualified delivery

The steps of a QERDS delivery, the Art. 44 requirement each one meets, and the evidence defined in ETSI EN 319 522, the standard referenced by Implementing Regulation (EU) 2025/1944. Evidence names are those of the standard; not every service uses all of them.

  1. 1

    Sender identification Art. 44(1)(b)

    Art. 44 requires identification of the sender with a high level of confidence. The reference standards of Implementing Regulation (EU) 2025/1944 accept, among others: physical presence, the European Digital Identity Wallet, a notified eID means at level substantial issued after physical presence, or an advanced signature or seal certificate issued under NCP. The identity is bound to an authentication means (for example two-factor, the wallet or mutual TLS).

  2. 2

    Submission Art. 44(1)(d) and (f)

    The sender hands the message and attachments to its provider. eIDAS does not define the moment of sending; in ETSI EN 319 522 it is the submission acceptance, and the date and time go into a qualified time stamp.

    ETSI EN 319 522 evidence: SubmissionAcceptanceSubmissionRejection

  3. 3

    Relay between providers Art. 44(1), last subparagraph

    In the four-corner model the sender’s provider relays the message to the recipient’s provider. Points (a) to (f) apply to every qualified provider involved. Providers may agree on interoperability between their services (Art. 44(2a)).

    ETSI EN 319 522 evidence: RelayAcceptanceRelayRejectionRelayFailure

  4. 4

    Addressee identification Art. 44(1)(c)

    Before delivery the provider identifies the addressee. The reference standards of Implementing Regulation (EU) 2025/1944 call for a very high level of confidence and accept, among others: physical presence, eID at level high, the European Digital Identity Wallet, or a qualified signature or seal certificate.

  5. 5

    Notice and acceptance (optional)

    The addressee may be told a message is waiting and, once authenticated, accept or reject it. If they do not respond in time, the expiry is recorded too.

    ETSI EN 319 522 evidence: NotificationForAcceptanceConsignmentAcceptanceConsignmentRejectionAcceptanceRejectionExpiry

  6. 6

    Consignment and handover Art. 43(2)

    The content is made available to the addressee inside the service (consignment) and/or handed over to their application (handover). eIDAS does not define the moment of receipt; the evidence records which of these events occurred and when.

    ETSI EN 319 522 evidence: ContentConsignmentContentHandoverContentConsignmentFailureContentHandoverFailure

  7. 7

    Necessary changes Art. 44(1)(e)

    If the content must be changed to be sent or received (for example a format conversion), the change is clearly indicated to both parties, with date and time.

  8. 8

    Evidence Art. 44(1)(d) and (f)

    The provider issues evidence of the delivery events and makes it available to the parties (REQ-ERDS-5.4.1-06). Sending and receiving are secured by the provider’s advanced signature or seal, and sending, receipt and any changes are dated with a qualified time stamp.

    ETSI EN 319 522 evidence: REQ-ERDS-5.4.1-06REQ-ERDS-5.4.1-07

  9. 9

    Verification, even years later Art. 22

    To rely on the presumption: validate the provider’s seal or signature and the time stamps on the evidence, and confirm that the service was on the trusted list as a qualified QERDS on the date of sending.

To check the evidence of a registered delivery you received, you can use the free validator at registado.eu.

What to use when

You need to prove that…Qualified service
a person accepted or subscribed a textQualified electronic signature (Art. 25(2))
a document came from a company or body and was not changedQualified electronic seal (Art. 35(2))
a file existed at a certain date and timeQualified electronic time stamp (Art. 41(2))
you sent something to an identified person, and when it was sent and receivedQualified electronic registered delivery (Art. 43(2))
the person subscribed the text and the other party received itQualified signature on the document + qualified registered delivery

Common misconceptions

“I signed the email with a qualified signature, so it is registered delivery.”
No. The signature proves who signed and that the content did not change. It does not prove the message was delivered, to whom, or when.
“With DKIM and DMARC my email has stronger legal value.”
They are technical domain-authentication mechanisms. They can help as evidence, but eIDAS gives them no presumption.
“A non-qualified registered delivery is worthless.”
It can serve as evidence: it cannot be refused solely for not being qualified (Art. 43(1)). But it carries no presumption, and whoever relies on it has to show it is reliable.
“QERDS proves the addressee read the message.”
It proves receipt by the identified addressee. Reading and agreeing with the content are not covered by Art. 43(2).
“QERDS signs the document for me.”
No. The evidence is sealed by the provider. If the content needs a signature, sign it before sending.
“A qualified time stamp proves when I sent it.”
It proves the data existed at that moment (Art. 3, point 33). You could have stamped it and never sent it.
“eIDAS requires registered email for notices.”
No. If a notice must take a given form, that comes from the applicable law or contract. eIDAS defines the effects of qualified registered delivery, not when it is mandatory.
“Any service presenting itself as qualified is qualified.”
Only those on a Member State’s trusted list (Art. 22). The EU trust mark (Art. 23) helps to spot them, but the list is the proof.

Standards and implementing acts

  • Implementing Regulation (EU) 2025/1944 of 29 September 2025 (OJ L, 30.9.2025), adopted under Art. 44(2) and (2b). Annex I sets the reference standards for sending and receiving data: ETSI EN 319 521 with adaptations, which refers to ETSI EN 319 522-1 and 319 522-2 (evidence), ETSI EN 319 401 and ETSI EN 319 411-1. Annex II sets the interoperability standards between providers (ETSI EN 319 522, parts 1 to 4-3).
  • Meeting the Annex I standards creates a presumption of compliance with Art. 44(1) (Art. 44(1a)). They are not the only route: the act itself allows a provider to show compliance through other practices (recital 3). Compliance of an interoperability framework is confirmed by a conformity assessment body (Art. 44(2a)).
  • For email-based services (REM — registered electronic mail), ETSI has published EN 319 531 and EN 319 532.
  • Identification in the reference standards is asymmetric: for the sender, “appropriate means” (Art. 44(1)(b) asks for a high level of confidence); for the addressee, a very high level of confidence.

This guide is informational and is not legal advice. Quotations are from Regulation (EU) No 910/2014, consolidated version of 18.10.2024, and from Implementing Regulation (EU) 2025/1944.