I encountered a MIP labelling use case that I have not encountered before. The use case question is:
What happens to an email that inherits the higher label IF the inherited label has the encryption/ permission set as “Let users assigns permissions when they apply the label” (aka user defined label)
The answer: a whole lot of complication as you can see below.
Encryption in MIP
Starting with the basic of access control: Microsoft Purview Information Protection gives IT admin an option to select which type of permission model to choose. IT defined or User defined model. The User defined model enables end-users to be to define the encryption for their document. This can be done through the label itself under controls.

This gives the user the ability to mix and match how they want their data to be accessed. Users can select who can have read or view or edit rights. These can be different individuals in 1 permission.

In the label publishing policy, you can then configure whether emails should inherit the label of a attachment if the label of the document is higher. This is to ensure that the higher label (with it’s higher security) takes precedence.

Testing
I ran a test with the following parameters.
- Open Outlook > The email label is set a NO LABEL
- Attached the Word document I created earlier with the label called Highly Confidential (this is the same file with the permission set from the 2nd screenshot above)
- Sent it to other 2 accounts that was not in the permission list above. This is to simulate how the recipients would see the message
- Sent to 1 internal account (Barry Allen)
- Sent to 1 external account that is NOT in the permission list
Outcome:
- Outlook was NOT able to inherit the higher label.



On a positive note, this means that the encryption/ permission still works on the document. The screenshot above is from an external email that I have that was not in the permission list of the attached file. So IT security can at least have that peace of mind to know that as long as the data is properly labelled. Data leakage is kept to a minimal.
The IT defined encryption option
In another test where the encryption option model for the label that I used is set to use IT Admin defined (all permission is pre-defined.)
The Outlook email was able to properly inherit the label.
Advice to IT admins
The Value of Testing and Advice for IT Admins
Testing is essential when setting up MIP labels and encryption. Real-world testing helps uncover issues or behaviours that might not be obvious from the documentation. By testing it yourself, you can be confident that the setup works as expected in your environment and meets your organisation’s needs.
Advice for IT Admins:
If you plan to use user-defined encryption, make sure your users are properly trained. This model can be confusing, and users might think they’ve set permissions correctly when they haven’t. To avoid mistakes, provide clear instructions and training. Testing these scenarios yourself will also help you spot potential problems and give better support to your users.