Exchange Online Mail Flow Rules to stop supporting DLP-related rules, conditions, and actions
Published Oct 19 2023 03:24 PM 37.7K Views

In July 2023 we announced the discontinuation of support for all DLP-related functionality within Exchange Online Ma..., and encouraged admins to finish migrating any remaining DLP-related mail flow rules to Microsoft Purview DLP. In August we stopped supporting mail flow rules (also known as Exchange Transport Rules or ETRs) that are linked to Microsoft Purview DLP policies.

Today, we’re announcing that starting in the middle of November 2023 we’ll stop supporting the following DLP-related mail flow rules conditions and action:

Conditions

  • MessageContainsDataClassifications (message contains sensitive information)
  • ExceptIfMessageContainsDataClassifications
  • HasSenderOverride (sender has overridden the Policy Tip)
  • ExceptIfHasSenderOverride

Action

  • NotifySender

Starting in mid-November, the following will occur:

  • The ability to create or edit new ETRs that use these conditions or action will be disabled.
  • ETRs that use these conditions or action will not be evaluated nor run (as if the rule is disabled).
  • The Mail flow Rules page in the EAC and the Get-TransportRule cmdlet in Exchange Online PowerShell will show these ETRs are no longer supported (Configuration Supported and Unsupported Reason in the EAC, and IsRuleConfigurationSupported and RuleConfigurationUnsupportedReason in Exchange Online PowerShell).

Migration Process

Recreate your DLP-related mail flow rules in Microsoft Purview DLP then please delete those mail flow rules in the EAC. This will make it easier to manage your remaining mail flow rules and free up some of your mail flow rules quota.

Exchange Online Transport Team and Microsoft Purview Data Loss Prevention Team

21 Comments
Steel Contributor

@The_Exchange_Team Thanks for the head’s up. We manage many tenants and always monitor the Message Center. Any plans to push out Message Center messages to those tenants actively using these ETR rules or do we need to check each tenant config if it’s used?

Copper Contributor

So I have 8 ETRs that say "Support for DLP-related mail flow rules will stop in mid-November. See https://aka.ms/NoDLPinETRs."  But I when click Migrate Polices in Exchange Online nothing shows up to migrate.

@Jonas Back I was hoping we could, but sorry we won't be able to provide targeted MC posts to tenants using rules with these conditions. 

 

@Shawn Christian actually the wizard only migrates DLP policies and associated mail flow rules so mail flow rules without policies that use these DLP-related conditions and action don't qualify for migration with the wizard. You can export your rules using PowerShell and filter/search for the above conditions/action. Apologies for the misleading statement in the blog post, we'll correct it shortly. 

Copper Contributor

How will this affect inbound rules that use SIT? Assume we have a SIT for profanities, we block outbound using DLP and use the same SIT to block inbound using an ETR...

 

Thanks

@lukesrees Depends on your rule - if the rule uses any of the mentioned predicates above then that rule won't work come mid-November (early to mid-next week). If you're using something else for your profanity list like a simple expression check using the condition "SubjectOrBodyContainsWords" (aka "The subject or body includes any of these words" in the EAC UI) then it won't be affected. That said, you might consider just moving it to DLP along with your outbound DLP rule. Purview DLP supports both outbound and inbound mail flows (e.g. use Content is received from. . .People outside my organization). 

Copper Contributor

My current ETR's relating to credit Card blocking have been locked. How can I display the contents of those rules to allow me to recreate exclusions and other details in Purview. I have tried Get-TransportRule and it does not seem to be working. There is no banner for rule migration in Purview, so I am assuming my rules cannot be migrated?

Thanks

@Bobby_ono While the Edit option is disabled for rules that include DLP-related conditions and actions, you can still click on the rule in the EAC to expose the rule's fly-out panel summary where you can still see the rule's description including its predicates and actions. The rule migration banner in Purview will only show up for ETRs that have linked DLP-policies in them. For rules that have DLP-related conditions/action those can't be migrated with the DLP migration wizard and won't trigger the banner in Purview. Using PowerShell try these cmdlets:

1. Check if you have ETRs linked to DLP policies via Exchange Online PowerShell:

Get-TransportRule | where { $_.DlpPolicyId -ne [Guid]::Empty }

