Skip to content
EML-004 Email Evidence

Could the email content have been altered after delivery?

title: Could the email content have been altered after delivery? subtitle: The original mailbox message may be stable, while screenshots, forwarded copies, exports and local files can be changed or recreated. slug: could-the-email-content-have-been-altered-after-delivery series: email-evidence section: evidential-limits-and-corroboration card_type: question_card pathway_order: 40 section_order: 6 status: draft public_safe: true video_ready: true word_count: 620 estimated_read_time_seconds: 257 audiences: - investigator - supervisor - fraud and compliance practitioner tags: - email evidence - integrity - alteration - DKIM - S/MIME sources: - title: 'Microsoft Learn: Update message' url: https://learn.microsoft.com/en-us/graph/api/message-update?view=graph-rest-1.0 - title: 'RFC 6376: DomainKeys Identified Mail (DKIM) Signatures' url: https://www.rfc-editor.org/info/rfc6376/ - title: 'RFC 8551: S/MIME Version 4.0 Message Specification' url: https://www.rfc-editor.org/info/rfc8551/ - title: 'RFC 9787: Guidance on End-to-End Email Security' url: https://www.rfc-editor.org/info/rfc9787/ - title: 'RFC 7508: Securing Header Fields with S/MIME' url: https://www.rfc-editor.org/info/rfc7508/

Could the email content have been altered after delivery?

The original mailbox message may be stable, while screenshots, forwarded copies, exports and local files can be changed or recreated.

Script

You’ve been shown an email and need to know whether the content could have changed after it was delivered.

The answer depends on what you have preserved.

A message still held in the recipient’s provider mailbox is generally a stronger source than text copied into a document, a screenshot, a forwarded version or an EML file supplied without provenance.

Mainstream mailbox systems usually treat the subject, body and recipients of a sent or received message differently from a draft.

For example, Microsoft’s normal message API permits body and subject changes only while the message is a draft. After sending, ordinary updates are generally limited to properties such as read status, flags or categories.

That supports the practical view that a delivered mailbox item isn’t normally edited in place through the standard user workflow.

But don’t turn that into an absolute claim that alteration is impossible.

A person can create a new message that looks like the original.

They can forward it and edit the quoted text.

They can copy the content into another document.

They can alter a downloaded EML or local mailbox file.

They can create a screenshot or PDF showing different content.

Messages can also be imported or inserted into mailboxes through administrative, migration or application processes.

The relevant question is whether the item you are examining is the original delivered object and whether its integrity can be supported.

Start with provenance.

Which account and folder held the message?

Who acquired it?

Was it exported directly from the provider?

Was the original left in place?

Can the Message-ID and provider identifiers be matched to message trace?

Does another recipient hold the same message?

Does the sender’s Sent item or platform record match it?

Then review cryptographic evidence.

A valid DKIM signature can support that the signed body and selected headers haven’t changed in a way that breaks the signature since the signing service created it.

But DKIM may not cover every header.

Some legitimate delivery changes can affect validation.

And DKIM identifies the signing domain rather than the human author.

S/MIME or another end-to-end digital signature can provide stronger message-integrity and origin evidence for the signed content.

Even then, check which content and headers were covered, whether the certificate was valid and trusted at the relevant time, and whether the mail client displayed the signed material correctly.

End-to-end email security standards warn that clients can mishandle or misrepresent protected MIME structures.

So a “valid signature” icon should be supported by examination of the original signed message rather than accepted from a screenshot.

Also separate message content from mailbox state.

Read or unread status, categories, flags, folder location and labels may change after delivery without altering the message body.

A message may be moved, deleted, restored or copied.

Those actions matter to the timeline but don’t necessarily change the words.

The common mistake is:

“It is in the mailbox, so it must be exactly what arrived.”

The other is:

“It was exported, so it can’t be trusted.”

A properly acquired native export, matched to provider and recipient records, may be strong evidence.

The point is to show the chain.

A careful conclusion might say:

“The native message was acquired from the recipient’s mailbox, matched to provider trace and another recipient’s copy, and its DKIM signature validates over the signed content.”

That explains why the content is treated as reliable.

If all you have is a screenshot or pasted text, say so.

It may accurately show what somebody saw.

It doesn’t, by itself, prove that the displayed content is the unchanged original delivered message.

Preserve the native source.

Match it to the provider records.

Verify any signature.

Then describe the integrity supported by that evidence, rather than assuming it.

Key takeaway

Preserve the native original and verify any signatures. A readable copy shows what it contains now, not automatically that it is the unchanged delivered message.

Source notes

Keep moving

Where this question leads

These links explain why the next page may matter, rather than presenting an undifferentiated list.