Shared Mailbox Sent Items Not Showing or Saving: The Fix

Replies sent from a shared mailbox save to the sender’s own Sent Items, not the shared mailbox’s, until an Exchange admin turns on MessageCopyForSentAsEnabled (for Send As) and MessageCopyForSendOnBehalfEnabled (for Send on Behalf) on that shared mailbox. Both properties default to False, and the change only affects mail sent after it.

Here is the whole fix for Exchange Online. Run it as an admin, then send a test reply. The rest of this page covers the admin center option, the registry method for classic Outlook, and what the “attached message was sent by a member of this shared mailbox” item is.

Messages sent from a shared mailbox aren’t saved to the Sent Items folder: why#

In Microsoft 365, a shared mailbox doesn’t need a license and you can’t sign in to it. You sign in to your own mailbox and open the shared one. Microsoft’s troubleshooting article explains that when you send or reply from the shared mailbox, Outlook sends from the sender’s account, so the message is stored in the sender’s Sent Items.

That is the default, not a bug. The recipient still sees the shared mailbox’s address, but the copy lives in a mailbox only the sender opens, so the rest of the team can’t see the thread was answered. Two permissions decide how the message looks to the recipient, and each has its own copy setting:

• Send As: the message appears to come only from the shared mailbox. The recipient never sees your name.
• Send on Behalf: the message shows both, as “Your Name on behalf of Shared Mailbox”.

MessageCopyForSentAsEnabled and MessageCopyForSendOnBehalfEnabled: what they do#

Both are Boolean properties on the mailbox, documented in Microsoft’s Set-Mailbox reference. Each one covers exactly one permission, which is why enabling only one still leaves the other type of reply going to the sender’s folder.

• Set it per mailbox with Set-Mailbox. It isn’t inherited, so a new shared mailbox starts at False again.
• Check it with Get-Mailbox <mailbox> | fl MessageCopyForSentAsEnabled, MessageCopyForSendOnBehalfEnabled. True means on.
• It works in Exchange Online and in on-premises Exchange Server 2013 and later. Microsoft notes it’s also available on user mailboxes in current versions, but not on linked mailboxes.
• The copy is made when the message is sent, so it only affects mail sent after you switch it on.
• With the property on, the sender’s own Sent Items still keeps its copy as well, unless you also use the registry value in Fix 2.

Fix 1: Turn on the mailbox-level setting#

This is the fix that works in every client, including new Outlook, classic Outlook, Outlook on the web and mobile, because it’s set once on the mailbox. It needs an account that is allowed to run Set-Mailbox on that mailbox, which in practice means an Exchange administrator. A user with Full Access can’t change it.

You can also do it without PowerShell. Microsoft’s shared mailbox settings page says to open the Microsoft 365 admin center, go to Teams & groups > Shared mailboxes, select the mailbox, and choose Edit under Sent items. Microsoft Q&A answers describe checkboxes there for items sent as and sent on behalf of the mailbox; labels can change as the portal is updated, and it’s worth confirming the result with Get-Mailbox.

1. 1

   Connect to Exchange Online PowerShell

   Run Connect-ExchangeOnline with an admin account. This is a tenant-level session that end users can’t run.

2. 2

   Confirm the current setting

   Run Get-Mailbox <mailbox name> | fl MessageCopyForSentAsEnabled, MessageCopyForSendOnBehalfEnabled. Both read False on a mailbox nobody has configured.

3. 3

   Enable both properties

   Run Set-Mailbox <mailbox name> -MessageCopyForSentAsEnabled $true -MessageCopyForSendOnBehalfEnabled $true. Enable both, because most teams have a mix of Send As and Send on Behalf delegates.

4. 4

   Re-check the values

   Run the Get-Mailbox command again and confirm both now read True. Microsoft doesn’t publish a propagation time for this setting, so if a test right after the change still lands in the sender’s folder, wait a little and retest.

5. 5

   Send a test reply and look in the right folder

   Reply from the shared mailbox in any client, then open the shared mailbox’s own Sent Items, not the sender’s, to confirm the copy is there. If the sender can’t open the shared mailbox’s folders at all, they need Full Access (see the permissions check below).

What does “The attached message was sent by a member of this shared mailbox” mean?#

That text comes from a wrapper message. Instead of showing the sent mail as a normal item, Exchange delivers it as an attachment inside a short notification, and the notification carries three fixed lines:

• “The attached message was sent by a member of this shared mailbox.”
• “Usually, it would appear in Sent Items, but your service is currently being upgraded.”
• “Things will be back to normal after the upgrade.”
• A variant says the message was sent by a user who has Send As or Send on Behalf rights for the mailbox, and that it will be saved to the Sent Items folder after the upgrade.

The “service is being upgraded” line is wording built into the wrapper. It doesn’t mean your tenant has an outage. Practical 365 documents the classic case: during Exchange 2010 and 2013 coexistence, a newer sender using Send As on a shared mailbox that was still on Exchange 2010 produced exactly this wrapper in the shared mailbox’s Inbox, and the author notes the upgrade wording confuses users who live in a long coexistence.

The newer documented case is hybrid. Microsoft’s support article on wrapper messages in hybrid environments (next section) describes wrapper messages arriving in a shared mailbox’s Inbox when MessageCopyForSentAsEnabled or MessageCopyForSendOnBehalfEnabled is enabled and the sender is an on-premises user.

