A PEC — Italian certified email — is not an email with a badge on it. It is an envelope signed by the mail provider, and inside the envelope is the message you sent or received. Verifying a PEC means verifying that signature — and knowing exactly what it covers, because it does not cover everything your mail client shows you.

What actually lands in the mailbox

When you send a PEC, your message does not travel on its own. The sender's provider seals it in a transport envelope and signs it; the recipient's provider, when it drops the envelope into the mailbox, issues a signed receipt of its own and sends it back to the sender. Every step produces a separate message, recognisable by a subject prefix and by a dedicated header (X-Trasporto for envelopes, X-Ricevuta for receipts). The prefixes are in Italian, because that is what the system writes.

Message	Subject starts with	What it contains
Transport envelope	`POSTA CERTIFICATA:`	a text, `daticert.xml`, the original message in `postacert.eml`
Anomaly envelope	`ANOMALIA MESSAGGIO:`	a message that arrived with errors, wrapped by the provider that received it
Acceptance receipt	`ACCETTAZIONE:`	the certification data of the sending
Delivery receipt, complete	`CONSEGNA:`	certification data and the original message
… short	`CONSEGNA:`	certification data and an extract of the message
… synthetic	`CONSEGNA:`	certification data only
Notices	`AVVISO DI NON ACCETTAZIONE:`, `AVVISO DI MANCATA CONSEGNA:`…	the reason the sending failed

The three forms of delivery receipt are defined by the technical rules (Ministerial Decree of 2 November 2005). Probatio takes them into account: it looks for postacert.eml in the transport envelope, in the anomaly envelope and in the complete receipt, and does not demand it from the short and synthetic ones, which by definition do not carry the whole original.

The signature is everything

The value of a PEC rests on a single fact. Presidential Decree no. 68 of 11 February 2005, Article 9, provides that receipts are signed by the provider with an advanced electronic signature, generated automatically by the system, which makes their origin manifest and ensures their integrity and authenticity; and that the transport envelope is signed with the same kind of signature. The technical rules add that messages conform to the S/MIME standard and that the transport envelope is delivered unmodified, precisely so that the recipient can verify the certification data.

In practice the envelope is a multipart/signed: two parts, the content and the signature.

The provider's signature covers part 1 and nothing else. The headers your mail client shows at the top of the message sit outside it.

What the signature covers, and what it does not

The S/MIME signature is computed over the bytes of the first part: the covering text, daticert.xml and postacert.eml. Changing a single character in any of these files makes verification fail.

The envelope headers — From, To, Subject, Date — are not in that part. They are the lines your mail client shows at the top, and they can be rewritten without the signature noticing. That is why, when the signature is intact, the data that counts is the data in daticert.xml: sender, recipients (each marked certificato or esterno, certified or external), subject, day, time and time zone, issuing provider, message identifier.

Probatio says so explicitly in every verification, and then compares the two versions: sender, recipients, subject (with the prefix removed), date (with a five-minute tolerance between daticert.xml and the Date header), message type, provider name against the certificate. A mismatch is an amber finding, not a verdict: the signature is still good, but something between what you see and what is certified does not add up, and it needs looking at.

Why the data is read from the signed part only

Here is a simple attack. Take an authentic PEC and add, inside the multipart/signed, a third part with a second daticert.xml: different subject, different date. The original signature is not touched, and it stays cryptographically valid — it still covers part 1, which is intact.

A tool that only checks the structure and then reads the first daticert.xml it finds in the message can pass this PEC as good, with the forged data. It happened in the tests run while the module was being built, with a checker of exactly that kind.

Probatio does the opposite. It verifies the signature first; then it takes the exact bytes covered by the signature and parses them on their own, and it is from there — and only from there — that it reads daticert.xml and postacert.eml. Finally it compares the digests of what the message shows with those of what was signed. An extra part in the multipart/signed, or a displayed file that differs from the signed one, is a red check that makes the PEC invalid, naming the parts that are not covered.

Whose certificate is it

An intact signature says the content has not changed since it was signed. It does not yet say who signed. For that you have to climb from the provider's certificate to a recognised authority.

For the PEC circuit that authority is AgID CA1, the certification authority of the Agency for Digital Italy which, since 20 November 2017, issues the providers' signing certificates. Probatio ships it, together with the Actalis root that issued it, both downloaded from the AgID website. The check is strict: the «AgID CA1» label is given only if the provider's certificate is signed directly by a certificate whose subject is AgID CA1, Agenzia per l'Italia Digitale — the built-in one or one carried in the envelope. Reaching the Actalis root is not enough: the same root can sit above Actalis certificates unrelated to the PEC circuit, and a certificate that reaches the root by another path turns the check red, because it is outside the PEC circuit and cannot sign a provider's envelope. If the certificate chains neither to AgID CA1 nor to the Actalis root, Probatio tries the AgID/EU trusted list it keeps in its cache: this is the normal case for PECs older than November 2017, and it is reported as information. If it is not in the list either, the check turns amber and shows the issuer.

Valid when?

This is where people often go wrong. The right question is not «is the provider's certificate valid today?» but «was it valid when the provider signed?». A PEC from 2024 signed with a certificate that expired in 2025 does not become false in 2026.

Same certificate, same PEC. Only the position of the revocation relative to the certification date changes.

Probatio takes as its reference instant the date written in daticert.xml — day, time and time zone, all inside the signed part — and checks that it falls within the certificate's validity period. If it falls outside, the check is red. If the certificate has expired today but was valid then, it is noted as information: that is the normal state of a PEC a few years old.

