Retention Labels Travel, Retention Policies Don't: Closing the Gap in Microsoft 365

A copy that quietly escapes its policy

A user copies a signed contract from a SharePoint document library into their OneDrive so they can edit it offline. The library sits under a retention policy that deletes content after one year. Three years later the copy is still in OneDrive, and nobody notices until a legal team asks why it exists.

Nothing is broken. Microsoft Purview retention policies are scoped to a container — a mailbox, a SharePoint site, a OneDrive account, a Microsoft 365 group. The copy lives in a different container, so a different policy (or none) governs it. A retention label is attached to the item itself and travels with it, including across containers.

That container-versus-item distinction is the most reliable way to choose between the two mechanisms, and it is usually the first thing skipped when a tenant designs retention. This post covers where the gap bites, a configuration pattern that closes it, and what to verify before trusting it.

What each mechanism is actually scoped to

Both policies and labels can retain, delete, or retain-then-delete. The difference is where the setting lives.

Question	Retention policy	Retention label
Scope	Whole container: mailbox, site, OneDrive, group	Individual item: email, file, Teams message
Follows the item to another location	No — the destination's own policies apply	Yes — the label stays on the item
Who applies it	Administrator, tenant-wide or via adaptive scope	Published to users, auto-applied, or user-applied
Disposition review and event-based triggers	Not available	Available
Typical role	Baseline hygiene: everything ages out eventually	Records-style lifecycle for specific content

Conflicts are resolved by the documented principles of retention: retention wins over deletion, the longer retention period wins, and an explicitly applied label beats an inherited policy. That is why a broad delete-only policy will not erase something a label says to keep — useful, but also a reason a cleanup policy can appear to be doing nothing.

Where the gap shows up

• Moves and copies between containers. SharePoint to OneDrive, a mailbox to a shared mailbox, one site to another. The item lands under the destination's rules, not the source's.
• Teams. Chat and channel messages are stored in hidden Exchange mailboxes, and channel files live in SharePoint. A Teams retention policy is configured separately from Exchange email policies; covering email does not cover Teams chats.
• Records-style lifecycles. Disposition review and event-based retention — for example, starting the clock when an employee leaves — are label-only capabilities. No policy configuration produces them.

A worked example: broad cleanup plus a narrow contracts label

The pattern below is a configuration outline for a tenant that wants general collaboration content to age out after a year while contracts are kept for seven. It is a design to validate in your own tenant, not a tested transcript.

1. Check entitlements first. Auto-apply label rules, adaptive scopes, and disposition review require higher-tier compliance licensing, commonly E5 or add-ons. Confirm in the Microsoft 365 admin center under Billing > Licenses before designing around them.
2. Create the baseline policy. In the Microsoft Purview portal (compliance.microsoft.com), go to Data lifecycle management > Retention policies and create a policy scoped to all Exchange mailboxes, SharePoint sites, OneDrive accounts, and Teams locations, set to delete items older than one year with no retention period. Creating and editing policies requires the Retention Management role group in Purview; a Global Administrator can grant it.
3. Create the label. Under Data lifecycle management > Labels, create a label named Contracts set to retain for seven years, then delete.
4. Auto-apply it with a keyword query. In the label's auto-apply rule, scope it to the relevant SharePoint sites and use a KQL query such as:

FileName:contract* OR "master services agreement" OR "statement of work"

Before enabling enforcement, run the same query in Content search or use the rule's simulation mode to see exactly which items match. A query that is too broad will silently stamp a seven-year retention obligation onto ordinary documents. Then publish the label through a label policy to a small pilot group rather than the whole tenant.

Verification and the limits to plan around

• Policy status. In Purview, the retention policy and label lists show distribution status per location. An item's compliance details, available from the item's menu in SharePoint or Outlook, show which label and policy apply.
• Preservation. Delete a retained test file in a test site and confirm a copy appears in that site's Preservation Hold library, visible to site collection administrators under Site contents.
• Timing. Retention processing runs on backend timers, not synchronously. Deletions and label enforcement can take days, so do not promise immediate compliance effects.
• Storage. Preserved copies in the Preservation Hold library count against the site's storage quota. A retention design can therefore surface as a quota problem before it surfaces as a compliance win.
• Propagation. Published labels take time to reach user clients. Pilot before tenant-wide rollout.

The decision rule

Ask two questions about the content. Does it move between containers? Does its lifecycle depend on an event or a review step? If the answer to either is yes, you need a label. If the content stays put and you only need a baseline where everything eventually gets cleaned up, a policy is simpler and requires no user or auto-apply logic.

Most tenants end up with both, which is fine — as long as the broad policy is understood as hygiene, not as the control that protects the records that matter. Verify licensing, run the query in simulation, and check the Preservation Hold library before widening scope.

Behavior described reflects Microsoft Purview retention configuration through the compliance portal. Feature availability and licensing change; confirm the specific capabilities in your own tenant before relying on them.