Recently, i faced a challenge : a massive mailbox, nearly 800 GB in size, needed to be drastically reduced to under 100 GB for a migration. The solution? Deleting old emails. But what happened next was completely unexpected.

The Situation

My Customer had a central service mailbox that had grown significantly over the years and needed urgent cleanup. After discussion, it was agreed that everything before January 2024 could be deleted. To minimize risk, we started with a careful test run deleting emails from Q1 2018 first.

And then we noticed something strange.

Suddenly, Read Receipts Were Being Sent

Shortly after the first cleanup run, we discovered that many old emails were automatically triggering read receipts (empty mails with just ‘Not Read:’ in the subject). These were messages where the original sender had requested a delivery confirmation sometimes years ago.

But why was this happening?

This behavior has actually been known in Outlook since 2003. Normally, when you delete such emails manually, Outlook displays a small window asking for confirmation before sending a read receipt. However, in our case, everything happened silently in the background because the deletion was performed via PowerShell rather than Outlook:

Search-Mailbox -Identity "service@company.com" -SearchQuery "Received:<01/01/2018" -DeleteContent

No prompt. No warning. No official documentation mentioning this behavior. Yet Exchange was suddenly sending emails without any visible confirmation or request.

The reason we opted for Search-Mailbox was that it was the only viable method in this case.

• Mounting the mailbox in Outlook or using MFCMAPI was not an option—the mailbox was simply too large to be added.
• Compliance rules take too long to take effect, which was not practical for this cleanup.
• E-Discovery features are not designed to handle such large-scale deletions efficiently.

Given these constraints, Search-Mailbox was the only feasible choice to remove the data in a controlled and efficient manner. However, what we didn’t expect was that this would lead to automatic email transmissions in the background.

In my opinion, this should never happen.

The Transport Rule as a Safety Net

To stop the outgoing read receipts, we quickly set up a transport rule to block and delete them. We ran extensive tests:

• The rule was activated, and emails were successfully blocked.
• We set the filter firstly for hours, then for days, then for an entire quarter.
• No more read receipts were sent.

With everything looking stable, we gave the final go-ahead to clean up the entire mailbox.

Then It Happened – 4,800 Emails Were Sent Anyway

Despite the active transport rule, Exchange still sent 4,800 read receipts, while correctly blocking 13,000 others.

This raised two major questions.

Why does Exchange send emails when deleting messages?

• It’s known that Outlook does this, but via PowerShell and a centrally deletion-function?
• There is no mention of this behavior in official Microsoft documentation.

Why did some emails bypass the transport rule?

• We suspect the Exchange server hit internal, hidden limits that caused the rule to stop working consistently.
• When too many emails were processed at once, the rule might have been ignored.

We found messages such as “SenderExceededSubmissionRateLimit” in some of the event data related to the successfully sent emails. This serves as one indicator that the Transport Rule may have been overwhelmed by the sheer volume of emails being processed.

Lessons Learned – What We Took Away from This

• Even well-tested rules can fail in real-world scenarios, especially when encountering undocumented system limits.
• Deleting emails doesn’t always just remove them it can trigger unexpected processes buried deep within the system.
• Exchange still holds surprises, and when Microsoft provides no documentation, the only option is learning by doing.
• If an additional mail gateway is in place, it’s crucial to review and activate compliance rules there as well. This can serve as a backup mechanism in case Exchange does not enforce its transport rules correctly.