Saved Email Shows the Wrong Date in SharePoint: How to Keep Sent/Received Date
You save an email from Outlook to SharePoint. Then someone opens the library and says, “Why is this dated today? This email was sent last week.”
It is a common point of confusion.
What SharePoint is often showing by default is the document’s library timestamp, not the email’s original Sent or Received value. In Microsoft 365, different content types can carry different date fields, and Microsoft’s own eDiscovery documentation calls out that emails, documents, and Teams messages may have separate fields such as Created, Last Modified, Received, and Sent.
That matters because for email records, the “right date” is usually not “when the file landed in SharePoint.” It is “when the message was sent” or “when it was received.”
So the real fix is usually not to fight SharePoint’s system columns. It is to capture and use Sent/Received as dedicated metadata.
Why the date looks wrong in the first place
When a file is uploaded into SharePoint or OneDrive, the built-in Created and Modified values generally reflect when the item was stored or updated in the library, not the file’s original historical date from elsewhere. Microsoft community guidance reflects this behavior, and it is exactly why teams often see “today’s” date on older content that has just been saved or migrated.
So if you save an Outlook email into SharePoint as a file or item, SharePoint is doing what it normally does for documents:
- Created = when the item was created in the library
- Modified = when the item was last updated in the library
That is useful for document management. It is just not the same thing as the email’s original timeline.
The date you need depends on the use case
For email-heavy teams, there are usually at least three different date questions in play:
- When was the email sent?
- When was the email received?
- When was the saved record created or updated in SharePoint?
All three can be valid. The problem starts when teams expect one field to answer all three questions.
Microsoft’s metadata guidance also reinforces the broader point here: SharePoint metadata is there to help classify and manage content in a way that matches business meaning, not just storage mechanics.
For email records, Sent Date and Received Date are often business-critical metadata. Created and Modified are still useful, but they describe the SharePoint item, not the original communication event.
The practical fix: keep Sent and Received as separate columns
The cleanest approach is usually this:
- Keep SharePoint’s system columns such as Created and Modified.
- Add separate date/time metadata columns for:
- Sent Date
- Received Date
- Populate those fields from the original email properties at the time the email is saved.
- Use those custom fields in views, sorting, filtering, and governance.
This gives you two benefits at once:
- You preserve SharePoint’s own library history.
- You also preserve the email’s original timeline.
And that is usually what users actually want when they say, “the saved email shows the wrong date.”
Do not try to “repurpose” Created and Modified
This is one of the most common mistakes.
Teams sometimes try to treat SharePoint’s Created field as the email’s sent date, or Modified as the received date. That creates confusion later because those fields still behave like SharePoint system fields. If the item is updated, the Modified value can change again. If the email is saved today, Created will still reflect today’s save event in the library. Microsoft documentation for SharePoint connectors also shows that SharePoint distinguishes between file metadata and the values stored in the library’s columns, which is another reminder that system/library behavior and business metadata are not the same thing.
In other words, let SharePoint keep its own audit-friendly timestamps. Just do not rely on them as your only email dates.
How to make the right date visible to users
Once you have proper Sent Date and Received Date columns, the next step is simple but important: make those fields visible in the library view.
SharePoint views let you show and hide columns, and save sorting and filtering choices for a library. You can also sort by a chosen column and create saved views around that logic.
So instead of leaving users to stare at Created and assume it is the email date, you can:
- show Sent Date in the default view,
- show Received Date where relevant,
- sort by Sent Date instead of Created,
- filter by Received Date for operational or compliance reviews,
- keep Created and Modified available, but not as the main business date fields.
That one change often removes a lot of user confusion.
Metadata is what makes email records workable at scale
This is really a metadata design issue more than a date issue.
If a team is saving only raw email files into SharePoint and relying on filename plus default system columns, they will eventually hit the same problems:
- wrong-looking dates,
- hard-to-filter records,
- weak search precision,
- poor separation between document history and email history.
When email properties are captured as metadata instead, SharePoint becomes much easier to work with. Microsoft’s managed metadata guidance is built around this principle: metadata helps classify, find, and manage content more effectively.
For email records, that usually means capturing at least:
- Sent Date
- Received Date
- From
- To
- Subject
- Matter / Project / Client reference where relevant
This is also where broader email records strategy starts to improve. If you want more ideas on metadata-driven filing, retention, and Outlook-to-SharePoint governance, it is worth exploring our resource on Auto filing emails from Outlook to Sharepoint
Understand “wrong date” vs “wrong display”
Sometimes the issue is not that the wrong value was captured. It is that the wrong value is being shown.
For example:
- the library default view is showing Created instead of Sent Date
- a saved view is sorting by Modified
- a formatted column changes how the date looks without changing the actual stored value
Microsoft’s column-formatting guidance makes this distinction explicit: formatting changes how a field is displayed, not the underlying data itself.
So if users say the date looks wrong, the first check should be:
- Which field are they actually looking at?
- Is that the field the business really wants to use?
A better operating model for saved emails
A sensible setup for most SharePoint email libraries looks like this:
- Created / Modified stay in place as SharePoint system fields
- Sent Date / Received Date are added as explicit business metadata
- default library views use Sent Date or Received Date as appropriate
- filtering and sorting are built around those fields
- retention, reporting, or legal review processes use the right date field for the job
This is cleaner, easier to explain, and much more defensible than trying to make one generic date do everything.
Final thoughts
If a saved email in SharePoint is showing the “wrong” date, the problem is usually not that SharePoint is broken. It is that SharePoint is showing its own document-centric dates, while the business is expecting email-centric dates.
The fix is straightforward:
- keep SharePoint’s system timestamps,
- capture the original Sent and Received values as metadata,
- and use those fields in views, sorting, and governance.
That gives users the date they actually care about, while still preserving SharePoint’s own record of when the item was saved or changed.
And if you want to make that capture process easier inside Outlook, Konnect eMail helps teams save emails directly to SharePoint while preserving useful email properties as metadata, so the right date does not get lost in the first place.
