Shared Mailbox Sent Items Not Saving: How to Fix It

Shared mailbox sent items not saving to the shared folder is one of the most common shared-mailbox complaints in Microsoft 365 support tickets. A teammate replies as [email protected], and the message disappears — not into the shared mailbox's Sent Items, but into their own personal Sent folder. Nobody else on the team can see it was answered.

This isn't a bug. It's the default behavior of Outlook and Exchange Online, and it comes straight from how Microsoft designed shared mailbox permissions. Fixing it takes one setting change per mailbox — but it will not rescue messages you already sent.

What this error literally means#

When you open a shared mailbox in Outlook, you never actually sign in to it. You sign in to your own account, and Outlook layers the shared mailbox on top as an extra set of folders.

Reply from inside that shared view, and Outlook still sends the message under your authenticated identity, acting on the shared mailbox's behalf. Where the outgoing copy gets filed depends on a setting on the shared mailbox object itself — not on which folder you clicked reply from.

Microsoft designed it this way because a shared mailbox doesn't have its own license or its own sign-in — you can't authenticate directly to one. Every action taken 'as' the shared mailbox is really an action taken by a licensed user who has been delegated access to it, and Exchange has to decide separately where to file the result.

By default, that setting is off. The copy lands in your personal Sent Items, visible only to you, while the recipient still sees the shared mailbox's address in the From line. Two related permissions decide how the message looks to the recipient, and both are affected the same way:

• 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".

Full Access, Send As, and Send on Behalf: what each one controls#

The MessageCopy settings only matter once you already have the right permission to send from the shared mailbox in the first place. These three permissions get confused constantly, and mixing them up is the most common reason a fix appears not to work.

None of the three imply each other. A person can have Send As without Full Access, which means they can send mail as the shared mailbox but can't open its Inbox or Sent Items to check anything — including whether the copy actually saved.

Why sent items go missing: the three real causes#

Most tickets that describe this problem turn out to be one of three separate causes, not one bug with three symptoms. Confirm which one you have before you touch a registry key — it's the difference between a five-minute fix and an afternoon.

All three sit at a different layer — mailbox configuration, client cache, and tenant rollout — which is why a single 'try this' answer copied from a forum thread often doesn't fix it for the next person who searches the same error.

The fourth row matters more than it looks. Plenty of tickets titled 'sent items not saving' turn out to be 'I can't see the shared mailbox at all' tickets in disguise, and no MessageCopy setting fixes a missing Full Access grant.

Fix 1: Turn on the mailbox-level setting#

This is the fix that works everywhere — new Outlook, classic Outlook, Outlook on the web, and mobile — because it's set once on the mailbox itself, not per client. It requires Exchange admin rights.

You need the Recipient Administrator or Exchange Administrator role in Microsoft 365 to run these commands. A regular user, even one with Full Access to the shared mailbox, can't change this setting themselves — it has to come from IT.

There's no toggle for either property in the Microsoft 365 admin center or the Exchange admin center interface. As of July 2026, Exchange Online PowerShell is the only supported way to set them.

1. 1

   Connect to Exchange Online PowerShell

   Run Connect-ExchangeOnline with an account that has Exchange admin rights. This is a tenant-level session; end users can't run it themselves.

2. 2

   Confirm the current setting

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

3. 3

   Enable both properties

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

4. 4

   Wait for it to replicate

   Give it up to 60 minutes to take effect across Exchange Online before retesting. A test five minutes after the change often looks like the fix failed when it hasn't yet applied.

5. 5

   Send a test reply and check the shared mailbox

   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 landed there.

Fix 2: Force it client-side with the registry#

This method exists for one specific case: someone on classic Outlook desktop needs the copy to save locally, and you can't or don't want to change the mailbox-level setting yet. Microsoft's own guidance is explicit that new Outlook only supports Fix 1 — this registry method has no effect there.

It also only works when Cached Exchange Mode is turned on for that Outlook profile. Skip it if the account runs in online mode.

This is worth doing when you need an immediate fix for one person while an admin gets around to Fix 1, or in a small business where nobody holds Exchange admin rights at all.

