In some cases, you may be asked to force OME on anything that isn't TLS encrypted, and I enhanced Mikes process by building out a script that scrapes exchange online Trace results for messages to domains that are held up, collects them, compares them to the domains in existing 2 rules, and then updates the rule with an alphabetical split balance of Domains. It needs to be fleshed out a bit, but I felt it'd be a great starting point, and as is, could easily be slipped into An Azure automation for regular updating.
A bit of documentation :
Designed to be utilized with either Azure automation, or in a powershell ISE session after 'connect-exchangeonline' is run. Filtering is done in 2 parts, the query that builds 'TRACECURRENT', and the function 'TRACE-DETAILS'
I suggest editing the where-object in TRACECURRENT with common typo's seen in your org, or other things you may know you don't care about.. automation that cant handle responses, etc. The filtering in Trace Details drops data from the message detail that either slipped through, or is from a trace response that isn't pertinent.
Dates pertinent: Depending on your use case, the start date & end date in 'TRACECURRENT' can be adjusted, Both are required by the 'get-messagetrace' commandlet, Feel free to adjust your usage, as you need.
*An automated process for managing the dates will likely have to be added if you utilize Azure automation. *This requires message transport rules be created following Mike Parker's guide, but must input your Rule names into the script attached.
**Final note: there are comments in the script that rules can sustain around 189 domains. The exact capacity of Exchange online rules as of this writing, is '8 KB'. The current byte/bit usage of a Rule is unattainable at this time, except by maxing it out when you try a 'set-transportrule'. THis is a known issue, and if anyone on the product team reads this, let me know if you can fix, or provide a proper solution.
No warranty implied, utilize the attached code at your own risk*