Why Email DLP Misses Anonymous OneDrive Share Links

Here is a scenario that plays out in security reviews more often than it should.

An employee composes an email. They attach a financial spreadsheet from Q3. The DLP engine scans it, matches a sensitivity rule, and blocks the message. The employee is not happy, IT is called, an exception is filed.

Two hours later, the employee sends a second email. Same spreadsheet. This time they upload it to OneDrive, set the link to Anyone with the link can edit, paste that link into the body of the email, and sends it to the same recipient.

The DLP does not block this message. There is no alert. The security team has no record of the second email leaving.

The file left the building both times. The DLP caught the first method and completely missed the second.

This is not a configuration error. It is a gap built into how email DLP engines work.

Why DLP Inspects Attachments But Not Share Links

Email DLP operates on the email message as it passes through the mail transport agent. When an attachment is present, the DLP engine can:

Extract the file from the MIME structure
Fingerprint the content using data classification rules
Match it against known sensitive data patterns (PII, financial data, credentials)
Block or quarantine the message based on policy

When the content is a URL pointing to a OneDrive file, the DLP engine is looking at text, not a file. The URL is a pointer to content hosted outside the email channel, on a SaaS platform that the DLP has no live connection to at the time of scanning.

There are three reasons this matters.

First, URL inspection does not mean content inspection. A DLP rule that scans for sensitive keywords in email bodies will not catch a OneDrive link that contains no describable content in the URL itself. The link https://contoso-my.sharepoint.com/personal/user/Documents/Q3_Financials.xlsx tells the scanner nothing about what is actually inside that file.

Second, dynamic content changes after the email passes. The file attached to an email is static. The file accessible via a share link can be changed, updated, or replaced after the email has already been delivered, with no new DLP scan triggered.

Third, anonymous access means no authentication context. When a DLP policy evaluates whether a user should be allowed to send something, it relies on authentication context from the sender's email session. An anonymous share link strips that context entirely. The link works for anyone who has it, regardless of who sent or received the original email.

Where Microsoft Purview and Other DLP Products Stand

Microsoft Purview DLP has explicit policies for SharePoint and OneDrive. In the Purview compliance portal, you can configure DLP policies that:

Scan files at rest in SharePoint and OneDrive
Block external sharing of files classified as sensitive
Alert on anonymous OneDrive link creation

These policies operate at the SharePoint/OneDrive layer, not the email layer. They are designed to catch sharing behavior inside the Microsoft 365 environment.

The email DLP and the SharePoint DLP are separate policy engines. An outbound email containing a OneDrive link passes through the email DLP scanner, which does not query the SharePoint DLP policies in real time. If the SharePoint DLP policy is not configured to block anonymous link creation for that file type, or if the file was uploaded before the policy was applied, the link goes through.

The practical result is that an employee who triggers the email DLP on an attachment can often work around it by uploading to OneDrive and pasting a link instead. The email DLP has no mechanism to recognize that the link and the attachment are the same file.

Other enterprise DLP products, including Symantec DLP and Zscaler Email DLP, have the same fundamental limitation. Their email DLP engines inspect message content and attachments at the transport layer. They do not perform real-time dereferencing and content inspection of URLs pointing to external SaaS storage.

The gap is not a vendor failure. It is a architectural boundary between email DLP and CASB enforcement that most organizations have not fully closed.

How to Find This Gap in Your DLP Logs

If you are running Microsoft Defender for Office 365 or Microsoft Sentinel, the gap is visible in your DLP alert data.

In Microsoft Defender, run a DLP alert search for the past 30 days. Filter by:

Policy: your file attachment DLP policy
Action: Blocked

Now cross-reference that with SharePoint/OneDrive sharing audit logs. In the SharePoint admin center or via the Unified Audit Log, look for:

SharingLinkCreated events where the link scope is Anonymous or Anyone
The file name or path matches or resembles files involved in your DLP attachment blocks

The pattern you are looking for is: an employee triggered an attachment block, then shortly after created an anonymous share link to the same or a similar file, then presumably sent that link via email or another channel.

In practice, this correlation is not easy to do manually. The audit logs for email DLP and SharePoint sharing are in separate systems. A security analyst would need to manually cross-reference timestamps, file names, and user accounts across two or three log sources to confirm the gap was exploited.

