SIT matches, but email Not Being Blocked

Hello Nate,

Welcome and thank you for posting your query on Microsoft Q&A!

Based on your description you've successfully tested the sensitive information type using the Purview's "test" feature and the Test-DataClassification PowerShell cmdlet. However, ensure that you are checking the specific conditions under which the DLP policy should trigger. Sometimes, slight syntax changes or different conditions can lead to mismatches.

File Attachment Types: If there are specific types of file attachments causing issues, verify whether the DLP policy is set to evaluate those specific attachments. Sometimes, file types that aren't explicitly allowed can be overlooked.

you need to make sure your DLP rules are set up to scan attachments and the correct file types. The Purview test tools can already detect this, but the Exchange transport engine (which enforces the DLP policy during mail flow) only scans what you explicitly configure.

In the Purview Portal:

1. Go to Microsoft Purview portal -> Data loss prevention -> Policies.
2. Edit the policy that should be blocking these emails.
3. Open the affected rule.
4. In the Conditions, make sure you include:
5. Content contains ->Sensitive info types (your SITs).
6. File type is ->add the file types you want scanned (e.g., .zip, .docx, .xlsx, .pdf).
7. Save and republish the policy.

In PowerShell:

# Connect to Exchange Online
Connect-ExchangeOnline -UserPrincipalName ******@contoso.com
# Check current rule settings
Get-DlpComplianceRule -Identity "Block SSN in Attachments" | FL Name,FileType,EnableFileTypeDetection,InspectContentInCompressedFile
# Enable file type detection and allow scanning inside compressed/nested files
Set-DlpComplianceRule -Identity "Block SSN in Attachments" `
-FileType @("docx","xlsx","pdf","zip") `
-EnableFileTypeDetection $true `
-InspectContentInCompressedFile $true

Re-run your test using Test-Message or send a test email with the attachment. Let us know if you still facing same issue.

Please refer these Microsoft documents for more details:

https://learn.microsoft.com/en-us/purview/sit-sensitive-information-type-learn-about

https://techcommunity.microsoft.com/blog/microsoft-security-blog/scenario-based-troubleshooting-guide---dlp-issues/3445489

Hope this helps! If it does, please Upvote and Accept Answer so others in the community can find it useful. You’re also welcome to share your own suggestions or solutions for the benefit of others facing similar issues.

Thanks,

Kalyani

Hello Kalyani,

You mentioned syntax changes, but the policies have been completely unchanged since February.

You said that "Sometimes, file types that aren't explicitly allowed can be overlooked." First of all, that's not even true. That's not true at all.
Purview DLP does not specifically require you to specify specific file types before the scanning occurs. Again, the policies work, and most file attachments are scanned just fine, it's just random ones that don't.
(For what it's worth, the file types are PDFs, which are obviously covered by Purview DLP policies in Exchange.)

You mentioned "Set-DlpComplianceRule" with a flag of FileType, but that PowerShell cmdlet doesn't even have a flag of "FileType". There's a flag called ContentFileTypeMatches, but that flag is undocumented (additionally, I shouldn't need to set that flag if I want it to scan all attachments.)
Additionally, you said that this cmdlet has a flag called "EnableFileTypeDetection", however, that cmdlet does not have this flag; it doesn't exist.

I've reviewed that documentation you provided, but there's still 0 indication as to why the SIT matches (Test-DataClassification), but the policy doesn't match (Test-Message). Again, it does work for most file attachments! It's just random file attachments which don't work.

Hello Nate,

Thanks for your response, I can understand your frustration on ongoing things, I asked about syntax changes because there's a chance someone might've accidentally updated the policies without realizing it.

I have given that document to verify your SIT information is aligned with the rules or not.

• Sometimes multiple DLP policies can conflict with each other. Ensure that there’s no other policy that could be allowing these emails to go through in spite of the SIT match.
• What specific file types are you testing that are not being blocked? You have confirmed that its happening for some random files right.

Thanks!

Kalyani

Hello Kalyani,

Thank you for your response. Here's my answer to your questions:

• There are no policies that would be conflicting with each other, we did have to make a separate policy to handle "policy tips" since policy tips aren't supported on policies that contain the "Message type is" attribute (https://learn.microsoft.com/en-us/purview/dlp-owa-policy-tips).

So basically, we have one policy which will put a policy tip on the email if "SIT 1" is detected (which is set to be "in simulation with notification" so that no actual blocking is performed), and another policy that actually blocks the email if "SIT 1" is detected unless "Message type is" is set to "Permission Controlled" -- the 2nd policy actually blocks the emails.
And the policies almost always work with no problems.

• There's only very specific PDF files that aren't being caught. Even though Purview successfully detects "SIT 1" with 85% accuracy on these problematic files -- if you use "Test-DataClassification" or upload to Purview directly -- they aren't blocked for some reason. Most PDF files with "SIT 1" are blocked just fine.

Thanks!

Hello Kalyani,

It's looking like the 2nd reason might be the cause; I was unaware that "Test-DataClassification" uses more advanced parsing than the enforcement engine. Maybe that's it.

Thanks for your help!