Change Optics Report released into Public Preview to showcase messages impacted by future changes

The Change Optics Report is documented as a pre-enablement planning tool — a sample set to help tenants prepare before enabling RejectDirectSend. Our situation is the inverse: the setting is already enforcing in our tenant, legitimate business mail is being rejected, and the rejections do not appear in Message Trace or Extended Message Trace. Confirmed by Microsoft support case.

That leaves no way to determine what is currently being lost. A sampled report with roughly 18 hours of retention cannot serve as an incident inventory, and the guidance to use Message Trace for further detail doesn't apply, since these messages are rejected at the edge before acceptance.

Two requests: full rather than sampled DRS data, and retention matching the date range selector. In our tenant this scenario is generating hundreds of rejections per week across four distinct sending platforms, and users have no way of knowing what they are not receiving.

"Something went wrong when getting data. Please refresh the page or try again later!" when selecting DRS in "Optics for Upcoming Changes" tab. I still able to see the Message Volume graph of DRS.

[REQUEST FOR CHANGE]: As others have mentioned the "Allowed" message types, like Journaling, has to be suppressed as soon as possible. Having it there makes this report effectively useless as journaling environments will have many hundreds of thousands of emails. This obviously causes too much noise and may obsecrate real MOERA emails that will be throttled. Keep this unfiltered makes the OMC reporting in the Change Optics reporting useless. 

Is there a way to generate this report using Powershell at this time?

It's very nice to have the ability to see a report for messages sent via Direct Send. However, it seems there is an issue when exporting the report. No matter if you choose 7 days, 30 days or 90 days, the exported csv file only contains the messages that were loaded to the page at the time the export was initiated. To get the complete report you have to continually scroll to the bottom of the page and click "Load more" until the whole period is loaded. With tens of thousands of messages this doesn't seem very efficient, and I doubt this has been the intention...

This is a good start towards being able to monitor Direct Send traffic. I would like to see the sending IP and sending MTA in the report to verify whether the message is legitimate.

This would be a good point to add to your other blog post on Direct Send.

The newly released OMC (OnMicrosoft.com outbound traffic) and DRS (Direct Send inbound traffic) report is a useful step toward improving visibility and control over mail flow, especially for large enterprise tenants preparing for throttling or enabling “Reject Direct Send.”

However, there are key concerns. The report currently lacks sufficient technical depth—such as source IPs, sending hosts, authentication details, connector mapping, and traffic trends—making it difficult to accurately identify dependencies and remediate legitimate usage. This is particularly critical for DRS scenarios involving line-of-business applications and devices.

A major issue is that the downloaded report does not capture the complete dataset, leading to discrepancies and limiting its reliability for analysis and decision-making.

To be fully actionable, the report should provide complete and consistent data exports, enhanced granularity, clear schema definitions, and better correlation with existing mail flow insights.

Overall, while directionally valuable, the report needs improved completeness and technical detail to effectively support enterprise use cases.

My report is flooded with NDR messages sent from MicrosoftExchange329e71ec88ae4615bbc36ab6ce41109e tagged as OMC

These are not supposed to be affected by traffic throttling.

Just a thought.  It would be nice to me if I could see the status of the message delivery in the report.  Like, if the message was quarantined or delivered.  That would be nice to see since it would help me to focus on the scenarios where messages are being delivered for a valid reason so that I can reconfigure the sending application.