This is where cross-channel monitoring becomes necessary, not optional. DMARCFlow monitors outbound email by analyzing DMARC aggregate reports, which means it sees every authenticated source sending mail on behalf of your domain. If an employee attempts to work around a DLP block by sending the same file from a personal email account, or if a third-party application starts sending mail that resembles blocked content patterns, DMARCFlow flags that discrepancy between expected and actual sending sources. The share link itself bypasses email DLP because it is a URL, not a file. But the act of sending that link from an unauthorized source, or the follow-on activity of a file being accessed via an anonymous link by an external party, creates signals that DMARCFlow can pick up from the email channel when traditional DLP cannot.

What Monitoring Controls Close This Gap

There is no single DLP policy that closes this gap completely. The solution is a layered approach across three areas.

CASB enforcement for SharePoint and OneDrive. If your organization uses Microsoft 365, enable Purview DLP policies for SharePoint Online and OneDrive. These policies run at the storage layer, not just the email layer, and can block or alert when sensitive files are shared via anonymous links regardless of how the link was delivered.

Email DLP extension to URL scanning. Some email DLP vendors offer URL rewriting and click-time verification, where links in outbound email are rewritten to pass through a proxy that checks the user's authorization at click time. This does not inspect the file content behind the link, but it can enforce that the recipient is authenticated to the organization's tenant before the link resolves.

Cross-channel monitoring with DMARCFlow. The most practical near-term step for email security teams is to monitor outbound email signals that DLP does not cover. DMARCFlow reads your DMARC aggregate reports daily and alerts when new sending sources appear, when legitimate sending patterns change unexpectedly, or when mail is being rejected due to policy violations you did not configure. If an employee bypasses attachment DLP using a share link sent from a personal account or an unauthorized third-party app, DMARCFlow can surface that discrepancy because it sees all authenticated sending activity for your domain, not just what your DLP policy caught. This is not a CASB replacement, but it is the monitoring layer that makes your DLP alerts meaningful: without cross-channel context, a blocked attachment event tells you one attempted exfiltration path was closed, not whether others remain open.

Three Things to Check This Week

1. Run a DLP alert report for the last 30 days. Note every blocked attachment event. Now check your SharePoint/OneDrive sharing audit log for the same users and similar file names within 48 hours of each block. The overlap is your gap indicator.

2. Open your SharePoint admin center, go to Sharing policies, and check what the default anonymous link expiration is set to. If it is set to never or more than 30 days, that is an easy policy win to tighten.

3. Check whether your email DLP policy has any rules that inspect URLs in message bodies for patterns that indicate SaaS file sharing. If it only matches on attachment content, that is the architectural boundary to document and address.

The attachment DLP gap is real and documented. It is not a failure of your current DLP configuration. It is a scenario that most DLP policies were not designed to handle because it operates across the boundary between email inspection and SaaS sharing controls. Understanding where that boundary sits is the first step to closing it.

FAQ

Does Microsoft Purview DLP block OneDrive share links in emails?

Purview DLP has separate policies for email and for SharePoint/OneDrive. The email DLP component does not inspect the content behind a OneDrive link in an email body. The SharePoint/OneDrive DLP component can block or alert on anonymous sharing at the storage layer, but that enforcement happens independently of the email DLP scan. For full coverage, you need both policy layers configured.

How can I detect link-based exfiltration in my DLP logs?

Look for the sequence across two log sources: blocked attachment events in your email DLP logs, followed by anonymous SharePoint/OneDrive sharing events in your SaaS audit logs for the same user around the same time. In Microsoft environments, this means cross-referencing Defender for Office 365 DLP alerts with the SharePoint/OneDrive Unified Audit Log. Manual correlation is time-consuming, which is why cross-channel monitoring tooling earns its place here.

What closes the gap between DLP attachment scanning and SaaS share link inspection?

A CASB layer that enforces sharing policies at the SharePoint/OneDrive storage level closes the structural gap. In Microsoft 365 environments, this means Purview DLP policies for SharePoint and OneDrive configured to block or restrict anonymous sharing of sensitive file types. URL rewriting at the email gateway adds a second layer by enforcing authentication at click-time for outbound links. Cross-channel monitoring ties the two together so security teams can see the full picture.