If you’ve been working with Microsoft Purview eDiscovery for any length of time, you’ve likely run into a bit of a headache regarding BCC and Distribution List (DL) emails. It’s a common scenario: you’ve set up your search, added your custodian’s email address into the ‘Participants’ or ‘Recipient’ condition in KQL, and assumed you’ve captured everything.
Unfortunately, because of how Microsoft 365 is built, you are almost certainly missing data.
The Problem with Modern Indexing
For those who have spent years working with legacy on-premises eDiscovery solutions—like Enterprise Vault or Relativity—this wasn’t an issue. Those systems typically used "Envelope Journaling." When an email was sent, it was wrapped in a P1 envelope that contained every single recipient's details. Even if a user was hidden in the BCC field or was just one name in a 500-person Distribution List, the index saw them because the envelope expanded that data.
Microsoft Purview works differently. It searches "in-situ" within the Substrate (the underlying data layer for M365). When an email lands in a recipient's mailbox, Purview indexes the actual headers of that item.
The issue is that:
BCC details are stripped from the recipient’s copy of the email for privacy.
Distribution Lists aren’t expanded in the header; the "To" field simply shows the group address, not the individuals within it.
Because the custodian’s individual email address isn't physically in the header of the item in their mailbox, a KQL search for their name or email address will simply fail to find a match.
Sender vs. Recipient Context
It’s worth noting that if you happen to be searching the sender’s mailbox, you’ll see those BCC and DL details perfectly fine in their "Sent Items." But in eDiscovery, we are often working in a recipient context. If the sender is an external party, or if you only have access to the recipient's mailbox, that metadata simply doesn’t exist in a searchable format within those headers.
Because this is a fundamental part of the Exchange Online architecture, it’s unlikely that Microsoft will be able to "fix" this. The data items in the Substrate simply don't contain the recipient expansion required for a traditional header match.
A More Reliable Solution
Rather than trying to force an "Include" query that relies on missing header information, I’ve found that we need to change our approach. We need to stop searching for who the email was sent to and instead focus on the container (the mailbox) and the received context.
The strategy is simple:
Target the specific user's mailbox.
Query for everything in that mailbox.
Filter for email items only.
Filter out the items the user sent to others (to remove the noise of their Sent Items).
Keep items the user sent to themselves (self-notes/reminders).
Why this works
Captures BCC/DL Traffic: By ignoring the recipient headers and focusing on the fact that the item was delivered to the mailbox(es), you catch everything.
Filters Out the "Noise": Using kind:email ensures you aren’t bloating your data set with calendar invites, tasks, or system notifications.
Isolates Incoming Mail: We filter out anything sent by the mailbox owner unless they sent to themselves (we want to capture that)
One Vital Pro-Tip
A word of caution: You must target specific custodian mailboxes for this to work.
Do not try to run this as a tenant-wide search. Because this query doesn't specify a person's name, running a search across your entire organisation would return every single email received by every single employee during that timeframe.
By targeting the specific mailboxes and using this method, you bypass the architectural limitations of Purview and ensure your collection is both thorough and defensible. It’s a much safer way to ensure those "invisible" BCC and DL emails don't slip through the cracks.
