Microsoft 365 retention: Purview policies vs. retention labels — how to choose
Retention policies keep everything in a location; retention labels follow the item and can declare records. A comparison, the trade-offs, and a pilot you can validate in the Purview portal and PowerShell.
23 Oct 2025, 16:57 UTC

You need to keep (or delete) Microsoft 365 content on a schedule. Microsoft Purview offers two mechanisms — retention policies and retention labels — and picking the wrong one usually means either over-retaining everything in a site or discovering that retention didn't follow a document when it moved. The short version: policies retain at the location level and are invisible to users; labels attach to the item and travel with it. Most real deployments use both.
The decision and its constraints
Start with three questions:
- Scope: Does the rule apply to everything in a location (all mail in a mailbox, all files in a SharePoint site), or only to certain document types (contracts, invoices, HR records)?
- Mobility: Must retention survive the item being moved or copied between sites and libraries?
- Records: Do you need to formally declare items as records so they can't be edited or deleted?
If the answer to the first is "everything" and the other two are "no," a policy is enough. Anything more specific points to labels.
Comparing the supported options
| Capability | Retention policy | Retention label |
|---|---|---|
| Applies to | Whole locations: mailboxes, sites, OneDrive accounts, Teams messages | Individual items: documents, emails |
| Follows content when moved | No — retention is tied to the location | Yes — the label travels with the item |
| Visible to end users | No | Yes, in Office apps and SharePoint |
| Distinguish content types within one site | No | Yes (manual, default, or auto-apply) |
| Declare items as records | No | Yes (records and regulatory records) |
| Typical licensing | Broadly available in most business/enterprise plans | Manual labels broadly available; auto-apply and records features typically need E5-level or compliance add-ons — verify against your tenant |
Trade-offs in practice
Policies are simple but blunt. "Keep all Exchange email for 7 years" is one policy. But a policy can't treat a contract library differently from a working-drafts library inside the same site, and users get no signal that retention exists.
Labels are precise but need distribution. A label only works once it's published to the right users or locations, applied (manually, by default on a library, or auto-applied via KQL keyword queries, sensitive information types, or trainable classifiers), and given time to propagate. Publishing and policy changes are not instant — allow days, not minutes, before expecting labels to appear and take effect across workloads.
Conflicts resolve by documented precedence. Retention wins over deletion; the longest retention period wins; an explicitly applied label generally beats a policy or an inherited default label. Design with this in mind rather than discovering it during an audit.
Storage surprise: when a labeled item is edited or deleted in SharePoint or OneDrive, preserved copies go to the Preservation Hold library, which counts against site storage quota. Factor this into capacity planning.
Teams is special. Teams messages live in hidden Exchange folders and Azure-based chat services, and retention/eDiscovery behavior differs from files. If Teams is in scope, test it as its own scenario.
A concrete pilot: label plus policy, validated
A common pattern: a tenant-wide policy as a safety net, labels for the content that matters.
- In the Microsoft Purview compliance portal, create a retention policy scoped to a pilot mailbox and one pilot SharePoint site — e.g., retain for 3 years, then delete. Keep it narrow while testing.
- Create a retention label (e.g., "Contract — retain 7 years, mark as record") and publish it to the pilot site.
- Wait for propagation, then confirm the label is selectable on a document in the pilot library.
- If you plan auto-apply, create the auto-apply label policy and run it in simulation mode first. Inspect the sample of matched items to confirm your KQL query targets the intended content before enabling enforcement.
- Apply the record label to a test document and try to edit and delete it. You should see the expected block, and deleted preserved content should surface via the Preservation Hold library.
Cross-check with PowerShell
Portal status pages can lag; the Security & Compliance PowerShell module shows the actual configuration. Run these from an admin workstation with an account holding an appropriate compliance role (e.g., Retention Management):
Connect-IPPSSession
Get-RetentionCompliancePolicy -Identity "Pilot-3Year-Policy" |
Format-List Name, Enabled, Mode, ExchangeLocation, SharePointLocation
Get-RetentionComplianceRule -Policy "Pilot-3Year-Policy" | Format-List Name, RetentionDuration, RetentionComplianceActionCheck that Enabled is true, the locations match your pilot scope, and the rule's duration and action match what you set in the portal. Disconnect with Disconnect-ExchangeOnline when done. These are read-only queries, so they carry no rollback risk.
Limitations and how to verify the result
Propagation delays mean a label that "doesn't show up" today may simply not have arrived yet — re-check after 24–72 hours before troubleshooting. Licensing boundaries and portal locations change frequently in Microsoft 365, so confirm your subscription covers auto-apply and records features before designing around them. The definitive end-to-end check is behavioral: apply the label, attempt a prohibited edit or deletion, and confirm the block and Preservation Hold behavior on test content. Do that before rolling anything out broadly.
0 replies
A thoughtful contribution can make all the difference. Be the first to share one.