New Outlook Data Loss Prevention: Confirm DLP policy behavior in New Outlook

Data Loss Prevention or DLP policies in Microsoft 365 help prevent sensitive information from leaving your organization through email. When you switch to New Outlook, DLP rules that worked in classic Outlook may behave differently because the new client uses a different architecture. This article explains how DLP policies apply in New Outlook, how to test and confirm they are working correctly, and what to do if a policy does not trigger as expected.

DLP in New Outlook relies on the same Microsoft Purview compliance portal as classic Outlook, but the enforcement point shifts to the server side. Understanding this change helps you verify that your existing policies still protect sensitive data. You will learn the exact steps to test a DLP policy, interpret the results, and troubleshoot common failures specific to New Outlook.

Why DLP Policy Behavior Differs in New Outlook

New Outlook for Windows is built on a web-based platform that uses the same Microsoft 365 backend as Outlook on the web. This means DLP enforcement happens primarily on the server before the email is sent, rather than on the client. In classic Outlook, DLP rules can run locally through the Outlook client and the Exchange Online add-in. In New Outlook, the client simply displays the result of a server-side DLP evaluation.

This shift has two main effects. First, DLP policy tips appear in New Outlook only if the server sends them back to the client. Second, any custom DLP rule that depends on a client-side action like a custom property written by an Outlook add-in may not trigger in New Outlook. The Microsoft Purview compliance portal remains the single source of truth for all DLP policies regardless of the email client.

Steps to Confirm DLP Policy Behavior in New Outlook

Follow these steps to create a test DLP policy, send a matching email from New Outlook, and verify the policy fires correctly.

1. Create a test DLP policy in Microsoft Purview
   Go to the Microsoft Purview compliance portal. Select Data Loss Prevention then Policies. Click Create policy. Choose Custom then Next. Give the policy a name like Test DLP New Outlook. Select a location and enable Exchange. Click Next. Under Rules, click Create rule. Name the rule Test SSN Block. For Condition, select Content contains then Sensitive info types. Add U.S. Social Security Number SSN. For Action, select Restrict access or encrypt the content. Set the action to Block people from sending email. Set the user notification to Notify users with a policy tip. Finish the wizard and wait 15 minutes for the policy to replicate.
2. Open New Outlook and compose a test email
   Launch New Outlook for Windows. Click New Mail. In the To field, enter any internal recipient within your organization. In the Subject line, type DLP Test. In the body, paste a realistic SSN like 123-45-6789. Do not use a real person’s SSN. Microsoft 365 will detect the pattern regardless of the numbers you use.
3. Look for the DLP policy tip before sending
   After pasting the SSN, wait a few seconds. New Outlook sends the content to the server for evaluation. The server returns a policy tip if the rule matches. The tip appears as a yellow bar above the message body with text similar to This message contains sensitive content. It may also show a Send Anyway link if the policy allows override. If the policy is set to block, the Send button will be grayed out.
4. Check the activity log in Microsoft 365 Defender
   Open Microsoft 365 Defender. Go to Reports > Data loss prevention. Click View activity for DLP rules. Filter by the policy name Test DLP New Outlook. You should see an entry with the subject DLP Test and the action Blocked or Allowed with override. This confirms the server processed the email against the DLP rule.
5. Test a non-blocking rule to verify policy tip delivery
   If you set the action to Audit only, the email will send but a policy tip still appears. Create a second rule that only audits. Send another test email. The policy tip appears in New Outlook and the activity log shows Audited. This confirms that New Outlook can display server-side policy tips even when no block is enforced.

If DLP Policy Does Not Trigger in New Outlook

Policy tip does not appear after pasting sensitive data

Wait up to 30 minutes after creating or editing a DLP policy. Microsoft 365 needs time to replicate policy changes across all servers. If the tip still does not appear, check that the recipient is an internal user. DLP rules in Exchange only evaluate messages sent within the organization by default. Also confirm that the sensitive info type you used is enabled in the Microsoft Purview compliance portal under Data classification > Sensitive info types.

Policy tip appears in Outlook on the web but not in New Outlook

New Outlook uses the same server-side evaluation as Outlook on the web. If the tip appears in the browser version but not the desktop version, clear the New Outlook cache. Go to Settings in New Outlook > General > About New Outlook. Click the Clear all cached data button. Restart New Outlook and test again. A corrupted local cache can prevent policy tips from rendering.

DLP rule blocks email but no policy tip is shown

This usually happens when the policy is configured to block silently without user notification. In the Microsoft Purview compliance portal, edit the rule and expand User notifications. Make sure Notify users in Office 365 with a policy tip is checked. Also confirm that the notification text is not empty. Save the policy and wait 15 minutes before retesting.

Custom sensitive info types are not detected

Custom sensitive info types that rely on a specific keyword or regex pattern may not match if the format of the data in the email body differs slightly. Test with the exact pattern defined in the custom type. You can also run a trial classification in the Microsoft Purview compliance portal under Data classification > Trainable classifiers to see if the content matches.

Item	Classic Outlook DLP	New Outlook DLP
Enforcement location	Client-side via Exchange add-in	Server-side via Exchange Online
Policy tip delivery	Local rule evaluation	Server sends tip to client
Custom add-in support	Can trigger rules via custom properties	Does not support client-side add-in triggers
Cache dependency	Minimal	Local cache can block policy tips
Policy replication time	Up to 1 hour	Up to 30 minutes
Block action behavior	Blocks send immediately	Blocks send after server evaluation

Now you can confirm that your DLP policies work correctly in New Outlook by creating a test policy, sending a matching email, and checking the activity log. Next, verify that all production DLP rules that rely on client-side triggers are updated to use server-side conditions. A practical next step is to review the Microsoft Purview audit log weekly for DLP matches from New Outlook to catch any policy gaps early.