What can timestamps in an email header tell me?¶
title: What can timestamps in an email header tell me? subtitle: They can help reconstruct when systems handled the message, but they don’t all describe the same event or carry the same weight. slug: what-can-timestamps-in-an-email-header-tell-me series: email-evidence section: technical-interpretation card_type: question_card pathway_order: 20 section_order: 7 status: draft public_safe: true video_ready: true word_count: 656 estimated_read_time_seconds: 271 audiences: - investigator - supervisor - fraud and compliance practitioner tags: - email evidence - timestamps - timezones - Received - timeline sources: - title: 'RFC 5321: Simple Mail Transfer Protocol' url: https://www.rfc-editor.org/info/rfc5321/ - title: 'RFC 5322: Internet Message Format' url: https://www.rfc-editor.org/info/rfc5322/ - title: 'Microsoft Learn: Message trace in Exchange Online' url: https://learn.microsoft.com/en-us/exchange/monitoring/trace-an-email-message/message-trace-modern-eac
What can timestamps in an email header tell me?¶
They can help reconstruct when systems handled the message, but they don’t all describe the same event or carry the same weight.
Script¶
An email header may contain several dates and times.
They don’t all record the same event.
The visible Date field usually represents the time the sender’s software says the message was created or submitted.
Each Received line may contain the time a mail server says it accepted the message from the previous system.
The recipient’s mailbox may also record a received or internal delivery time.
Provider message trace can add another timeline showing when the service received, processed, filtered, redirected or delivered the message.
These times can help reconstruct the journey.
But first you need to ask:
Which system created this timestamp, and what event was it recording?
The main Date field is part of the message created by the sender’s side.
It may be correct.
It may also reflect a device with the wrong clock, an incorrect timezone, a manually altered value, a delayed submission or a message created earlier and sent later.
Don’t treat it as the final answer simply because it is the date shown most prominently in the email client.
Received timestamps are different.
Each receiving server normally adds its own line when it accepts the message.
Within the trusted part of the chain, those timestamps can help show when the message moved from one server to another.
Work from the recipient’s trusted infrastructure backwards.
Convert the times to a common timezone before comparing them.
Keep the original offset as well.
A timestamp such as 10:15 with a plus or minus offset may represent the same moment as a very different-looking local time elsewhere in the chain.
Expect some imperfections.
Server clocks can be wrong.
Systems may queue a message.
Malware scanning, attachment processing, greylisting, temporary delivery failures or service outages can create genuine delays.
A message generated automatically may sit in an application queue before reaching the first mail server.
A gateway may receive and later resend it.
A mobile device may prepare a draft offline and submit it only after reconnecting.
So a gap between timestamps doesn’t automatically show tampering.
It may show delay, queuing or movement through an indirect route.
Equally, an impossible sequence deserves attention.
If a lower, supposedly earlier server records a time after the recipient’s trusted provider says it received the message, one of several things may be wrong:
the lower line may be untrusted or fabricated;
a server clock may be inaccurate;
a timezone may have been misread;
or the header may have been altered or transformed.
Use the trust boundary before using the arithmetic.
The most reliable timeline usually comes from combining:
the complete original header;
the recipient provider’s message trace;
the mailbox received time;
the sender provider’s records where available;
account activity;
and relevant device evidence.
Be precise about the stage.
“The message’s Date field states that it was created at this time” is different from:
“The recipient’s provider accepted the message at this time.”
And that is different again from:
“The recipient opened the message at this time.”
The header usually won’t prove when a human read it.
You may need mailbox audit, read-receipt, application or endpoint records for that question.
The common mistake is to choose one timestamp and call it “the time the email was sent”.
Email has several stages: composition, submission, transfer, receipt, delivery and access.
Different systems record different stages.
Another mistake is to ignore the timezone and compare local clock values directly.
Preserve the original timestamp and offset, then normalise the timeline to UTC or another agreed timezone for analysis.
A good timeline states both the event and the source:
“The sender-supplied Date field records this time.”
“The first trusted receiving server accepted the message at this time.”
“The provider delivered it to the mailbox at this time.”
That shows the sequence without pretending that every clock is equally reliable.
Email timestamps are useful because they show the message moving through systems.
They become misleading when the event, timezone and system behind them are left out.
Key takeaway
Treat each timestamp as a record made by a particular system about a particular stage of the message journey.
Related questions¶
- Which Received line can I trust?
- What can a Message-ID tell me?
- Why might the original sender’s IP address not appear?
- How do I preserve an email properly?
Source notes¶
- RFC 5321: Simple Mail Transfer Protocol
- RFC 5322: Internet Message Format
- Microsoft Learn: Message trace in Exchange Online