error received when replying to an encrypted email in a shared mailbox using the new outlook

Question

error received when replying to an encrypted email in a shared mailbox using the new outlook

Dana Irvine 0

We have started to use Microsoft's encrypted emails with one of our shared mailboxes. We are able to send emails to initiate the conversation, but when the client responds to the email, we are unable to reply back. We get an error that states "The files couldn't be attached. Please try again later." and in the details after attempting to send, it references "The specified object was not found in the store." There are no file attachments on any message in the thread.

User's image

We do not experience this issue when emailing from personal mailboxes, this only happens when replying to encrypted emails from the shared mailbox. We have tried to reply using webmail, and we receive the same error message when sending. This affects all users of the mailbox.

What could be causing this?

0 comments

2 answers

Your answer

Answer 1

Hi Dana,

Thank you for confirming that the issue occurs in both new Outlook and Outlook on the web and affects all users of the shared mailbox.

This suggests the problem is related to the shared mailbox’s permissions or its handling of the encrypted message, rather than an Outlook installation or a visible attachment. The attachment error can appear because Outlook treats the protected content from the original encrypted message as part of the reply, even when no regular files are attached.

To resolve the issue, please follow these steps:

Open the Shared Mailbox Separately

In Outlook on the web:

Select your profile picture.
Select Open another mailbox.
Enter the shared mailbox address.
Open the encrypted conversation from that separate window and try replying.

Check and Reapply Mailbox Permissions

Please ask your IT administrator to connect to Exchange Online PowerShell and replace the example addresses below with the actual shared mailbox and user addresses:

Connect-ExchangeOnline
$SharedMailbox = "******@company.com"
$User = "******@company.com"

Check the user’s current Full Access and Send As permissions:

Get-MailboxPermission -Identity $SharedMailbox |
    Where-Object {
        $_.User -like $User -and
        $_.AccessRights -contains "FullAccess"
    } |
    Format-List User,AccessRights,Deny,IsInherited
Get-RecipientPermission -Identity $SharedMailbox -Trustee $User |
    Format-List Trustee,AccessRights,IsInherited

Full Access allows a delegate to open and manage the mailbox, while Send As allows messages to be sent as the shared mailbox. Automapping only works when Full Access is assigned directly to an individual user, not through a group.

If Full Access was assigned through a security group, assign it directly to a test user. If the user already has direct Full Access, remove and re-add it to explicitly enable automapping:

Remove-MailboxPermission -Identity $SharedMailbox `
    -User $User `
    -AccessRights FullAccess `
    -InheritanceType All `
    -Confirm:$false

Add-MailboxPermission -Identity $SharedMailbox `
    -User $User `
    -AccessRights FullAccess `
    -InheritanceType All `
    -AutoMapping $true

If Send As is missing, add it:

