Forum Discussion
Thousands of Sent Items moved to Deleted Items, no rules, no retention
Hello everyone,
I'm investigating a very unusual Exchange Online mailbox issue and would appreciate any insights from anyone who has seen something similar.
Environment
- Exchange Online (Microsoft 365)
- Mailbox: User mailbox
- Outlook for Mac
- Outlook for iOS
- Outlook Web (OWA)
Incident Summary
On August 13, 2026, approximately 4,997 messages were moved from:
The activity occurred over roughly a 3-hour period.
Mailbox audit logs show thousands of:
Operation: MoveToDeletedItems
events.
Hourly breakdown:
01:00 - 2,046 events
02:00 - 1,540 events
03:00 - 1,408 events
Audit Findings
All sampled audit events show:
LogonType = 0 (Owner)
UserId = affected mailbox owner
Result = Succeeded
I sampled 5,000 records and all of them were:
LogonType = 0
No events were recorded as:
LogonType = 1 (Admin)
LogonType = 2 (Delegate)
Source and Destination Folders
Examples from mailbox audit records:
Folder : \Sent Items
Destination : \Deleted Items
Operation : MoveToDeletedItems
Message Trace Findings
Extended Message Trace was performed on one of the affected emails.
The trace confirmed:
CopiedToSentItems=True
DeleteAfterSubmit=False
which indicates:
- The email was successfully sent.
- The email was copied to Sent Items.
- Exchange did not delete the message during transport.
So the message existed in Sent Items and was later moved to Deleted Items by a mailbox operation.
Rules Investigation
Checked:
Get-InboxRule -Mailbox <mailbox> -IncludeHidden
Findings:
- No Inbox Rules targeting Sent Items.
- No hidden Inbox Rules targeting Sent Items.
- Only two legitimate rules that delete messages from specific Jira/Confluence senders.
Delegation Investigation
Mailbox permissions reviewed.
Known permissions exist, but mailbox audit logs show:
5000/5000 sampled events = LogonType 0
Therefore:
- No evidence of delegate activity.
- No evidence of administrative activity.
Retention / Compliance Investigation
Checked:
Get-Mailbox
Get-RetentionPolicy
Get-RetentionPolicyTag
Get-RetentionCompliancePolicy
Get-RetentionComplianceRule
Findings:
- No Sent Items retention tag.
- No retention policy targeting Sent Items.
- No Purview retention/compliance policy appears to explain this behavior.
- Activity pattern does not resemble normal retention processing.
Add-ins Investigation
Mailbox add-ins:
Polls
Share to Teams
Send to OneNote
Action Items
Bing Maps
My Templates
Unsubscribe
No third-party mailbox-management or archiving add-ins found.
Client Information Seen During Investigation
Examples observed in mailbox audit logs:
Client=OutlookService;MacOutlook/16.112
a { text-decoration: none; color: #464feb; } tr th, tr td { border: 1px solid #e6e6e6; } tr th { background-color: #f5f5f5; }
What Has Been Ruled Out
✅ Admin activity
✅ Delegate activity
✅ Inbox Rules
✅ Hidden Inbox Rules
✅ Outlook add-ins
✅ MRM retention policies
✅ Sent Items retention tags
✅ Purview compliance retention policies
✅ Exchange transport deleting the messages
Question
Has anyone encountered a similar case where:
Thousands of messages were moved from Sent Items to Deleted Items
Operation = MoveToDeletedItems
LogonType = 0 (Owner)
No rules
No retention policy
No delegate activity
particularly involving:
Outlook for iOS
Outlook for Mac
Client=OutlookService
Any similar experiences, findings, or recommendations would be greatly appreciated.
As we need to know the root cause for this issue.
Thanks
2 Replies
- ahmadmahmoud2020Copper Contributor
Thank you for the feedback.
We have already reviewed the mailbox audit logs extensively for the incident period and confirmed the following:
- Approximately 4,997 MoveToDeletedItems operations affected messages in Sent Items.
- All sampled records show LogonType = 0 (Owner).
- No Inbox Rules (including hidden rules), retention policies, compliance policies, delegate activity, or administrative actions were identified.
- Message Trace confirms affected messages were successfully copied to Sent Items (CopiedToSentItems=True, DeleteAfterSubmit=False) and were not removed by Exchange transport.
- Audit records associated with the bulk Sent Items deletion activity consistently show:
Plain Text
1
ClientInfoString:
2
Client=OutlookService;MacOutlook/16.112.26081010;
3
4
ActorInfoString:
5
MacOutlook/16.112.26081010 (ARM64 Mac OS X 26.5.2 Build 25F84)
Show more lines
We agree that LogonType=0 does not identify the specific user action performed, and that mailbox auditing alone does not conclusively identify the exact physical device. However, Microsoft Support has already indicated that they have seen similar Outlook for Mac cases, so we are currently working with Microsoft to correlate affected Message IDs and audit records with their backend telemetry.
At this stage, the evidence points to a client-originated mailbox action rather than retention, transport, rules, delegation, or server-side processing.
he audit evidence confirms an owner-context move, but LogonType 0 does not identify the human action or exact client. ClientInfoString, ClientIPAddress, SessionId, LogonUserSid, and timestamps are the fields that can narrow it down. Export the full audit records for the three-hour window, group them by session and client IP, and compare those values with Microsoft Entra sign-in logs. The MacOutlook value indicates an Outlook service path, not conclusively a Mac user gesture. Temporarily remove the mailbox from iOS and Mac clients one at a time and check whether new move events stop. Preserve and restore the affected messages from Deleted Items before further testing. If any sign-in is unfamiliar, reset the password and revoke sessions immediately. Check Microsoft 365 service health. With rules, retention, delegates, and transport already excluded, Microsoft Support will need the exported audit JSON, timestamps, tenant, mailbox, and session identifiers to determine the server-side origin.