Microsoft has moved the overhauled Message Trace experience in Exchange Online to general availability, bringing a faster UI, new PowerShell cmdlets, and a firm September 1, 2025 deadline for the legacy tools that thousands of administrators rely on daily. The rollout, which began in mid-June and completed in July, delivers extended query windows, sharper filtering, and tenant-level throttling that will force organizations to redesign automation and integration scripts before the year is out.

A Long-Overdue Upgrade Arrives

Exchange Online's Message Trace is the go-to forensic tool for tracking email delivery, troubleshooting missing messages, and auditing mail flow. The previous iteration, built on the Get-MessageTrace and Get-MessageTraceDetail cmdlets, suffered from performance bottlenecks, limited historical data, and a clunky pagination model. Microsoft’s Exchange team has now replaced that legacy stack with a modernized, high-performance alternative anchored by Get-MessageTraceV2 and Get-MessageTraceDetailV2.

The new experience is enabled by default in the Exchange admin center (EAC) for worldwide tenants. Administrators who connect via PowerShell must upgrade to the Exchange Online PowerShell V3 module, version 3.7.0 or later, to use the V2 cmdlets. Microsoft’s public announcement on the Exchange Team Blog details the changes, while community threads on the Microsoft Tech Community and Q&A forums surface early adopter feedback—some praising the speed, others wrestling with the throttling constraints.

What’s New Under the Hood

The revamped Message Trace addresses long-standing pain points with three areas of improvement: query range, filtering, and programmatic access.

Extended Historical Data and Longer Query Windows

The new system can surface near-real-time traces across up to 90 days of historical data. Initially, tenants may see a 30-day window that expands over time. Each individual query, whether in the EAC or via PowerShell, covers up to 10 days of data per request. This is a significant jump from the old 7-day limit, giving compliance and security teams far deeper visibility without having to stitch together multiple exports.

Richer, More Granular Filtering

Subject filtering now supports starts-with, ends-with, and contains operators—including special characters—so admins can zero in on specific email campaigns or phishing lures. The delivery status filter has been expanded to include Quarantined, Filtered as spam, and Getting status, cutting down manual triage time for spam incidents. These additions, while simple on the surface, eliminate the need for messy post-query parsing that many teams had built into their workflows.

UI and UX Polish

The EAC interface now remembers customized column widths and layouts across sessions, a small but welcome quality-of-life improvement. Timestamps align to the logged-on admin’s Exchange time zone, removing a persistent source of confusion during cross-region investigations. Lazy loading ensures the first rows appear quickly while the rest stream in on demand.

The PowerShell Shift: Get-MessageTraceV2 and Get-MessageTraceDetailV2

For automation, the transition to V2 cmdlets is mandatory. The old page-number and page-size pagination is gone. Instead, scripts use a -ResultSize parameter with a default of 1,000 and a hard maximum of 5,000 results per call. To retrieve larger datasets, administrators must adopt a deterministic batching pattern: call the cmdlet, take the last row’s Received timestamp and RecipientAddress, and feed them into the next request as -EndDate and -StartingRecipientAddress. This ensures no duplicates and no gaps, but it requires rewriting virtually every existing script.

Results are ordered by Received date descending, then by RecipientAddress ascending (case-insensitive). For messages sent to more than 1,000 recipients, the new MessageTraceId parameter—also known as NetworkMsgId—must be included to guarantee all recipients are returned. Microsoft Learn documentation provides sample scripts, but the onus is on each tenant to implement the pattern correctly.

Throttling: The New Operational Reality

Perhaps the most disruptive change is the introduction of tenant-level rate throttling. The new Message Trace enforces a cap of 100 query requests per tenant per 5-minute sliding window. This applies to both the V2 cmdlets and equivalent EAC traces. Throttling is only triggered if the query rate exceeds that threshold, but many organizations run frequent, fine-grained queries—for example, polling delivery status every few minutes for TLS reporting or feeding a SIEM. Those automations will hit the wall immediately if left unchanged.

“The 100-requests-per-5-minutes limit is a paradigm shift,” a discussion participant noted. “We used to pull a full day’s trace every 15 minutes for our dashboards. Now we need to entirely rethink our data ingestion pipeline.”

To stay under the cap, Microsoft recommends consolidating queries into fewer, larger calls (while respecting the 10-day window and 5,000-result max), staggering schedules across service accounts, and implementing client-side exponential backoff for 429 throttle responses. Some early adopters have already built centralized PowerShell extraction services that run at lower frequency and push batches to blob storage, where downstream consumers read without re-querying Exchange Online.

Deprecation Timeline and the Reporting Webservice Question

The legacy Message Trace UI and the original Get-MessageTrace/Get-MessageTraceDetail cmdlets begin sun setting on September 1, 2025 for worldwide tenants. That gives organizations a matter of months to complete their migration. The timeline is firm—Microsoft’s Tech Community post states it plainly, and Learn documentation echoes the date.

