"When did you receive this?" is the question behind a surprising share of disputes: limitation periods, notice periods, whether a client was told, whether a report existed before the incident. The honest answer is often "I think around March", and the file's date-modified is not going to help. Here is what actually proves timing, weakest to strongest.
Weak: the file's own timestamps
Created and modified dates on a file are set by the device and change when the file is copied, moved or saved. They can be edited freely. Useful as a hint, worthless as proof.
Weak: a date typed inside the document
The date on a letter proves the author typed that date. Nothing more.
Moderate: an email's headers
The sending server stamps the message, and each server it passes through adds its own timestamp. The full headers of the original message (not a forward, not a screenshot) are decent evidence of when it was sent and received. They can be forged by a determined party, but forging a chain of headers that survives scrutiny is hard, and most disputes are not with determined forgers.
Strong: a third-party system's record
When a document is uploaded to a system neither party controls the clock of, the system's upload timestamp is strong evidence of the latest time the document could have been created and the earliest it existed in that form. The strength depends on the system: was the timestamp set by the server, is the log editable by users, can the vendor attest to it. A case-management system that records uploads with server time in an audit log nobody can edit is exactly this. See what an audit trail is.
Strong: a signing or sealing event
An e-signature request records when each party verified their identity and signed, with server timestamps, and seals the document so any later change is detectable. That proves both when and what. For a document that needs to exist provably at a point in time without anyone signing it, a trusted timestamp (a cryptographic hash of the file signed by a timestamping authority) does the same job; some e-sign services apply one automatically.
Strong: a logged delivery
For proving receipt, a portal that logs when the recipient signed in (with a verified one-time code) and opened or downloaded the document beats any read receipt. The log shows the person, the time, and the action. Email read receipts, by contrast, are optional, easily disabled and prove little.
Having the strong kind by default
None of this requires effort at the moment it matters if the habit is right beforehand: documents are uploaded to the matter when created or received (server timestamp); emails are filed to the matter as received (headers intact); documents that must be proven are sent for signature or shared through the logged portal rather than attached. The dates are then already in the record, and "when did you receive this?" is answered by opening it. The wider set of habits is in the chain-of-custody checklist.
A note on backdating
The temptation to "correct" a date on a record is real and the consequence is severe: a single demonstrably altered date discredits every other date in the file. Systems that do not allow edits to timestamps protect their users from themselves. Choose them.