Then there is revocation. When the computer is online, Probatio queries the OCSP responder named in the provider's certificate. A revocation dated after the PEC does not invalidate it: when the provider signed, the certificate was good. A revocation at or before the PEC date does. The OCSP request is made by the app's main process, because the message itself is parsed in an isolated subprocess that has no network access.

The rewritten Message-ID

A detail that confuses anyone comparing messages by hand. daticert.xml carries two identifiers: identificativo, assigned by the provider, and msgid, the Message-ID of the original message. In the envelope, the original is referenced by the X-Riferimento-Message-ID header.

Real files come in two forms, both consistent. In the first, the original message in postacert.eml keeps its own Message-ID, which matches msgid. In the second, the provider has replaced it with the PEC identifier and moved the original one into X-Riferimento-Message-ID. Probatio accepts the second form only if both matches hold — Message-ID equal to identificativo and X-Riferimento-Message-ID equal to msgid — and says so in the check detail. One match alone is not enough.

PECs saved in other formats

Outlook and MSG files. A .msg does not hold the message as it arrived: Outlook breaks it down into properties. For a signed message, though, Outlook usually keeps the whole S/MIME envelope as an smime.p7m attachment (message class IPM.Note.SMIME.MultipartSigned). In that case Probatio rebuilds the message byte for byte and the PEC verifies as it would on the original. If the envelope is missing, the content can still be read but the provider's signature is gone: the outcome is cannot be verified — not «valid», and not «forged» either — and Probatio asks for the original .eml downloaded from the mailbox. The file formats have a guide of their own: EML, EMLX and MSG.

Apple Mail and bare LF. The S/MIME signature is computed over the canonical MIME form, where every line ends with CRLF. Many programs — Apple Mail, Unix tools — save the message with bare LF line endings. Probatio first verifies the bytes as they are; if the digest does not match, it retries on the canonical CRLF form and, if it matches there, says so. The comparisons between displayed and signed parts are made in the same form too: otherwise every PEC saved by Apple Mail would raise a false alarm.

postacert.eml on its own. Whoever extracts the original message from the envelope and forwards it hands over an ordinary email: no X-Trasporto, no daticert.xml, no provider signature. Probatio answers «not a PEC» and explains why.

The four outcomes

Outcome	When
Valid PEC	provider signature intact and every check passed
Valid PEC, with findings	signature intact, but at least one consistency check in amber (headers differing from `daticert.xml`, certificate chained neither to AgID CA1 nor to the list, opaque envelope, more than one signer)
Invalid PEC	invalid signature, content modified after signing, uncovered parts, certificate outside the PEC circuit (it reaches the Actalis root but is not issued by AgID CA1), certificate outside its validity or revoked at the PEC date, `daticert.xml` or `postacert.eml` missing where expected
PEC cannot be verified	no readable provider signature: unsigned message, MSG saved without the envelope, or an S/MIME-encrypted envelope — a PEC envelope is not encrypted, so that file is not the envelope as the provider delivered it

There is a fifth case, which is not an outcome of the verification: not a PEC, when the message has neither the PEC headers nor the certification data.

What the law says, briefly

Presidential Decree 68/2005 (Article 4(6)) provides that the validity of transmission and receipt is attested, respectively, by the acceptance receipt and by the delivery receipt. Article 6(3) adds that the delivery receipt proves the message reached the address declared by the recipient and certifies when; Article 6(5), that it is issued regardless of whether the message has been read. The Italian Digital Administration Code (CAD), Article 48(3), makes the date and time of transmission and receipt enforceable against third parties if they comply with Decree 68/2005 and its technical rules. Article 48 itself is due to be repealed once the decree aligning PEC with the eIDAS Regulation is adopted (Legislative Decree 217/2017, Article 65(7)). The legal value comes from the law; the technical verification only tells you whether the envelope in your hands is the one the provider signed.

Limits

There is one built-in anchor: AgID CA1 in its 2025 reissue, accompanied by the Actalis root, which only serves to complete its chain. For certificates from other CAs — older PECs — verification depends on the AgID/EU trusted list in the cache. If the list has never been downloaded, the certificate chains to nothing and the outcome drops to «valid, with findings».
Revocation needs the network and is checked only via OCSP, on the provider's certificate. Offline, the check is missing and the outcome does not make up for it: the report shows it. CRLs are not consulted.
The reference instant is written by the provider itself in daticert.xml. Probatio checks that it is covered by the signature; it does not compare it with an independent time source.
The official index of PEC providers is not public and is not queried: Probatio cannot tell whether a provider was registered on a given date.
An MSG without the S/MIME envelope stays unverifiable: a signature lost on saving cannot be rebuilt.

In practice

Keep the original file, downloaded from the mailbox as .eml. Printouts, forwards and conversions are the first things to lose the signature.
Verify with the computer online, so that the report includes the revocation status of the provider's certificate.
Quote the data from daticert.xml, not the envelope headers: it is the only data the signature covers.
Read the amber findings one by one. They do not invalidate the PEC, but in a report they need explaining.
For the general mechanics of signature verification — chain, validity, revocation — see Verifying a digital signature. The module is described on the PEC verification page.

A PEC is worth as much as the provider's signature and as much as what that signature covers. The rest — the headers, the way your mail client displays it — is presentation. Verifying it means telling the two apart.