How to fix retention policies that were not applied

What this check looks at

Checks that Microsoft has applied every retention and retention label policy that is switched on to its locations. A policy whose distribution failed shows as on in the portal but keeps nothing in the places it did not reach.

When a retention or retention label policy is created or changed, Microsoft distributes it to every mailbox, site and account it covers. Until that finishes its status is Pending; when it cannot finish, the status becomes Error (or a timeout), and the policy is not in force in the places it did not reach, even though the portal still shows it as on.

Distribution usually fails because a location named in the policy no longer exists (a deleted site or mailbox), a location is in more policies than Microsoft allows, or a temporary fault on Microsoft’s side. It does not try again on its own.

The check reads every retention and retention label policy that is switched on and fails when any has a distribution status other than Success or Pending, naming each with its status. It warns when a policy is still being applied or came back without a status, and passes when every policy has been applied.

Why it matters

A retention policy with a distribution error looks set up, so nobody looks again, while the mailboxes or sites it failed to reach keep nothing. The gap is found when something deleted turns out not to be recoverable after all.

A typical case: an MSP sets up a seven-year email retention policy for a client, sees it listed as on, and moves on. One of the mailboxes named in it was deleted the week before, so distribution failed and the policy was never applied anywhere. Two years later, during a dispute, the emails everyone believed were kept are gone.

A failed policy is worse than none, because everyone believes the records are kept. Checking the distribution status is the only way to know a policy is doing its job.

It supports ISO 27001 control A.5.33 (protection of records) and CIS Controls safeguard 3.4 (enforce data retention): records are only protected by a policy that is in force.

How to fix it

Where: Microsoft Purview portal → Data lifecycle management → Policies → Retention policies

Before you start

• Read the error on each policy named in the evidence (Get-RetentionCompliancePolicy -DistributionDetail): it usually names the location that could not be reached.

Step by step

1. 1Find the policies that were not applied. Connect to Security & Compliance PowerShell (Install-Module ExchangeOnlineManagement, then Connect-IPPSSession) as a Compliance Administrator. Run Get-RetentionCompliancePolicy -DistributionDetail | Where-Object DistributionStatus -ne "Success" | Format-List Name, DistributionStatus, DistributionResults. DistributionResults says which location failed and why.
2. 2Fix what stopped it. If the error names a location that no longer exists, edit the policy in the Microsoft Purview portal (Data lifecycle management > Policies > Retention policies, or Label policies) and remove it. If it names too many locations, split the policy in two, or use All in place of a long list.
3. 3Retry the distribution. Run Set-RetentionCompliancePolicy -Identity "<policy name>" -RetryDistribution for each policy in error. Microsoft applies it again; this can take up to a day.
4. 4Confirm it is applied. The next day, Get-RetentionCompliancePolicy | Select-Object Name, DistributionStatus shows Success for every policy that is on, and the next assessment passes. If a policy goes back to Error, raise it with Microsoft support with the DistributionResults text.

With PowerShell

Connect-IPPSSession
Get-RetentionCompliancePolicy -DistributionDetail | Where-Object DistributionStatus -ne "Success" | Format-List Name, DistributionStatus, DistributionResults
Set-RetentionCompliancePolicy -Identity "<policy>" -RetryDistribution

What users will notice

None. Once applied, the policy keeps content in the locations it had missed.

How to confirm it worked

Get-RetentionCompliancePolicy | Select-Object Name, DistributionStatus shows Success for every policy that is on, a day after the retry.

Frameworks and controls

This check maps to controls in 6 frameworks. Passing it is evidence that the setting is in place, not a certification against any of them.

The framework mappings were last checked against the published standards in October 2026.

Microsoft’s documentation

• Resolve errors in retention and retention label policies (Microsoft Learn)

Related checks

• How to keep email and files with Purview retention policies
• How to publish retention labels in Microsoft Purview
• How to set up retention labels in Microsoft Purview
• How to find users without MFA in Microsoft 365

The full Microsoft 365 security checklist, worst first