Microsoft 365's Default Retention Settings, and Why Most Admins Never Change Them

The defaults were never meant to be your policy. They were meant to be a starting point.

Aug 2, 2026

Ask most Microsoft 365 admins what their organization's retention policy is, and you'll often get a pause. Not because they don't care, but because the defaults were set up once, during initial rollout, and haven't been revisited since. That gap is worth closing, because the defaults were never meant to be a final answer.

Retention Policies vs. Retention Labels

Microsoft 365 gives you two different tools, and conflating them is where most confusion starts. A retention policy applies the same setting to everything in a location, a mailbox, a SharePoint site, at once. A retention label applies settings at the individual item level, a specific document or email, which lets different content in the same location follow different rules. Most companies start with policies because they're simpler to configure, and never add labels for the exceptions that actually need them.

The Principle Most Admins Don't Know

When content is subject to more than one retention setting, Microsoft applies two consistent rules to resolve the conflict: retention always wins over deletion, and the longest retention period wins. In practice, this means if one policy says delete after three years and a label says retain for five, the content survives for five years regardless of which setting was configured "on top." Most admins assume the most recently applied setting wins. It doesn't.

Why the Defaults Stay Untouched

Retention configuration takes real decision-making, legal input on what needs to be kept and for how long, which most IT teams don't have sitting in front of them during initial setup. So a reasonable-sounding default gets applied and left alone. Meanwhile, Microsoft keeps adding new locations that retention policies can cover, Teams chats, Copilot interactions, other AI app conversations, and those new locations don't automatically inherit the thinking that went into the original policy. They just sit there, often uncovered, until someone asks.

What to Actually Check

Three things worth confirming, even if you think your retention setup is fine:

Whether a policy exists at all for every location you actually use, not just the ones that existed when the policy was first written
Whether Copilot and other AI app interactions are covered, this is a newer addition and easy to miss
Whether any retention labels in use could override the policy's intended outcome at the item level, since label-based deletion always takes precedence over policy-based deletion when both apply

Final Thoughts

A retention setting that made sense during onboarding two or three years ago is not the same as a retention policy that reflects what your organization actually needs to keep today. The defaults are a starting point, not a decision, and most organisations never got around to making the decision at all.

References