I can't believe this is still an issue. I've also had to do a password reset workaround for the shared 365 inbox, this seems like exactly the type of the thing that a shared service desk would definitely support?

A potential work around for those interested, relates to Jira Service Desk email handlers as shared mailboxs are functional in Service Desk

https://jira.atlassian.com/browse/JSDCLOUD-9392?error=login_required&error_description=Login+required&state=f0f9ec6a-68d2-4154-bc44-4593ab97941f

Although it technically works to reset the password of a shared mailbox in O365 and directly log-in as with the shared mailbox credentials, this is practice is discouraged by microsoft. And in the standard setting also against Microsoft licensing terms if the shared mailbox does not have a license assigned.

Please reconsider to implement the authentication to a shared mailbox with a delegated account. Ideally implement this immediately with the Oauth2 authentication for IMAP.

What happens when that shared mailbox's password expires due to my company's global password expiry time being exceeded?

Can confirm the above comment - Followed the same procedure and JIRA authenticated just fine. I left off the \mailbox-alias and just used the email address as the username.

This now works fine using the shared mailbox credentials and secure IMAP as the protocol to access Office 365.

To set the password for the shared mailbox user, you must go to the Admin Center -> Users -> Active Users and reset the password for the Shared Mailbox user. When you do that, specify the password, and uncheck 'Make this user change their password when they first sign in'.

I put in the full email as user name, password as password, and my JIRA is now checking IMAP email successfully.

With Office 365 adoption increasing by IT service providers, I think it's important that Atlassian revisit this issue. In the meantime, I will attempt the workaround listed above.

EDIT: On a cloud account, I don't think I can utilize the imap workaround. POP it is...

A workaround if you require using IMAP rather than POP3 (for example if you need to pull emails from a subfolder) is to use this username format:
ADdomain\licenseduser\sharedmailboxalias
with these java parameters (we are using secure imap), as ntlm and auth plain seem to fail with this username format:
-Dmail.imaps.auth.plain.disable=true
-Dmail.imaps.auth.ntlm.disable=true
If you are using non secure imap, then this should do you:
-Dmail.imap.auth.plain.disable=true
-Dmail.imap.auth.ntlm.disable=true

Thanks for taking the time to raise this issue.

Due to the large volume of JIRA feature suggestions, we have to prioritise our development efforts. In part, that means concentrating on those issues that resonate the most with our users.

I am writing this note to advise you, that we have decided to close your Suggestion as it has not gained traction on jira.atlassian.com. We believe being upfront and direct with you will assist you in your decision making rather than believing Atlassian will eventually address this issue.

Thank you again for your suggestion and if you have any concerns or question, please don’t hesitate to email me.

Kind Regards,
Kerrod Williams
JIRA Product Management
kerrod.williams at atlassian dot com

I had this same issue after migrating our on-premises Exchange 2007 regular mailbox for JIRA up to a shared (non-licensed) mailbox in Office 365 / Exchange Online. Something is indeed broken with JIRA's IMAP implementation (probably in the core Java IMAP library), because I can successfully access and browse the shared mailbox via OpenSSL/Telnet commands. By switching to POP3 I was able to get it working.

Workaround for Office 365 shared mailboxes:
Protocol: SECURE_POP
Host: outlook.office365.com
Port: 995
Username: licenseduser@mydomain.com\sharedmailboxalias
Password: (licensed user password)

NOt sure if this is the same, but our company uses Exchange in where the ID used to authorize is not the mailbox ID. I can find no way in JIRA to distinquish the two

Hi Atlassian
Since you converted this from a FUG to an Improvement, I guess that you do not support IMAP 100%.
Note:with POP3 you can do the domain/user/sharedmailbox login (but no folder access with POP3)