How to challenge the authenticity of an email

Published on 18 August 2026 · Author: Francesco Zinghinì

The «From:» field of an email is written by whoever sends it, exactly like the return address on the back of an envelope. Anyone can write anything there. The lines that matter are elsewhere, in a part of the message that mail clients, by default, do not show.

The procedural rule that comes before everything

Before any technical consideration there is a procedural mistake that destroys most challenges: the email must be preserved and produced in its original format, with headers intact.

A printout will not do: it holds only the cosmetic part. A forward will not do: it is a new message, generated by your own client, quoting the text of the previous one and losing its original headers. Text pasted into a document will not do, for the same reason. What is needed is the message file — the extension varies with the program, but the object is always the same: a text file carrying, at the top, dozens of lines added by the systems that handled it.

If you know a message will be contested, the first thing to do is to have it acquired from the mailbox in its original format, with an integrity check. The second place to look, if the original has been lost, is the mail server's own logs: they often retain a record of transit even when the message itself is gone.

Received lines: the route

Every server that takes the message adds a Received line at the top with its own name, the network address of whoever handed it over, the protocol used and the time. The result is a stack: read from the bottom up, it reconstructs the journey from departure to arrival.

The point almost everyone misses is the differing reliability of each line. They are not equivalent, because they were not written by the same party:

Lines written by the recipient's own systems — those at the top — are as reliable as that infrastructure is. They record an event that occurred under the control of the receiving party.
Lines further down, describing the earliest hops, may have been fabricated along with the rest of the message: whoever forges a message writes whatever headers they like.

Hence the working rule: read downwards from the top for as long as the lines are verifiable, and stop where verifiability ends. The first line added by the first server one can trust is the point at which the message entered the verifiable world. Everything below it is the sender's assertion.

It is also why, when the disputed message was received by a corporate mailbox, that server's logs are worth more than the message itself.

SPF, DKIM, DMARC: what they actually establish

Three mechanisms, now active on almost every competently run domain, leave verifiable traces. It is worth understanding what each of them asserts, because they are routinely conflated.

SPF

The domain holder publishes in the naming system the list of servers authorised to send on its behalf. The receiving server compares the address the message came from with that list and records the outcome. A failure on a message claiming to come from that domain is a significant indicator. Note the limit, though: SPF checks the technical envelope sender, which is not necessarily the address shown to the user.

DKIM

This is the strongest element. The sending server applies a cryptographic signature over a defined portion of the message — typically certain headers and the body — using a private key; the corresponding public key is published in the domain's naming records. If the signature verifies, two things follow: that content passed through a server authorised by that domain, and the signed parts have not been altered since.

If the signature does not verify, there are at least three hypotheses and they must be kept apart: the message was modified; the signature was never there; or — the most insidious case — the key it was applied with is no longer published.

DMARC

It ties the other two to the domain the user actually sees, requiring the verified domain and the displayed domain to align, and instructs the recipient what to do when they do not. Its presence strengthens the weight of the other two checks.

The problem of time

DKIM verification can be repeated years later, but only for as long as the domain still publishes the key. Keys are rotated for security reasons, domains change providers, companies close. A signature that fails to verify today does not prove the message is false: it may simply no longer be verifiable. That distinction belongs in the report, because it is precisely where a hasty conclusion would be taken apart.

The practical consequence is always the same: acquire early. The evidential value of an email decays with time — not because the file changes, but because the world around it does.

Italian certified email

PEC (posta elettronica certificata) is a distinct system with rules of its own, set by presidential decree 68 of 2005 and the Digital Administration Code. Its evidential weight lies not in the message but in the receipts generated and signed by the providers.

The acceptance receipt attests that the sender's provider took the message in hand, with date and time.
The delivery receipt attests that the message was deposited in the recipient's mailbox, and contains the original message.

The distinctions that matter in practice:

Delivery attests deposit in the mailbox, not reading. This is the point that recurs in objections about service.
The receipts are signed by the provider: that signature is verifiable, and verifying it is the first thing to do when authenticity is disputed.
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.
A PEC message sent to an ordinary mailbox loses the guarantees on the recipient's side, and vice versa.

The system is moving towards the European registered electronic delivery model under the eIDAS regulation, which will bring stricter interoperability and identification rules. The questions about receipts remain, in substance, the same.

The questions to put

If you are framing a challenge, these are the questions that in my experience produce usable answers, because they are verifiable and bounded:

Was the message acquired in its original format, with headers intact?
Which is the first Received line attributable to verifiable infrastructure, and what does it attest?
Does the message carry a DKIM signature from the stated domain? Does it verify? If not, is the key still published?
Is the SPF result recorded by the receiving server?
Are the timestamps of the various hops consistent with one another and with the stated date, allowing for time zones?
Do transit records for that message exist on the receiving server?

A question framed as «whether the message is authentic» almost always yields a weaker answer than it could have.

Email and certified email: how I can help → · Back to insights