1. 1

   Confirm Cached Exchange Mode is on

   Go to File > Account Settings > double-click the account, and confirm the Cached Exchange Mode checkbox is ticked. The registry value silently does nothing without it.

2. 2

   Open Registry Editor on that machine

   Run regedit on the affected computer. This is per-machine, per-profile — it has to be repeated on every computer where you want the behavior, not just once for the team.

3. 3

   Navigate to the Outlook Preferences key

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

4. 4

   Create the DWORD value

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

5. 5

   Restart Outlook and retest

   Close and reopen classic Outlook fully, then send a test reply from the shared mailbox to confirm the copy now files into the shared mailbox's Sent Items.

Fix 3: Roll it out across every shared mailbox your team uses#

A team rarely has just one shared mailbox. Support, sales, and billing inboxes usually get created at different times by different people, and the sent-items setting doesn't inherit between them — each one needs it set explicitly.

1. 1

   List every shared mailbox in the tenant

   Run Get-Mailbox -RecipientTypeDetails SharedMailbox -ResultSize Unlimited to see every shared mailbox, so you're not fixing one and missing three.

2. 2

   Enable both properties in one pipeline

   Run Get-Mailbox -RecipientTypeDetails SharedMailbox -ResultSize Unlimited | Set-Mailbox -MessageCopyForSentAsEnabled $True -MessageCopyForSendOnBehalfEnabled $True to set both flags tenant-wide in a single command.

3. 3

   Check delegation matches, not just the flag

   The setting has no effect for someone who only has Send As without Full Access — they can send mail, but they can't see the shared mailbox's folders at all, including the now-working Sent Items.

4. 4

   Add it to your provisioning checklist

   Whoever creates new shared mailboxes should run this immediately after creation, before the first person gets delegated access, so the gap never opens on a new mailbox.

5. 5

   Set a recurring reminder to re-check

   Shared mailboxes created after your last audit won't have the setting, and neither will any migrated from an on-premises Exchange server. A calendar reminder every quarter catches both.

How to tell which cause you have#

If you're not sure which of the three causes above applies, match your symptom to one of these before you start changing settings.

If none of these match — for example, the copy saves into the wrong shared mailbox, or only for messages under a certain size — treat it as a support case with Microsoft rather than a configuration gap. That combination isn't standard behavior.

• Missing everywhere — OWA, new Outlook, mobile, and classic desktop — the mailbox-level setting is off. Go to Fix 1.
• Saves correctly in OWA and new Outlook but not in classic desktop Outlook — Cached Exchange Mode with no registry override. Go to Fix 2.
• Works for one shared mailbox but not another the team also uses — the property was set per-mailbox and missed some. Go to Fix 3.
• The sender can't see the shared mailbox's folder list at all, Sent Items included — this is a Full Access permissions gap, not a sent-items setting problem.

Preventing it#

The cheapest fix is never needing Fix 1 at all. Set MessageCopyForSentAsEnabled and MessageCopyForSendOnBehalfEnabled the moment a shared mailbox is created, as part of the same provisioning step that grants Full Access — before anyone sends the first reply from it.

For an existing tenant, run the Fix 3 audit command quarterly. A shared mailbox created by IT during an onboarding rush is the one most likely to get skipped, and it's usually the one a whole team depends on within a month.

If your organization scripts the provisioning of new shared mailboxes, add both Set-Mailbox flags to that script directly, so the fix ships as part of the automation that creates the mailbox — not as a manual follow-up someone has to remember.

The root cause here is that Outlook files sent mail by identity, not by which mailbox you replied from — a server-side flag has to explicitly override that, and it's easy to miss on any one mailbox. AI Emaily's shared inbox works differently: every reply sent by anyone with access to a connected shared mailbox is logged and visible to the whole team the moment it sends, with an audit trail of who replied and when, regardless of whether they used Send As or Send on Behalf. We build AI Emaily, and we built shared inboxes around exactly this failure mode, because a team that can't see its own replies ends up answering the same message twice.