How Long Microsoft Teams Keeps Message History
There's no fixed number. Microsoft doesn't put an expiration date on a Teams chat or channel message by default: it sits in a hidden mailbox folder until an admin-configured retention policy says otherwise, and if no policy targets that chat or channel, nothing on Microsoft's end deletes it at all. Microsoft's own documentation on Teams retention is direct about this. Retention policies are what retain Teams messages, delete them, or both, and without one configured for a given location, the message just stays where it landed.
That means the honest answer to "how long are my Teams messages kept" isn't a Microsoft-published number. It's "however long your tenant's admin configured Purview to keep them," and that number can be seven years, thirty days, or indefinite, set independently for chats and for channel messages. In a 1:1 or group chat, two people in the same conversation can even be on different clocks, because Teams keeps a separate copy of every chat message in each participant's own mailbox, subject to whatever policy their own tenant applies to it. Shared channels don't work that way, and mixing the two up is where most of the confusion starts.
Where the message lives
Retention policies for Teams target two locations: Teams chats and Teams channel messages, and the mailbox behind each one is different depending on the message type. Microsoft's retention documentation lists the mailbox types by name: a 1:1 or group chat message is copied into a hidden folder in a UserMailbox, one per person in the chat. A standard channel message goes into a GroupMailbox tied to the parent team. A shared channel message goes somewhere else entirely: a SubstrateGroup mailbox created specifically for that channel, not the parent team's GroupMailbox. Private channel messages are moving into that same GroupMailbox as part of a 2025 migration Microsoft has documented; before the migration they lived in each member's own UserMailbox. None of this is visible to a regular user or even a Teams admin browsing the client. It's built to be read by eDiscovery tools, not by the person who sent the message.
Because chat storage is per-participant, a policy applied to your tenant only governs the copies that live in your organization's users' mailboxes. If an external contact messages you in a group chat and their tenant runs a stricter policy than yours, their copy can disappear on their schedule while yours is still sitting there untouched. Shared channels don't split that way. Microsoft's shared-channels documentation is explicit that a shared channel has one retention policy, inherited from the parent team that hosts it: "Admins can apply a retention policy on a team where all channels, including shared channels, inherit the retention policy. Shared channels inherit the policy of the parent team." Every message in that channel's single SubstrateGroup mailbox is on the host team's clock, regardless of which organization posted it. If a customer messages you in a shared channel your team owns, their message isn't on their tenant's schedule. It's on yours.
What an admin can configure
A Purview retention policy for Teams chats or channel messages does one of three things: retain the content for a set period (say, seven years, for compliance), delete it after a set period with no retention step first, or retain it for a period and then delete it. Microsoft's documentation walks through the timing for each, and it's slower than the headline number suggests. A "delete after 30 days" policy doesn't mean the message vanishes on day 31. The retention clock starts a chain of internal steps, and each one adds real time before anything is unrecoverable.
The gap between "deleted" and gone
When a retention period expires, a background timer job (Microsoft states it typically runs every one to seven days) moves the message into a hidden staging folder called SubstrateHolds. It sits there for at least another day before the same timer job permanently deletes it on its next pass. Microsoft's own worked example makes the compounding delay explicit. A policy configured to delete messages after just one day can still take up to sixteen days before the message is gone from the record for good, because the one-day window is only the start of the process, not the end of it.
The same staging folder is why "deleted" and "gone" aren't the same word here. While a message sits in SubstrateHolds, it's no longer visible in the Teams client to anyone in the conversation, but it's still fully searchable by an admin running an eDiscovery search in Purview. And if a litigation hold, an eDiscovery hold, or a second retention policy on the same mailbox is also in effect, permanent deletion is suspended entirely until every applicable hold clears. A message can look gone to the people who wrote it and still be sitting in a mailbox a compliance admin can pull up in full.
The separate 21-day window for a message someone deletes themselves
This is a different clock from the retention policy one. When a person deletes their own message from the Teams client, Microsoft's Teams Export APIs documentation states that the message "can be accessed using export APIs up to 21 days from the time of deletion," independent of whether a retention policy exists. Past that window, a self-deleted message is only recoverable if a retention policy was separately holding it. The same page notes that a deleted team or channel is hard-deleted after 30 days, at which point its messages can't be retrieved through any export path.
Owen Feldt loses four months of a bug report
Alden Municipal Supply builds work-order and fleet-maintenance tracking software for city public-works departments, and Owen Feldt runs support there. Alden's biggest account, the City of Fairhaven's public works department, does almost all its day-to-day back-and-forth in a shared Teams channel rather than a ticket queue.
In April, Fairhaven's fleet supervisor, Rosalind Kemp, posted in that channel: "Truck 14's work order keeps reopening after we close it out. Started right after last week's update, only happens when the odometer field is left blank." Owen replied that he'd flag it for engineering, and the thread moved on without anyone filing it anywhere else.
In August, three more trucks started doing the same thing, and Owen went to pull up Rosalind's original report to hand engineering the full pattern. Search in the channel came up empty for anything before June. He asked Alden's IT team what happened, and learned that Alden's own retention policy for Teams chats and channel messages, set the previous year by legal after an unrelated dispute, retained messages for 90 days and then deleted them. Rosalind's April message had cleared both the retention window and the SubstrateHolds staging period months earlier, and no hold applied to that mailbox. It wasn't sitting in a compliance folder waiting for an eDiscovery search. It was permanently gone, deleted by Owen's own company's policy, not the customer's, and not anything Owen had a way to see coming.
“we need SSO before rollout”
“any update on single sign-on?”
“SSO came up twice on this call”
Linear issue, quotes attached
insight report in Notion
Claude CodeWhere the native retention picture stops working
The mechanism above is well documented, and it works exactly as designed. The gap is that the people who need old messages, support and product teams following up on a request, rarely have visibility into what policy is running, when it changes, or which mailbox a given conversation's copies live in. Owen didn't do anything wrong. He just had no way to know that a policy set by his own legal team for an unrelated reason would erase a customer's bug report before anyone connected the dots on a recurring issue. Once a retention policy permanently deletes a message and no hold applies, there's no export API, no Purview search, and no undo that gets it back.
That's the gap Modem is built to close. Modem's Microsoft Teams integration reads the channels you connect as messages land and keeps its own persistent record of who asked what, tied to the account and the person, independent of whatever retention policy is running on the underlying Teams mailbox. If Alden had that in place, Rosalind's April report would still exist as a named topic in August, whether or not the original Teams thread had already cleared its retention window. We build Modem, so weigh that against the alternatives, but the mechanism is the point. A support team's memory of what customers asked shouldn't depend on a retention setting IT configured for reasons that had nothing to do with support.
If Teams search itself is the immediate problem rather than deletion, the index behaves differently and is covered separately in why Microsoft Teams search can't find old messages. For how six purpose-built tools compare on capturing Teams feedback before it hits either wall, see the best Microsoft Teams feedback tools.
The smallest thing to do this week
Ask whoever administers your Microsoft 365 tenant, and your largest shared-channel customer's tenant if you can, what retention policy currently applies to the Teams chats and Teams channel messages locations, and write the retention period down somewhere outside Teams. That single fact turns "I assume it's all still there" into a number you can plan around, and it's the difference between noticing a policy problem in a quiet planning meeting and noticing it the day a four-month-old bug report turns out to be gone for good.