2. Check if you have any other ETRs that include DLP-related conditions or actions:

Get-TransportRule | where { $_.SenderNotificationType -ne $null -or $_.MessageContainsDataClassifications -ne $null -or $_.ExceptIfMessageContainsDataClassifications -ne $null -or $_.HasSenderOverride -eq $true -or $_.ExceptIfHasSenderOverride -eq $true }

Copper Contributor

Itried those both, am getting a cmd error

PS C:\Windows\System32> Get-TransportRule | where { $_.SenderNotificationType -ne $null -or $_.MessageContainsDataClassifications -ne $null -or $_.ExceptIfMessageContainsDataClassifications -ne $null -or $_.HasSenderOverride -eq $true -or $_.ExceptIfHasSenderOverride -eq $true }


Get-TransportRule: The term 'Get-TransportRule' is not recognized as a name of a cmdlet, function, script file, or executable program.
Check the spelling of the name, or if a path was included, verify that the path is correct and try again.

And 

PS C:\Windows\System32> Get-TransportRule | where { $_.DlpPolicyId -ne [Guid]::Empty }
Get-TransportRule: The term 'Get-TransportRule' is not recognized as a name of a cmdlet, function, script file, or executable program.
Check the spelling of the name, or if a path was included, verify that the path is correct and try again.

@Bobby_ono If the Get-TransportRule cmdlet isn't recognized it's likely one of two things:

  1. You haven't connected to Exchange Online PowerShell Connect to Exchange Online PowerShell | Microsoft Learn
    (be sure to import the ExchangeOnlineManagement module as stated in the doc)
  2. You don't have email or global admin permissions for your tenant.

If after following the instructions in the above doc and ensuring you have email admin or global admin perms in the tenant you're still getting the error then please open a support ticket for further assistance. 

Copper Contributor

AHA!

Thanks, I had recently upgraded to PS7 and was missing the exchange online management module.

Thanks for your help, and have a wonderful Thanksgiving.

 

@Bobby_ono Awesome! Glad to hear that helped! My best wishes to you as well for a happy holiday weekend. :)

Copper Contributor

Hi,

We were using a transport rule to block email containing credit card numbers. We did this with logic:
Is received from 'Outside the organization' and The message contains any of these sensitive information types: 'Credit Card Number'.

Trying to get this to work with Compliance/Purview DLP policy with the following logic:
Location: Exchange Email (All Groups)
Rule: Content is received from 'People outside my organization' AND Content contains Sensitive information types 'Credit Card Number'.