In a cloud-only tenant we couldn’t find a Microsoft document that explains wrapper items or says how to remove them, so treat that as a support case with Microsoft rather than guessing at a fix.

Why does a wrapper message appear in my shared mailbox Inbox (hybrid Exchange)?#

Microsoft’s article “Wrapper messages appear in shared mailbox inbox in hybrid environments after installing the June 2026 Security Update” covers one specific setup. It applies to Exchange Server Subscription Edition, 2019 and 2016, where the shared mailbox is hosted in Exchange Online, an on-premises mailbox has Send As or Send on Behalf on it, and one of the MessageCopy properties is enabled. After the June 2026 update, messages sent as or on behalf of the shared mailbox can also land in its Inbox as attachments with the wrapper text.

Microsoft says the fix is included in the September 8, 2026 security update for your Exchange version, or any later one. It doesn’t state a root cause. For the workaround, it says to check from the Exchange Management Shell whether a setting override named DisableBlockSharedAndUserMailboxHeaders exists, and to remove it if it does. Read the article for your version before changing anything on production servers.

1. 1

   Check whether the override exists

   In an elevated Exchange Management Shell, run Get-SettingOverride "DisableBlockSharedAndUserMailboxHeaders". If it reports that the object couldn’t be found, Microsoft says no further action is needed.

2. 2

   Remove it if it’s there

   Run Remove-SettingOverride "DisableBlockSharedAndUserMailboxHeaders", as the article instructs.

3. 3

   Install the September 8, 2026 or later security update

   Microsoft lists the KB for each Exchange version in the article. Pick the one for your Exchange build.

Fix 2: Force it client-side with the registry (classic Outlook only)#

This exists for one case: someone on classic Outlook desktop needs the sent copy in the shared mailbox now, and you can’t change the mailbox-level setting yet. Microsoft’s troubleshooting article is explicit that new Outlook only supports Fix 1, so this value does nothing there. It also requires Outlook to run in Cached Exchange Mode, applies per Windows profile, and has to be repeated on each computer.

Do not stack it blindly with Fix 1. Microsoft’s table of expected behavior for the Send As setting shows that combining DelegateSentItemsStyle = 1 with MessageCopyForSentAsEnabled = True produces two copies in the shared mailbox and none in the sender’s:

1. 1

   Confirm Cached Exchange Mode is on

   Go to File > Account Settings, open the account, and check that Use Cached Exchange Mode is ticked. Microsoft says the value needs it.

2. 2

   Open Registry Editor on that machine

   Run regedit. Back up the registry first, as Microsoft advises.

3. 3

   Go to the Outlook Preferences key

   Navigate to HKEY_CURRENT_USER\Software\Microsoft\Office\16.0\Outlook\Preferences.

4. 4

   Create the DWORD value

   Add a DWORD (32-bit) value named DelegateSentItemsStyle and set its data to 1.

5. 5

   Restart Outlook and retest

   Close and reopen Outlook fully, then send a test reply from the shared mailbox and check the shared mailbox’s Sent Items.

Fix 3: Roll it out across every shared mailbox#

Teams rarely have one shared mailbox, and the setting doesn’t carry over from one to the next. Support, sales and billing inboxes get created at different times, and a mailbox moved from an on-premises Exchange server may need the setting set again too (Practical 365 notes the Exchange 2013 values weren’t retained after a move to Exchange Online).

1. 1

   List every shared mailbox

   Run Get-Mailbox -RecipientTypeDetails SharedMailbox -ResultSize Unlimited | fl DisplayName, MessageCopyForSentAsEnabled, MessageCopyForSendOnBehalfEnabled to see which ones are still False.

2. 2

   Enable both properties in one pipeline

   Run Get-Mailbox -RecipientTypeDetails SharedMailbox -ResultSize Unlimited | Set-Mailbox -MessageCopyForSentAsEnabled $true -MessageCopyForSendOnBehalfEnabled $true. Review the list from the previous step first, because this changes every shared mailbox in the tenant.

3. 3

   Add it to your provisioning checklist

   Whoever creates a shared mailbox should set both properties in the same step that grants access, so the gap never opens. If creation is scripted, add both flags to the script.

Permissions check: why some people still can’t see sent items#

Plenty of “sent items not showing” tickets are really permission tickets. The copy settings decide where a message is filed; Full Access decides whether you can open the shared mailbox to see it. The three permissions are independent, so a person can have Send As and still be unable to look in the folder. The full breakdown is in Full Access vs Send As vs Send on Behalf.

If the mailbox doesn’t appear in Outlook at all, read shared mailbox not showing in Outlook. If you’re deciding how to send from it, see how to send email from a shared mailbox, and for client setup see automapping vs a separate account.

Where AI Emaily fits#

Everything above is Exchange configuration, and AI Emaily doesn’t change it. If your team’s shared mailbox lives in Microsoft 365, the Exchange setting is still what decides where Outlook files a reply.

What AI Emaily adds is a team inbox of its own. On the Team plan, an admin shares a connected mailbox with members, who all work the same threads, assign them and comment, and reply through Copilot so a person approves each send. Actions stay attributed to the person who took them in the thread history. See shared inboxes in AI Emaily for what members can and can’t do.