Most Microsoft 365 tenants I look at have both retention policies and retention labels configured. Usually set up by different people at different times, with something like “applied for legal” in the ticket notes. Nobody documented which one wins.
That’s a governance problem. When your client’s solicitor asks why a document that should have been kept for seven years was deleted after three, “we had both configured” isn’t an answer.
Here’s what cuts through all of it: preserve always beats delete.
If any retention setting — policy or label — says retain, the content stays. A delete-only cleanup policy cannot overrule a retain policy. That’s the first principle of retention in Microsoft Purview, and it’s the one rule worth tattooing on your brain before you touch anything else.
What a retention policy does and what a label does, really
A retention policy is a net cast over an entire location. All Exchange mailboxes. All SharePoint sites. All Teams messages. You configure it once and it runs silently in the background. Users don’t see it and can’t override it.
A retention label is a tag applied to a specific item — a document, a folder, an email thread. Item-level control, which means exceptions. A label can be applied manually by a user, or automatically via content inspection rules.
They’re not competing tools. They’re two layers of the same system.
Microsoft’s overview puts it plainly: use a policy when everything in a location should be treated the same, use a label when you need item-level exceptions. Most mature tenants use both — a policy as the floor, labels as the ceiling.
Step-by-Step: Creating and publishing a retention label
Setting up a retention policy is straightforward: Purview portal > Solutions > Data Lifecycle Management > Policies > Retention policies > New. Labels take a few more steps because you create them first, then publish them separately.
Open the Purview portal and navigate to Labels
Go to Solutions > Data Lifecycle Management > Labels and select Create a label.
Name it and set the retention action
Give it a meaningful name — Contracts – Retain 7 Years is better than Label 3. Set the retention period and what happens at the end: retain only, delete after retention, or retain then delete. If the item needs to be declared a record, tick that here — it adds immutability.
Publish via a label policy
Labels don’t apply themselves. Go to Label policies > Publish labels, choose your label, and set the locations (SharePoint, OneDrive, Exchange). This makes the label available for users to apply manually in those apps.
Set up auto-apply
For most SMB clients, relying on users to apply labels manually doesn’t work. They won’t. Back in Label policies, choose Auto-apply a label, set your content condition — keywords, sensitive information types, or a trainable classifier — select the label, and let Purview do the tagging.
Allow up to seven days for labels to propagate to SharePoint and OneDrive. Don’t test immediately and assume it’s broken.
What actually happens when a policy and a label disagree
Say you have an org-wide Exchange retention policy that keeps email for three years and then deletes. And a specific retention label on a contract thread that says retain for seven years.
Which wins?
The label wins. Because it specifies the longer retention period (Principle 2: longest retention wins), and because a label is explicit — a deliberate decision about a specific item, not a blanket setting over a location (Principle 3: explicit beats implicit).
The old thinking: “We have a seven-year legal hold… somewhere. I think.”
The new reality: You can show exactly which items carry which label, when they expire, and prove it via the Purview content explorer.
A delete-only policy can only affect content that has no retain setting at all. It cannot shorten a label’s retention period. It cannot override a retain policy. Preserve always wins.
The MSP angle: adaptive scopes
Adaptive scopes are the part of retention most MSPs haven’t touched — and they make multi-tenant governance dramatically simpler.
Instead of pointing a policy at a static list of sites or mailboxes, you write a query. The scope dynamically targets whoever matches it, updated daily. A client with Finance retaining for ten years and Sales retaining for five no longer needs two separately maintained group memberships. You build two adaptive scopes off the Department attribute in Entra ID, and the policy follows the org chart automatically.
My recommendation? Start with an org-wide retention policy as your baseline. Add labels for the high-value exceptions — contracts, HR records, anything with a different period or a record declaration. Then look at adaptive scopes when you’re ready to stop maintaining static lists across every client tenant.
If you’re not showing clients that their data governance is this deliberate and this auditable, you’re leaving a genuine service conversation on the table.
Retention policies set the floor. Retention labels set the ceiling. Preserve always wins.
CIAOPS 