Then there’s the Reporting Webservice endpoint (/ecp/reportingwebservice/reporting.svc/MessageTrace), which many SIEM tools and custom integrations rely on. The original GA announcement indicated this endpoint would also start deprecating on September 1, 2025. However, community forums and Microsoft Q&A threads reveal ongoing uncertainty. Some users have cited an alleged update from August 25, 2025, claiming a delay until February 28, 2026, but that update does not appear in the public Tech Community post or current Learn pages at the time of writing. Without official, timestamped confirmation in a tenant’s Message Center, administrators should treat September 1 as the operational cutoff. Microsoft staff in Q&A responses have acknowledged the lack of a direct REST replacement and recommend migrating integrations to the V2 cmdlets or awaiting Graph API support.

“We’re in limbo,” one admin wrote. “Our SIEM vendor needs a direct API endpoint. PowerShell isn’t an option for that connector, and there’s no Graph endpoint yet.”

Until Microsoft publishes a clear update, the safest posture is to assume the earlier date and accelerate migration. Sovereign clouds (GCC, GCC-High, DoD) follow separate timelines, with announcements expected in the second half of calendar year 2025.

Community Feedback: Praise and Pain

Early adopters have largely welcomed the improved speed and subject filtering. “The new trace is night-and-day faster for large bulk queries,” a veteran Exchange admin posted on the Tech Community thread. “Subject contains with special characters finally works as advertised.”

But frustrations have surfaced around throttling and edge cases. Some users report that the recipient filter requires a wildcard append (e.g., adding * to a partial address) to return expected results, a quirk that Microsoft has acknowledged. Others note that V2 deliberately shows the latest delivery status rather than the original, which can skew historical forensic analysis. “If a message was delivered and later quarantined, V2 might only show ‘Quarantined,’ whereas the old cmdlet showed the initial ‘Delivered’ status. That changes our audit trail,” a compliance officer explained.

Operational Impact: Why This Matters Now

For large enterprises, the throttling cap is the biggest time bomb. A typical full-day trace for a tenant with high mail volume might require dozens of V2 calls, even with maximum ResultSize. At 100 requests per 5 minutes, that could stretch retrieval times to an hour or more, breaking real-time monitoring. Organizations must now treat Message Trace as a scarce resource, centralizing queries and distributing results internally rather than letting multiple teams independently pound the service.

The absence of a documented REST API replacement for the Reporting Webservice forces teams to either adopt PowerShell-based extraction—a non-starter for many SaaS security tools—or build custom middleware. This gap will likely drive renewed interest in Microsoft Graph’s future Message Trace endpoint, but no public preview date has been announced.

A Migration Checklist for Administrators

To navigate the transition smoothly, Exchange Online admins should act on these steps immediately:

  • Inventory every script, automation, SIEM feed, or third-party connector that uses Get-MessageTrace, Get-MessageTraceDetail, or the Reporting Webservice.
  • Upgrade all automation hosts to Exchange Online PowerShell V3 module version 3.7.0 or later, ensuring modern authentication (OAuth) is configured.
  • Rewrite scripts to call Get-MessageTraceV2 and Get-MessageTraceDetailV2, using -ResultSize with the EndDate/StartingRecipientAddress pattern for large result sets.
  • Implement tenant-aware client-side rate limiting that respects the 100 requests per 5-minute cap; coordinate across service principals and admin accounts to avoid exceeding the quota.
  • For Reporting Webservice consumers, build a centralized extraction service that runs PowerShell at a controlled frequency, writes batches to storage, and lets downstream systems read without re-querying Exchange Online.
  • Run side-by-side comparisons between old and new cmdlets to verify result parity, especially for messages with more than 1,000 recipients, quarantined messages, and status changes after delivery.
  • Monitor the tenant’s Microsoft 365 Message Center and the Exchange Team Blog for any official timeline updates, particularly concerning the Reporting Webservice.

The Bottom Line

The new Message Trace is a meaningful upgrade that will speed up investigations and reduce the flakiness that plagued the old system. Subject filtering, 90-day history, and persistent UI settings are all welcome improvements. But the operational cost is real: throttling limits will break automations, and the lack of a direct REST replacement leaves API-centric integrations in a precarious state.

Organizations that start their migration now—rewriting scripts, centralizing extraction, and implementing client-side rate limiting—will avoid a frantic scramble in September. Those that wait risk finding their monitoring, compliance, and security operations grinding to a halt when the legacy tools are turned off. Validate any timeline extensions against official Microsoft notices before assuming extra breathing room, and keep a close eye on the Exchange Team blog for Graph API developments that could eventually simplify the landscape.