# Shared Mailbox Sent Items: A Complete Guide for 2026 Published: June 29, 2026 Fix missing shared mailbox sent items in Outlook & Office 365. This guide covers PowerShell commands, troubleshooting duplicates, and API sending scenarios. You send from support@company.com. The message goes out. The customer replies later, a teammate asks what was promised, and the shared mailbox looks like nothing happened. That's the moment this issue stops feeling like an Outlook quirk and starts feeling like an operational bug. In Microsoft 365, **shared mailbox sent items** often “disappear” because Exchange is doing exactly what it was configured to do by default. The sent copy lands in the sender's personal mailbox, not the shared mailbox the team uses. For a support queue, a sales alias, or an automated agent acting through a mailbox identity, that default is hostile to visibility. It breaks handoffs, weakens audit trails, and turns a shared address into a private trail of scattered sent mail. ## Why Shared Mailbox Sent Items Disappear The common failure mode is simple. Alice sends from support@. Bob opens the shared mailbox later and checks Sent Items. It's empty, or at least missing the message he expected to see. That behavior is default Exchange and Microsoft 365 behavior, not a random sync problem. **By default, the `MessageCopyForSentAsEnabled` setting is disabled**, so a copy of mail sent from a shared mailbox is stored only in the sender's personal Sent Items folder. The shared mailbox's Sent Items folder stays incomplete unless an admin changes that behavior. ### What users expect versus what Exchange does Organizations typically treat a shared mailbox like a team-owned identity. If someone sends from billing@ or sales@, everybody expects that message to live with the rest of that mailbox's history. Exchange doesn't think that way by default. It thinks in terms of the user who performed the send action. That's why the sender gets the saved copy, while the shared mailbox often gets nothing. > **Practical rule:** If your team sends from a shared address and relies on the shared Sent Items folder as the record of truth, default Microsoft 365 behavior is working against you. This gets worse when teams build process around the mailbox. A support lead audits replies from the shared folder. A manager counts outbound follow-ups. A developer wires automations around mailbox activity. All of them assume the shared mailbox reflects what was sent. Without explicit configuration, it doesn't. ### Why this matters beyond Outlook The cost isn't just user confusion. It's broken coordination. A lot of teams start with a shared mailbox because it feels lighter than deploying a full platform. That works for a while, especially if you're still [choosing a support ticket system](https://www.headsetarmy.com/articles/support-ticket-system) and haven't fully committed to a help desk workflow. But once multiple humans or automations send from the same identity, missing sent items create blind spots fast. A bot or internal tool can make the problem even harder to spot. Humans notice an empty folder. Code doesn't complain unless you deliberately check for sent item placement. So the mailbox can look healthy from the outside while your actual communication history is fragmented across personal mailboxes and application contexts. ## Fixing Sent Item Behavior in Outlook and Exchange If a shared mailbox is your team record, fix this in Exchange first. Client-side workarounds burn time and fail unannounced. Outlook rules differ by user, cached profiles hide changes, and old desktop fixes survive long after everyone forgets why they were added. The reliable control point is the mailbox itself. ![A comparison chart explaining the advantages of server-side control versus disadvantages of client-side rules for shared mailboxes.](https://cdnimg.co/9a227681-63f7-452a-a677-fb77b6767eba/825ae35d-2b66-410c-9de8-3e18206eed3d/shared-mailbox-sent-items-comparison-chart.jpg) ### Start with the mailbox attributes The setting lives on each shared mailbox. There is no tenant-wide switch that retroactively fixes every mailbox your org has accumulated over the years, so admins need to verify and set this per identity. Check the current value with PowerShell: ```powershell Get-Mailbox 'shared@example.com' | Select MessageCopyForSentAsEnabled ``` Enable saving sent copies for **Send As**: ```powershell Set-Mailbox 'shared@example.com' -MessageCopyForSentAsEnabled True ``` That fixes only one permission path. In real environments, that distinction matters more than people expect. ### Treat Send As and Send On Behalf as different cases Users often see both options as “sending from the shared mailbox.” Exchange does not. - **Send As** shows the shared mailbox as the sender - **Send On Behalf** shows the user sending on behalf of the shared mailbox Those map to different mailbox properties: - `MessageCopyForSentAsEnabled` - `MessageCopyForSendOnBehalfEnabled` If both permission models exist in your environment, enable both settings: ```powershell Set-Mailbox -Identity shared@example.com -MessageCopyForSentAsEnabled $true -MessageCopyForSendOnBehalfEnabled $true ``` The common mistake is assuming Full Access, Send As, and sent-item retention are one bundle. They are separate controls. Granting mailbox access does not tell Exchange where to keep the sent copy. ### The command that fixes most environments For shared mailboxes used by a mix of delegates, this is the practical default: ```powershell Set-Mailbox -Identity shared@example.com -MessageCopyForSentAsEnabled $true -MessageCopyForSendOnBehalfEnabled $true ``` I use that as the baseline unless there is a specific reason to preserve different behavior. It removes ambiguity, and ambiguity is what usually breaks audit trails. A few points are easy to miss: 1. **This is per mailbox.** Fixing one support inbox does nothing for the sales or finance mailbox. 2. **Exchange applies the setting server-side.** Outlook may still need a restart, and cached mode can make admins think the change failed when it has not. 3. **PowerShell is the source of truth.** Admin UI state can lag or hide details that matter during troubleshooting. Here's the quick reference: | Scenario | Required setting | |---|---| | User sends as shared mailbox | `MessageCopyForSentAsEnabled $true` | | User sends on behalf of shared mailbox | `MessageCopyForSendOnBehalfEnabled $true` | | Mixed environment with both behaviors | Enable both settings | Microsoft's older Exchange team guidance confirms the default behavior many admins run into. Saving a copy in the shared mailbox Sent Items folder is disabled by default and has to be turned on explicitly through admin tools or PowerShell, as described in [Microsoft Tech Community](https://techcommunity.microsoft.com/blog/exchange/want-more-control-over-sent-items-when-using-shared-mailboxes/611106). This matters even more once the mailbox stops being human-only. If a shared address is used by scripts, service accounts, or an AI agent, “someone probably has a copy in their personal Sent Items” stops being acceptable. Legacy Exchange settings can fix the classic Outlook problem, but they still leave you stitching together behavior across mailbox permissions, clients, and automation paths. Purpose-built agent platforms avoid a lot of that by treating message history as an application concern instead of a side effect of Outlook. A short demo helps if you need to show the team what this looks like in practice: ### What not to trust Skip these as your primary fix: - **Per-user Outlook rules**, because they drift and break unnoticed - **Team habits**, such as checking one delegate's Sent Items folder - **Assumptions based on the admin center**, because the mailbox properties are what control behavior Set the mailbox flags. Verify them in PowerShell. Then send a real test message from the exact permission model your users or automations use. ## Troubleshooting Duplicate and Missing Sent Items You enabled the mailbox settings and now every sent message appears twice. Or nothing seems to have changed. Both problems are common, and both usually come from old fixes colliding with newer server-side settings. ### Why duplicates happen The usual culprit is a conflict between a legacy client-side workaround and the newer server-side mailbox setting. That can be an Outlook rule, a previously modified machine, or a Group Policy setting tied to delegate sent-item behavior. A university IT notice about an Office 365 update describes the pattern clearly: **users with previously modified machines can start seeing duplicate sent emails in the shared mailbox Sent Items folder after the update**, and fixing it requires disabling the older client rule in [the University of Toronto guidance](https://easi.its.utoronto.ca/upcoming-change-to-shared-mailbox-sent-items-folder/). > Don't debug duplicates only in Exchange. Check the endpoint too. Old machine-level workarounds have a long half-life. If the environment has had shared-mailbox pain for years, assume someone implemented a local fix at some point. That's especially likely in enterprise tenants that passed through multiple Outlook versions and desktop management policies. ### A clean way to diagnose it Start with the mailbox, then the client. - **Verify the Exchange settings first** by checking the mailbox attributes in PowerShell. If the mailbox flags are correct, the server side is probably fine. - **Test in Outlook on the web** before touching local Outlook. If the behavior is clean there and messy on desktop, the desktop client is the problem. - **Review Group Policy and registry-based delegate settings** on affected machines. Legacy delegate behavior often survives upgrade cycles. - **Remove old client rules or prior workarounds** before testing again. A quick comparison helps: | Symptom | Likely cause | |---|---| | Message appears twice in shared Sent Items | Old client workaround plus server-side copy | | Message still missing after config change | Wrong permission path, wrong mailbox, or client delay | | One user sees correct behavior and another doesn't | Machine-specific Outlook or policy issue | ### Why missing items can persist after the fix Sometimes the setting is right, but users still report failure right away. That doesn't always mean the command failed. The mailbox setting can take a little time to propagate, and Outlook clients may need a restart before they reflect the new behavior. Cached state also muddies testing. If you sent one test message before the change and another immediately after, users often compare the two and assume the fix never worked. Use a boring, controlled test: 1. Close Outlook. 2. Confirm the mailbox attributes in PowerShell. 3. Reopen Outlook or use Outlook on the web. 4. Send one new test message as the shared mailbox. 5. Check only that new message. ### What usually works in the field When shared mailbox sent items are still broken after “the fix,” I look for layered history, not a single bug. Old desktops, old policies, old assumptions. Exchange is often the easy part. For duplicate behavior, remove client-side workarounds. For missing behavior, verify whether the sender used **Send As** or **Send On Behalf** and whether the matching mailbox setting exists. Those two checks solve a large share of the mess. ## Managing Sent Items for Automated and API-Based Email The ugly version of this problem shows up at 2 a.m. A job sends 5,000 support replies through a shared mailbox, customers receive them, and the team opens Sent Items the next morning to audit what happened. Half the trail is missing, or it is sitting under the wrong identity. ![A four-step infographic illustrating the automated process for managing sent items from API-based email systems.](https://cdnimg.co/9a227681-63f7-452a-a677-fb77b6767eba/6bcb0169-3007-4bd8-82e4-e5307066d2ee/shared-mailbox-sent-items-email-automation.jpg) ### The responsibility shifts from Outlook to your code With interactive Outlook use, Exchange and the client hide a lot of sent-item behavior behind mailbox settings and delegate logic. API and service-driven sending expose that complexity. SMTP, Microsoft Graph, and EWS all send mail differently, and none of them magically guarantee that the copy lands in the folder your operations team expects. That gap causes real pain in production. Delivery success only proves that the remote recipient got the message. It does not prove that your shared mailbox kept an auditable sent record, that the right mailbox owns the conversation history, or that another service can reconstruct the thread later. Identity is usually the sharp edge. An app might authenticate as a service principal, send as a shared mailbox, and log success in its own database while the mailbox itself shows nothing useful. From Exchange's point of view, those are separate concerns. If you do not model them explicitly, sent-item visibility becomes accidental. ### What developers should design for Treat sent-item handling as part of the send path, not a UI detail. - **Define the sender identity up front.** Decide whether the app sends as the shared mailbox, on behalf of it, or as a user with delegated access. The mailbox record you want later depends on that choice. - **Store message state deliberately.** If your API path does not create the sent copy you need, write that requirement into the workflow instead of assuming Exchange will infer it. - **Test with production-like permissions.** Broad admin access in development hides the exact permission failures that break mailbox history in staging or production. - **Separate transport from auditability.** A 202 Accepted from Graph or a successful SMTP handoff does not mean your support team can see the sent message where they expect it. - **Log mailbox context with each send.** Capture the mailbox identifier, auth path, permission mode, and message ID. Without that data, post-incident debugging turns into guesswork. I have seen teams verify only that the email arrived and call the integration done. That is enough for a demo. It is not enough for a shared mailbox that multiple humans, automations, and now AI agents depend on for case history. If you are building the sender in Python, the mechanics of auth, message creation, and delivery affect where your operational trail lives. This guide on [sending email with Python for application workflows](https://robotomail.com/blog/how-to-send-email-with-python) is useful because it treats email as system behavior, not just a button in a mailbox client. ### The architecture question teams put off too long Shared mailboxes were built for delegated human work. They can support automation, but only if someone owns the edge cases around permissions, sent copies, retries, threading, and audit logs. That trade-off matters more now that AI agents are sending mail. If an agent is using a shared mailbox as its working memory, Sent Items stops being a convenience folder and becomes part of the application state. At that point, every missing or misplaced message is a data integrity problem. For a small internal script, bolting that logic onto Exchange may be fine. For agent fleets, support automation, or multi-tenant product workflows, it is usually a sign that the mailbox model and the application model are fighting each other. That is the boundary where classic PowerShell fixes still help, but purpose-built agent email platforms start making more sense. ## How Robotomail Simplifies Sent Item Management The cleanest way to avoid shared mailbox sent items problems is to stop forcing application workflows into the delegate model that created the problem in the first place. ![Screenshot from https://robotomail.com](https://cdnimg.co/9a227681-63f7-452a-a677-fb77b6767eba/screenshots/9c1a454b-1223-4823-aa9a-b0c09141d6a9/shared-mailbox-sent-items-robotomail-landing-page.jpg) Robotomail is built as **email infrastructure for AI agents**, and that architectural choice matters more than any Outlook setting. Instead of treating an automated sender like a weird extension of a human mailbox, Robotomail gives an agent its own real mailbox through API, CLI, or SDK provisioning. That removes the classic split where one identity sends and another identity accidentally owns the sent record. ### Why the old problem disappears With a traditional shared mailbox, you're always negotiating between at least two actors: the mailbox identity and the delegate who performs the send. That's where sent-item confusion begins. Robotomail avoids that by making the mailbox programmatic from the start. An agent can create a mailbox with a single API call, send from that mailbox, receive into that mailbox, and preserve conversation context through automatic threading. There's no SMTP setup, no OAuth dance, and no human-in-the-loop provisioning step required just to give the agent a usable inbox. That changes the sent-items conversation completely. You're no longer asking Exchange to copy a message from a sender's personal Sent Items into a shared folder for team visibility. The mailbox history already belongs to the sending identity. ### What this means for developers For developers building autonomous workflows, the practical advantages are straightforward: - **Mailbox creation is native to the platform**. Agents don't need a human admin to pre-create and wire up a shared mailbox. - **Inbound handling fits modern systems** through webhooks, server-sent events, or polling, with HMAC signing for integrity. - **Conversation state is preserved** with automatic threading, which is what teams usually wanted from shared mailbox history in the first place. - **Operational controls exist at the mailbox level** such as rate limiting, suppression lists, storage quotas, attachment handling, and presigned URLs. That's a much better fit for agent stacks using Claude, Gemini, LangChain, CrewAI, or AutoGen than trying to bolt API behavior onto a mailbox model designed around Outlook delegates. A practical starting point is Robotomail's guide to [setting up an agent mailbox easily](https://robotomail.com/blog/easy-install-mailbox). It shows the model clearly: create the mailbox the app owns, then build send and receive logic on top of that mailbox directly. ### The bigger operational win The primary gain isn't convenience. It's data integrity. In the Microsoft 365 shared-mailbox pattern, visibility depends on flags, permissions, client behavior, and old workstation state. In an agent-native mailbox model, the mailbox itself is the system of record. That's much easier to reason about, much easier to audit, and much less likely to fail in ways your application never notices. ## Your Shared Mailbox Sent Items Checklist If shared mailbox sent items are broken, don't troubleshoot by instinct. Work through the scenario you're in. ![An infographic checklist for managing sent items in a shared mailbox, detailing server settings and user permissions.](https://cdnimg.co/9a227681-63f7-452a-a677-fb77b6767eba/1826596c-a365-40dd-81e9-27e9dbf0e321/shared-mailbox-sent-items-checklist.jpg) ### If you send from Outlook and can't find the message First, assume the message may be in your personal Sent Items instead of the shared mailbox. That's the default behavior. **By default, `MessageCopyForSentAsEnabled` is disabled, and a message sent from a shared mailbox is stored only in the sender's personal Sent Items.** Enabling that setting in PowerShell is the first step to getting shared visibility. Then ask your admin one direct question: was the shared mailbox configured for the permission type you used? ### If you administer shared mailboxes Use a repeatable setup checklist instead of fixing this after users complain. - **Set both mailbox flags when appropriate** so Send As and Send On Behalf are both covered where your workflow needs them. - **Verify each mailbox individually** because these settings are mailbox-specific. - **Test with a real delegated account** instead of assuming PowerShell success means user success. A simple setup habit prevents a lot of operational noise later. ### If users report duplicates Look for conflicting old fixes before touching server settings again. - **Check for desktop-specific workarounds** on previously modified machines. - **Review any policy-driven delegate behavior settings** if only some users see duplicates. - **Retest in Outlook on the web** to separate Exchange behavior from local Outlook behavior. > Shared mailbox duplicate issues usually mean two systems are trying to be helpful at the same time. ### If you build app or agent integrations Don't treat mailbox history as accidental. Define it. 1. Decide whether the app sends **as** the mailbox or **on behalf of** it. 2. Make sure the permission model matches that decision. 3. Test that the sent record lands where operators expect to find it. 4. If your workflow is heavily automated, consider whether a human-delegate mailbox model is the wrong foundation. ### If you need reporting and auditability Remember that visibility and reporting are not the same thing. Shared-mailbox activity metrics in the Microsoft 365 Admin Center depend on licensing or auditing configuration. If reporting matters, validate your measurement path instead of assuming mailbox behavior alone solves observability. That's the broader lesson with shared mailbox sent items. The pain isn't mysterious. It comes from defaults, from permission mismatches, and from years of layered workarounds. Once you treat it as a systems problem, it becomes manageable. --- If you're building AI agents that need a real mailbox without shared mailbox quirks, [Robotomail](https://robotomail.com) is a cleaner foundation. It gives agents API-native mailboxes with send, receive, threading, webhooks, and mailbox lifecycle control built in, so you don't have to fight Outlook-era delegate behavior just to preserve sent history.