Looking at the documentation, specifically the Exchange Email Location scoping (https://learn.microsoft.com/en-us/purview/dlp-policy-reference#exchange-location-scoping), it states:

 

If you choose to include specific distribution groups in Exchange, the DLP policy is scoped only to the emails sent by members of that group. Similarly, excluding a distribution group excludes all the emails sent by the members of that distribution group from policy evaluation.


What about if you choose 'All Groups'? Does 'All Groups' really mean All Groups? or does it mean all senders and receivers? The reason I ask is because I cannot get this inbound DLP policy to function. If All Groups does mean All Groups then anyone external would not be in a group and thus wouldn't apply, which is what I am experiencing in my testing.

We have similar outbound (Content is shared from Microsoft 365 with people outside my organization) DLP policy for blocking sharing of credit cards and as soon as I hit reply on the test email containing CC information sent to trigger the inbound policy I mention above, the outbound policy kicks in and shows the policy tip - so I know the keywords and cc number in the email is enough to trigger the policy. And I suspect that because when I hit reply, the internal user I am hitting reply from is in a group used in the outbound exchange email location scoping and is the sender in this case.

Any help would be greatly appreciated.

Regards

Copper Contributor

Hi David!

Im in the same boat you are with Credit Card rules. Im just starting to figure out how to compose under Purview.

Hopefully someone will  respond and help us both out on this "journey".

Copper Contributor

@Bobby_ono
Looking at the policies with 

 

Get-DLPCompliancePolicy 'policy_name' | FL

 

 shows that the policy is in fact working and I now understand how the Exchange scoping works. The ExchangeLocation attribute is set to All regardless of which radio button is selected during the creation wizard. There are two other attributes that represent the Specific Groups radio button:

  • ExchangeSenderMemberOf
  • ExchangeSenderMemberOfException

These are blank/$null when 'All Groups' is selected.

There are a few other attributes that reveal how many times the policy has been 'matched':

  • MatchedItemsCount
  • TopNLocationStatistics
  • WorkloadStatistics

These attributes show the policy is matching my test emails. Policy currently in test mode, so the content is delivered to the recipient. I know which part of the policy isn't working now, which is the notification email to the sender - in my case is an external sender.

 

The documentation on DLP policy notifications covers this scenario - https://learn.microsoft.com/en-us/purview/use-notifications-and-policy-tips#options-for-configuring-...

 

External senders receive only a templatized notification without full details to prevent any unintended loss of information about the policy configuration.

 

Hope this might help you Bobby.


edit: Worked out the notification issue on my end - the notification email was ending up in gmail spam folder.

Copper Contributor

Issue that we have is that we used ETR with DLP to route emails to spesific connector and since DLP is not working with ETR anymore this is not possible anymore. I have not found any workaround to this, am I the only one that uses ETR with DLP to route through connectors?

Copper Contributor

What's the best way to move ETR's with DLP conditions to a Purview DLP policy? I use this for my clients to encrypt HIPAA-sensitive email, for example:

 

Apply this rule if: message is sent outside the organization and the message contains sensitive information (like SSN, credit card numbers, etc)

Do the following: rights protect message with RMS template: "Encrypt"

 

I now have a bunch of clients whose encryption is not working because of the move to Purview Compliance DLP (Yes, I probably should've seen the warnings in advance). Microsoft's documentation suggests there is a "Migration wizard" to move DLP rules created in Exchange, but I cannot find that wizard anywhere. 

 

Is there another way to access the migration wizard and/or is there a PowerShell command to do this? Or am I going to have to manually create DLP polices for each client? 

@esd087 The DLP team's migration wizard only works for ETRs that are *linked* to DLP policies. You can find migration wizard eligible ETRs by running the cmdlet I posted in a previous comment: 

Get-TransportRule | where { $_.DlpPolicyId -ne [Guid]::Empty }

You can learn more about how the migration wizard works here: Migrate Exchange Online DLP policies to Microsoft Purview compliance portal | Microsoft Learn

However, ETRs with DLP-related conditions/actions but *not* linked to a DLP policy are *not* eligible to be migrated via the migration wizard and must be manually recreated in Purview DLP, sorry to say. 

 

Copper Contributor

@KevinShaughnessy thanks for the response. We don't have policies linked to the ETRs - all we did was create the ETR. So are you saying there is no other way (Powershell?) to do this efficiently? I've got dozens of clients whose DLP ETRs are broken and their email encryption has to be manually triggered until we fix this. Obviously a major, major headache if we have to manually create DLP policies on each. 

Copper Contributor

Hello everyone !

 

I was using ETR with the operation  "Generate recipient notification and include the following content:..."

It seems that with the new center i can no longer have this functionnality. Anyone has an idea on how to recreate this functionnality in the new center ?

 

Any help would be greatly appreciated.

Regards

@esd087 Understood it's a pain, but unfortunately now at this final stage of the > 2 year long process to migrate all DLP-related functionality to Purview DLP, you'll have to recreate them via the Purview DLP UI  in the compliance center or via Powershell. You could write a script that builds off the cmdlet provided above (to find the ETRs with DLP-related conditions/actions) to then extract the parameter values for each found rule then create new DLP rules/policies with the corresponding parameters and values. 

Copper Contributor

Recently I have started getting emails from "Microsoft Exchange - System Mailbox" with the subject of "Expired: Your "__(insert what looks to be the subject of an email that never made it to me)___" is no longer valid because it's expired".  

The body of the email just says "The approval request has expired."  Then underneath this, it just says the same thing that the subject says - except this time it's down in the body of the email.  

 

I am getting about 10 of these per day, but I don't see anything that has actually expired, or anything that I could change to fix this - and it is driving me absolutely nuts.  Can anyone advise where I need to go to actually get this shut off so that I can stop receiving these emails so frequently?  I have actually thought about ditching this email address all together because it's driving me that crazy. 

 

Any help would be so greatly appreciated!

Thank you SO much!

Co-Authors
Version history
Last update:
‎Nov 02 2023 04:57 AM
Updated by: