Azure Information Protection will be able to apply the same tracking and revoke features on email that today are available for documents.

Add new options in EXO DLP to interrogate and analyze protected attachments in unprotected emails or in emails protected with a different policy.

Providing the same secure mail to anyone scenarios to users with on-premises Exchange Server mailboxes

The DNF template has restrictions on copy, print and export. Some customers would like to modify this template for example to allow print.

Maybe also a possibility to add a company wide scope of users to this dynamic rule like the request in
https://msip.uservoice.com/forums/600097-azure-information-protection/suggestions/19602400-dynamic-protection-templates

And the possibility for the sending user to add more users to the permission list with BCC and without BCC

for example if Sara@contoso.com send DNF to Anna@contoso.com and Lisa@adatum.com but wants Anna@contoso.com to be co-owner.

if Sara@contoso.com send DNF to Lisa@adatum.com but wants her team to be co-owner.

Allow for a configurable prefix or suffix to be added to the subject line of an Outlook message. For example - my message subject is "Testing" when I classify this as Confidential the subject line becomes "Testing [C]" adding in an abbreviated form of the classification for quick reference and visibility in the inbox.

Currently, when sender has digitally signed a protected email in Outlook, recipients using OWA or Outlook Mobile will only see the IRM wrapper message.

If recipient uses Outlook 2016, the protected message is deciphered/rendered perfectly fine!

The Do Not Forward option is the current default protect action in new exchange online emails. This protection level is very restrictive and not preffered by enterprise. The Encrypt Only option is a better fit for business. Would like to have the ability for organizations to Change the default protect action for their users to allow setting Encrypt Only as the default action.

Under the Office 365 Message Encryption portal you can access and view a protected email once you authenticate through the portal, but you cannot access a protected attachment by choosing Preview in the Office Online viewer, as you cannot in Office Online apps generally (from SPO or OWA etc). You can only download the attachment.

This suggestion describe a scenario when all mails that are sent without a label (no AIP client, mail client that don't support labeling, enforce mandatory labeling) will be applied with the policy default label on the Exchange Online service side

Some organizations have established policies by which they will never send an email with a link to their customers. Since OME includes a link to open the email, this can go counter to such policies.
OME should allow users to log in to a specific portal where they can consume their protected emails sent by the organization, in the same way they use OME today but without having to click on a link in an email.

Building on this item ( https://msip.uservoice.com/forums/600097-azure-information-protection/suggestions/33963844-allow-custom-email-x-headers-defined-per-label ) there is a need to dynamically inject a token into the custom header.
IE. Embedding the user's email address into the custom header is a requirement for all Australian Government customers (~1m users nationally).

When you don't select a default label, users are required to manually select a label. Although this is great for live users, it interferes with bulk email distribution scripts, because the process stops to wait for the selection of a label for each automatically generated email. We need to assign a default label that applies only for bulk email processes. Either that, or provide standard code that can be included in bulk email scripts to enable the assignment of an appropriate default label.

We want to use auto decrypt feature for IRM e-mail (as like -DecryptAttachmentFromPortal).
The aim of decrypt feature is to encrypt e-mail between sender and reciever.(decrypt only e-mail's route)
This featuer is not need 3rd party SSL certification and reciever can be flexibly use the e-mail and attached contents.
We want to use the feature regardless of the user or content.