Email and certified email

An email carries almost the whole of its own journey written inside it. That is why, among digital evidence, it is one of the few kinds that can stand on its own — provided it was acquired in the right form and is read by someone who knows what the lines mean.

The message is not what you see

What a mail client displays — sender, subject, date — is the cosmetic part. Underneath is the real message, a text file containing dozens of header lines added by every system that handled it. The «From:» field is among the easiest to forge: it is written by the sender, exactly like the return address on the back of an envelope.

The lines that matter are elsewhere, and the first consequence is procedural: a printed or forwarded email loses all of it. If the message is to serve as evidence it must be preserved and exported in its original format, with headers intact. A forward is not the message: it is a new message quoting its text.

What the headers show

The route

Every server that receives the message adds a Received line at the top carrying its own name, the address of whoever handed the message over, and the time. Read from the bottom up, they reconstruct the journey. Each line is only as reliable as the server that wrote it: lines added by the recipient's own systems are trustworthy; lines further down may have been fabricated along with the rest of the message. Telling the two apart is the heart of the analysis.

Sender verification

Three mechanisms, now present on almost every seriously managed domain, leave verifiable traces in the headers.

• SPF publishes in the domain's DNS which servers are authorised to send on its behalf. The receiving server records the outcome of the check. A failure on a message claiming to come from that domain is a significant indicator.
• DKIM is a cryptographic signature applied by the sending server over a defined portion of the message. It is the strongest element: if the signature verifies, that content passed through a server authorised by the domain and the signed parts have not been altered since. If it does not verify, either the message was modified, or the signature was never there.
• DMARC ties the two to the domain the user actually sees, and tells the recipient what to do when they do not line up.

One limit is routinely overlooked: DKIM can be re-verified years later, but only for as long as the domain still publishes the key used. Keys are rotated and domains change hands — a signature that fails to verify today does not prove the message is false. It is another reason to acquire early.

Italian certified email (PEC)

PEC is a different system with rules of its own. Its evidential weight lies not in the message but in the receipts the providers generate and sign: the acceptance receipt, attesting that the sender's provider took the message in hand, and the delivery receipt, attesting that it was deposited in the recipient's mailbox.

The distinctions that matter in practice:

• Delivery attests deposit in the mailbox, not that the recipient read it. This recurs in objections about service of documents.
• The receipts are signed by the provider: that signature is verifiable, and verifying it is the first thing to do when authenticity is disputed.
• A PEC message sent to an ordinary mailbox loses the guarantees on the recipient's side, and vice versa.
• The original message travels attached to the transport envelope: that is where it must be extracted from for analysis, not from the client's display.

The framework is set by presidential decree 68 of 2005 and the Digital Administration Code, and the system is moving towards the European registered electronic delivery model under the eIDAS regulation.

The questions I answer

• Was this message sent from the domain it claims to come from?
• Is the content the original, or was it modified after sending?
• Is the stated date consistent with the timestamps of the servers it passed through?
• Is the delivery receipt genuine, and which message exactly does it relate to?
• Is the attachment the one that was actually sent?

Further reading: how to challenge the authenticity of an email →