Your sensitivity labels are not showing up. Here is the order to check

A user opens Word or Outlook and the Sensitivity button is missing, or it is there but your labels are not in the list. Someone else in the same tenant sees them fine.

This is the single most recurring Purview issue, and the reason it eats so much time is that the label sits at the end of a long chain: a licence, a policy, the policy reaching that specific user, the label being enabled for the right content types, the client being willing to use built-in labelling, and a local cache that may be days out of date. Any one of those breaks it, and the symptom looks identical every time.

So do not start by editing the label. Work the chain in order, cheapest first.

Free, instant, and genuinely the cause more often than people expect.

Confirm the account signed into the app is the licensed one. On a shared or newly built machine, Office is frequently signed in with a personal account or a different tenant account, and labels correctly do not appear for it.

Then confirm the licence is actually assigned to that user, not merely owned by the tenant, and that the Office edition in use is covered by it.

A label only exists for a user if a label policy publishes it to them. This is where most tickets end up.

Check a policy includes the user. If it is scoped to a group, confirm they are really a member: nested groups and recently added members are a classic trap. Check the policy is in Enforce mode rather than sitting in test.

Then check it actually distributed:

Get-LabelPolicy -Identity "Your policy name" | fl

You want DistributionStatus: Success. Anything else means the policy has not landed yet, and no amount of client-side fiddling will help.

Only now is it worth looking at the label:

Get-Label -Identity "Your label name" | fl

Check ContentType includes both File and Email. A label scoped only to groups and sites will never appear in Office apps, which is the single most common misconfiguration here. Check Disabled is False. For Outlook specifically, the policy Workload needs to include Exchange.

One more that catches people: a parent label that has sublabels cannot be applied directly. If your users are looking for the parent, they will never find it. They are meant to pick a sublabel.

If the service side is clean, the client may be refusing to use built-in labelling.

Check the app version supports it, then check this registry key:

HKEY_CURRENT_USER\Software\Microsoft\Office\16.0\Common\Security\Labels

If UseOfficeForLabelling is 0, Office is handing labelling to the old AIP add-in instead of doing it itself. Set it to 1. Also check the equivalent policy key under Software\Policies, because Group Policy can switch built-in labelling off across the estate without anyone remembering it was set.

Finally, confirm the file type is actually supported for built-in labelling.

If everything above is correct and it still will not show, the client is probably holding a stale copy of the policy.

Close every Office app. Go to %localappdata%\Microsoft\Office\CLP and rename the CLP folder to something like CLP_old. Reopen the app: it reconnects and downloads the labels fresh.

This is safe and it is the right last step, but do not lead with it. If the policy never reached the user, clearing the cache just re-downloads nothing.

Worth knowing: Microsoft ships an automated sensitivity label diagnostic in the Microsoft 365 admin center. It takes a label name and the affected user and checks much of the above for you. It needs Global Administrator, which is why it is not always the first tool reached for.