Retention Policy

A retention policy in Microsoft Purview keeps content for a defined period and, optionally, deletes it at the end. Policies apply across Microsoft 365 workloads — Exchange mailboxes, SharePoint sites, OneDrive accounts, Teams chats and channel messages, Yammer/Viva Engage — and can be adaptive (auto-scoped by Entra ID attributes) or static (manually scoped). They override user delete actions: content stays in a hidden preservation hold and is recoverable until the retention period expires. Retention policies are the foundation of records management, regulatory compliance, and resilience against accidental or malicious deletion in Microsoft 365.

Retain, delete, or both

A policy can be configured to retain only (keep content for N years/months regardless of user deletion, with no automatic deletion afterward — the content simply becomes subject to normal deletion again once the period ends), retain then delete (keep for the period, then permanently delete it — the pattern used for genuine "we're not allowed to keep this longer than X" regulatory requirements), or delete only (no retention guarantee, just an automatic cleanup after N days/years — used for reducing storage and stale-data risk rather than for compliance preservation). The distinction matters because "retain then delete" is a genuine, unrecoverable deletion at the end of the period — it isn't a safety net, it's an enforced expiry.

Worked example

A company operating under a regulation requiring emails be kept for at least seven years, but not indefinitely, applies a retain then delete policy scoped to all Exchange mailboxes: seven years from the item's creation date, then permanent deletion. During those seven years, even if an employee deletes an email from their own mailbox, the message is preserved in a hidden recoverable state the retention policy maintains — a compliance search can still surface it, and it isn't actually gone until the policy's own deletion trigger fires at the seven-year mark. A separate department handling active litigation additionally needs specific mailboxes to survive indefinitely regardless of the retention policy's schedule; that's handled with an eDiscovery hold, which layered on top of (and takes precedence over) the retention policy's own deletion timer for those specific mailboxes.

Adaptive scope vs static scope

A static scope lists exactly which mailboxes, sites, or accounts a policy applies to — simple, but requires manual maintenance as the organisation changes (new hires, departmental moves, org restructuring). An adaptive scope instead defines membership by a live query over Entra ID attributes (department, country, job title) or SharePoint site properties, so the policy's actual coverage updates automatically as people join, leave, or move between departments — the standard recommendation for any retention policy expected to apply broadly and durably rather than to a fixed, known list of mailboxes.

Common pitfalls

The most consequential mistake is applying a retain then delete policy without understanding that it is a genuine, automatic, unrecoverable deletion once the period ends — organisations occasionally discover this only when content they assumed was "backed up somewhere" or "surely still exists" turns out to have been deleted exactly as configured years earlier. The second is scope conflicts: when multiple retention policies and holds apply to the same content with different outcomes, Purview follows a defined precedence (the longest retain period wins over a shorter delete-triggering one, and any hold wins over an automatic deletion) — but a tenant with many overlapping policies authored by different teams over time can find it genuinely hard to predict, without checking, what will actually happen to a given piece of content and when.