Add-RecipientPermission -Identity $SharedMailbox `
    -Trustee $User `
    -AccessRights SendAs `
    -Confirm:$false

Test a New Encrypted Conversation

Send a completely new encrypted email from the shared mailbox and ask the recipient to reply. If the new conversation works, the original encrypted thread may contain an invalid protected-message reference.

Verify the Encryption Configuration

Ask your IT administrator to check the tenant’s Information Rights Management configuration:

Get-IRMConfiguration |
    Format-List AzureRMSLicensingEnabled,InternalLicensingEnabled,SimplifiedClientAccessEnabled

Then test the encryption configuration using a licensed user as the sender:

Test-IRMConfiguration -Sender "******@company.com"

Next, identify the Outlook on the web mailbox policy assigned to the shared mailbox:

Get-CASMailbox -Identity "******@company.com" |
    Format-List OwaMailboxPolicy

Check whether IRM is enabled for that policy:

$Policy = (Get-CASMailbox -Identity "******@company.com").OwaMailboxPolicy

Get-OwaMailboxPolicy -Identity $Policy |
    Format-List Identity,IRMEnabled

If IRMEnabled is False, enable it for the policy assigned to the mailbox:

Set-OwaMailboxPolicy -Identity $Policy -IRMEnabled $true

If SimplifiedClientAccessEnabled is False, enable it:

Set-IRMConfiguration -SimplifiedClientAccessEnabled $true

After completing the checks, disconnect the PowerShell session:

Disconnect-ExchangeOnline -Confirm:$false

In case you do not know who is your IT admin, kindly refer to this article: How do I find my Microsoft 365 admin? - Microsoft Support

I hope your issue gets resolved soon. Any updates would be greatly appreciated.

Answer 2

The exact error is not covered by a current Microsoft known-issue fix; because it occurs for every delegate in both new Outlook and Outlook on the web, verify the shared-mailbox/Purview configuration and then open a Microsoft 365 support case if those checks are clean.

The attachment wording is likely misleading. The accompanying message—“The original message can't be shown right now”—suggests that the modern Outlook service cannot retrieve or process the protected original while constructing the reply, but Microsoft has not documented that as the confirmed cause of this exact error.

1. Test the documented shared-mailbox access path

If webmail was tested by expanding the shared mailbox beneath the user's primary mailbox, perform this distinct test:

Sign in to Outlook on the web.
Select the profile picture in the upper-right corner.
Select Open another mailbox.
Enter the shared-mailbox address and open it in its own browser tab.
Open the encrypted conversation there and send the reply.

Microsoft documents Open another mailbox as a workaround for a related condition where encrypted or restricted messages cannot be loaded through delegated shared-mailbox access.^1^

If webmail was already tested with the mailbox open in its own tab, skip this test.

2. Check how Full Access was assigned

An Exchange Online administrator should verify that the affected delegates have Full Access. New Outlook and Outlook on the web support delegates reading IRM-protected messages when they have Full Access; automapping is specifically relevant to classic Outlook.^2^

If Full Access was granted only through a security group, test one user with Full Access assigned directly. Microsoft documents that security-group membership is not expanded for automapping and recommends explicit Full Access assignments when automapping is required.^3^

This is a configuration check, not a documented fix for this exact reply error. Do not remove existing group permissions until direct assignment has been tested.

3. Run the Purview diagnostic and verify the assigned OWA policy

A Microsoft 365 Global Administrator should run the Microsoft Purview Message Encryption diagnostic from the Microsoft 365 admin center. An authorized Exchange Online administrator should then identify the OWA mailbox policy assigned to the affected user and check its IRM setting rather than assuming the default policy applies.^4^

Get-CASMailbox -Identity <DelegateUserAddress> |
    Format-List OwaMailboxPolicy

Get-OwaMailboxPolicy -Identity <AssignedPolicyName> |
    Format-List IRMEnabled

# Run only if IRMEnabled is False:
Set-OwaMailboxPolicy -Identity <AssignedPolicyName> `
    -IRMEnabled $true

Also verify that each delegate signing in to Outlook has a license that supports Microsoft Purview Message Encryption. Because the failure also occurs in Outlook on the web for all users, clearing local Outlook credentials is unlikely to address this case.

4. Check for the cross-tenant sensitivity-label condition

A separate by-design failure applies only when all these conditions are true:

The encrypted message came from an external organization.
Your organization enforces mandatory sensitivity labeling.
The user selects a sensitivity label that itself applies encryption.

In that case, reply using a label that does not apply encryption, such as General. Outlook cannot replace encryption owned by the external sender with encryption from the replying organization.^5^

5. Escalate if the checks pass

If the separate-tab test, direct Full Access test, Purview diagnostic, assigned-policy check, and licensing check do not resolve it, open a Microsoft 365 support request. Include:

Shared-mailbox address with identifying portions redacted in screenshots
UTC timestamp of a failed send
Affected delegate and recipient domains
Whether the original message is internal or external
Encryption policy or sensitivity-label name
Full error details, request/correlation IDs, and any NDR
Confirmation that both new Outlook and Outlook on the web fail for all delegates

This gives Microsoft Support the data needed to trace the protected-message operation in Exchange Online.

References