Exchange June 2026 Security Update: Shared Mailbox Sent Items Appearing in the Inbox in Hybrid Environments
A real, currently open Microsoft issue affecting hybrid Exchange environments. This is informational — it's a Transport/message-flow issue, outside what shared mailbox delegation tooling like Tenvero manages.
What's happening
Following the June 2026 Exchange Server Security Update, Microsoft has documented an issue affecting shared mailboxes in hybrid deployments: mail sent using Send As or Send on Behalf can appear as an attached "wrapper message" in the shared mailbox'sInbox instead of being filed in Sent Items, with an in-message notice about the service being upgraded.
Who is affected
This is scoped narrowly, not a general Exchange Online problem:
- Hybrid environments only — a shared mailbox hosted in Exchange Online, with the sending delegate's own mailbox on-premises.
- The shared mailbox has
MessageCopyForSentAsEnabledorMessageCopyForSendOnBehalfEnabledturned on, so a copy of sent mail is expected in its Sent Items. - Mail sent via Send As or Send on Behalf specifically — not mail sent from the delegate's own mailbox.
Source and current status
Microsoft's official support article covers the exact scope, symptom and workaround — it's the authoritative reference, and the one to check for updates since Microsoft notes the article is subject to revision:
Wrapper messages appear in shared mailbox inbox in hybrid environments (Microsoft Support, KB 5105719), corroborated by Released: June 2026 Exchange Server Security Updates on the Exchange Team Blog.
Microsoft's KB documents a workaround using a Transport New-SettingOverrideagainst the BlockSharedAndUserMailboxHeaders setting, plus a diagnostic refresh step — see the KB directly for the exact command, since it's the kind of setting best applied from the current, canonical source rather than copied secondhand. As of this writing, Microsoft describes the issue as under investigation — treat it as open, not resolved.
Why this isn't a Tenvero item
This issue is about how Exchange Transport files a copy of an already-sent message — it happens after the send, regardless of who was allowed to send. It has nothing to do with who holds Full Access, Send As or Send on Behalf, or whether that access is correctly reconciled against an AD group. If you're troubleshooting this, the fix is Microsoft's transport-level workaround above, not a delegation change.