This browser is no longer supported.
Upgrade to Microsoft Edge to take advantage of the latest features, security updates, and technical support.
![](data:image/svg+xml, %3Csvg xmlns='http://www.w3.org/2000/svg' height='64' class='font-weight-bold' style='font: 600 30.11764705882353px "SegoeUI", Arial' width='64'%3E%3Ccircle fill='hsl(80, 28.000000000000004%, 17%)' cx='32' cy='32' r='32' /%3E%3Ctext x='50%25' y='55%25' dominant-baseline='middle' text-anchor='middle' fill='%23FFF' %3ECJ%3C/text%3E%3C/svg%3E)
My Organization is having problems opening AIP labeled emails in Outlook 2019. They are getting the email and it is asking them to verify the information, but that's as far as it goes. Trying to double click on the email only gives the "You don't have the permissions" window. This still will not bring up a prompt for them to verify.
I checked my labels. I set the whole domain for viewer permissions and it is properly applied through Policies. Is there something I'm missing? Does the domain need to be added to my AAD or is there a problem with Outlook?
I sent the same email to my school account. It opened with no problem.
I figured out we use O365 and outlook is just pulling the information from that to fill in the inbox. Would there be some kind of reason that AIP can't verify credentials in this instance?
What do you mean by Does the domain need to be added to my AAD? Your domain that you use for cloud accounts needs to be in Azure AD, otherwise you would not be able to use it for your accounts. Office 365, Azure AD and AIP are MS cloud services that use the same tenant, so the same accounts and the same domains.
![](data:image/svg+xml, %3Csvg xmlns='http://www.w3.org/2000/svg' height='64' class='font-weight-bold' style='font: 600 30.11764705882353px "SegoeUI", Arial' width='64'%3E%3Ccircle fill='hsl(86.4, 80%, 18%)' cx='32' cy='32' r='32' /%3E%3Ctext x='50%25' y='55%25' dominant-baseline='middle' text-anchor='middle' fill='%23FFF' %3ECJ%3C/text%3E%3C/svg%3E)
I think I found it out. I noticed while messing around that in the security and compliance center that the domain is actually a "*.onmicrosoft.com" domain, but we always use our "domain.com" domain for emails. Is this a connector? Also, is this what might be causing recipients to not be able to open encrypted emails?
The onmicrosoft.com domain is the default domain also known as "tenant name" which is globally unique across all MS cloud services and customers. And you are not able to change it afterwards.
Recommended is that you use your own (custom) domain name like domain.com for your accounts. Before you can use it, you need to add and verify the domain, see https://learn.microsoft.com/en-us/office365/admin/setup/add-domain?view=o365-worldwide So once you have verified the domain, you can use it for your accounts. Recommended is that you use your own domain for both UPN and mail - this is the simplest way. And you should also use the default onmicrosoft.com domain as an alias on your accounts. Then everything should work.
I made sure the aliases were set up, the problem still persists. I sent a protected labeled email to my admin account and tried to open it in outlook 2019 again. The admin could see i sent the mail, but could not see the message inside, even after double clicking on it.
The label has any authenticated users for permissions so I guess the domain wasn't the problem after all. Maybe it's because I'm using outlook 2019 standard edition? I know that it doesn't support the AIP plugins and labeling for outgoing mail, but shouldn't it still be able to authenticate incoming mail?
So it isn't the outlook version I'm using. I'm able to send email from my test o365 accounts with AIP to my local account running Outlook 2019 standard and open them with no problem.
I tried using labels and using the encrypt button, still sending mail between me and my admin account on the same domain. Just using the encrypt button gave me a different error. "Something went wrong with IRM. Unspecified error." Another email I sent gave back almost the same error except it added "The request is not supported" on the end instead of "Unspecified Error"