Microsoft has opened public preview of Message Trace support in Microsoft Graph, marking a significant step toward modernizing how organizations collect, query, and automate email trace data from Exchange Online. The preview shifts message tracing from the legacy Reporting Webservice to a RESTful Graph surface (exchangeMessageTrace in the Graph beta), introduces cmdlet‑style V2 PowerShell equivalents, and brings explicit migration and throttling guidance that administrators must factor into their automation and SIEM strategies.
Background
The Message Trace capability has long been essential for Exchange administrators: it enables tracing of email delivery status, auditing of mail flow, and large‑scale extraction of message metadata for compliance and security workflows. Historically, admins used the classic Get‑MessageTrace / Get‑MessageTraceDetail cmdlets and the Reporting Webservice to pull that data programmatically. Microsoft’s recent program begins retiring the legacy surfaces and consolidates message trace capabilities into the new Message Trace experience (EAC UI + V2 cmdlets) and into Microsoft Graph (beta) to support modern RESTful automation and centralized governance. The public preview rollout for the Graph endpoint is intended to give administrators and developers a modern API (exchangeMessageTrace in Graph beta) to trace messages across Exchange Online tenants, while Microsoft phases out the reporting endpoints that have powered many third‑party integrations. The Graph beta documentation already exposes the exchangeMessageTrace and exchangeMessageTraceDetail resource types and their properties, giving developers a clear schema to build against during the preview.
What’s new: Graph-based Message Trace and V2 cmdlets
Modern API surface: exchangeMessageTrace (Graph beta)
- The Graph beta exposes an exchangeMessageTrace resource that represents message metadata as it flows through Exchange Online: sender, recipient, messageId, receivedDateTime, status (delivered, pending, failed, quarantined, filteredAsSpam, etc., subject, size, and IP addresses. This resource maps directly to the tracing semantics admins expect while using JSON/REST rather than older XML/soap endpoints.
- The Graph beta entry documents two primary methods:
- List message traces (collection of exchangeMessageTrace)
- Get details by recipient (exchangeMessageTraceDetail)
Using Graph means standard Microsoft Graph tooling (SDKs, $select, paging patterns, OAuth) can be used for ingestion and automation.
PowerShell parity: Get‑MessageTraceV2 / Get‑MessageTraceDetailV2
- Microsoft delivered PowerShell V2 cmdlets that align with the new Message Trace experience: Get‑MessageTraceV2 and Get‑MessageTraceDetailV2. These cmdlets require Exchange Online PowerShell V3 module (version 3.7.0+), change result semantics (no page number/page size; use -ResultSize), and introduce a subject parameter and refined filters. The intent is to provide familiar cmdlet semantics while moving customers toward a REST+OAuth model.
- Important behavioral changes include:
- Extended historical window visibility (tenants can eventually query up to 90 days near‑real‑time, but individual queries typically cover a 10‑day span).
- Result sizing controlled by -ResultSize (default 1,000; maximum 5,000).
- New ordering and normalization semantics (V2 preserves recipient casing and returns the most up‑to‑date size/status).
Migration guidance and deprecation timeline — exact dates you must track
Microsoft has published a sequence of milestones for the transition. Administrators should treat the Microsoft posts and each tenant’s Message Center entries as the authoritative timeline for their environment; public notices have changed as Microsoft responded to feedback. Two points to emphasize:
- The new Message Trace experience (UI + V2 cmdlets) has already reached General Availability and is rolling out to tenants; the old UI and original cmdlets were scheduled for phased deprecation with firm “act by” dates to allow migration.
- Reporting Webservice support for Message Trace is being deprecated on a timeline Microsoft adjusted after feedback. Public Microsoft notices show deprecation actions around March 2026 (Microsoft updated the Message Center entry to reflect a delay and specific dates). Administrators must validate the deprecation date shown in their tenant’s Message Center; tenant‑specific notices may differ and sometimes supersede public blog text.
Key practical migration dates and advisories (as published and updated by Microsoft):
- Migrate scripts using legacy cmdlets to the V2 cmdlets by the documented deadlines (Microsoft gave an “act by” date for migrating automation to the new cmdlets and advised admins to have automation updated ahead of deprecation).
- Reporting Webservice Message Trace support deprecation window was adjusted in Microsoft’s public notices; administrators must confirm the final tenant Message Center entry for the precise effective date in their environment. If your organization’s notice shows April 6, 2026, treat that as tenant‑specific guidance and plan migration accordingly. If Microsoft public notices show March 18, 2026 or February 28, 2026, reconcile that with your tenant’s Message Center. Do not assume a single global deprecation date without checking tenant Message Center.
Because message tracing is often integrated with SIEMs, third‑party tools, and compliance exports, the migration window requires careful coordination with vendors and internal teams. Community guidance and migration playbooks recommend an inventory‑first approach and staged testing.
Throttling: the new rules and what they mean for automation
Microsoft implemented rate‑based tenant throttling to ensure fair usage and service availability. The published throttling policy for the V2 surfaces and Graph message trace (as noted by Microsoft) is summarized below.
Published throttling limits
- Tenant rate limit: maximum of 100 query requests accepted within a running 5‑minute window. This limit applies across message trace and message trace detail query surfaces; both Get‑MessageTraceV2 and Get‑MessageTraceDetailV2 share the same quota. Throttling is not applied if your request rate stays below 100 past requests in 5 minutes.
- Result size per query: up to 5,000 results per query (the -ResultSize cap). A single query can return up to 5,000 rows; query and result count are distinct.
Practical capacity math (admin planning)
- Maximum queries in 5 minutes: 100 requests.
- Max results per request: 5,000 rows.
- Therefore, *maximum rows pulled per tenant per 5 minutes = 100 5,000 = 500,000 rows**.
- Scaling that to a day (5‑minute windows repeated across 24 hours):
- There are 12 five‑minute windows per hour × 24 = 288 windows per day.
- If you hit the 100 requests every 5 minutes: 100 Ă— 5,000 Ă— 288 = 144,000,000 rows per day.
- Microsoft published the same figure to illustrate theoretical daily throughput when queries are distributed evenly.
Operational context and implications
- Many tenant automations that historically polled legacy endpoints more aggressively will now encounter enforced limits. If you run automation polling every minute per mailbox or run parallel retrieval jobs, you will likely hit tenant throttles frequently.
- Throttling is rate‑based, so you must redesign ingestion patterns to:
- Batch queries sensibly (use time windows to consolidate).
- Use the -ResultSize cap effectively (increase result size per query to reduce request count while staying below 5,000 rows).
- Use a time‑window paging strategy (query sequential 10‑day windows for historical coverage) rather than numerous tiny queries.
- For very large estates that need continuous export of message trace for SIEM or analytics, consider:
- Scheduled bulk pulls during off‑peak windows with exponential backoff.
- Distributed ingestion across multiple tenants (if appropriate) or dedicated service accounts with coordinated timing—while still respecting the tenant quota.
- Pushing only deltas (since last retrieved receivedDateTime) rather than full scans.
Migration checklist — an actionable plan for the next 90 days
- Inventory:
- Run EWS/Reporting Webservice usage reports, enumerate all scripts, service principals, scheduled jobs, and third‑party connectors that call legacy Message Trace endpoints or old cmdlets. Document owners and SLAs.
- Prioritize:
- Classify dependencies: immediate (business critical), medium (vendor upgrades), and long‑tail (archival or ad‑hoc reporting). Prioritize critical SIEM feeds and incident response automation.
- Pilot:
- Choose a non‑production or pilot tenant and test Graph exchangeMessageTrace beta endpoints and the Get‑MessageTraceV2 cmdlets. Validate query properties, $select usage, and result schemas. Use the Graph beta page to check expected properties and behavior.
- Update automation:
- Replace legacy Reporting Webservice calls with either:
- Graph beta exchangeMessageTrace calls (where available), or
- V2 PowerShell cmdlets for script parity.
- Consolidate polling frequency, increase per‑query result packages (where appropriate), and implement retry/backoff on HTTP 429 with Retry‑After handling.
- Harden authentication:
- Move integrations to app‑only OAuth where possible, adopt certificate‑based authentication for service principals, and assign least‑privilege RBAC roles. Log and rotate keys regularly.
- Vendor coordination:
- Contact third‑party vendors and confirm their migration timelines. Track vendor readiness to consume Graph message trace or V2 cmdlets. Document interim mitigations if vendors cannot migrate in time.
- Validate and monitor:
- After cutover, compare trace volumes and coverage against historical baselines. Monitor 429/503 rates and adapt schedules to avoid service interruptions. Keep a rollback plan to the V2 PowerShell path if Graph beta changes break assumptions during preview.
Risks, tradeoffs, and mitigation strategies
Risk: Timing ambiguity and tenant‑specific notices
Microsoft’s public announcements have been updated over time; message center entries and tenant notices may differ. Rely on the Message Center for tenant‑specific enforcement dates. If you’ve been told to migrate by a specific date (for example, April 6, 2026), treat that as an authoritative tenant instruction and plan accordingly. If you see a different date in public posts (e.g., March 18, 2026), reconcile both with your tenant’s Message Center and support channels before making a hard go/no‑go decision.
Flag any mismatches to your Microsoft account team. Risk: Throttling impact on SIEM and forensic pipelines
Strict rate caps will affect high‑volume, low‑latency ingestion patterns. If your SIEM or SOC depends on near‑real‑time message trace exports, you must redesign the ingestion pattern to:
- Reduce request frequency and increase request payload size where possible.
- Implement backoffs and coordinated fetching windows.
- Consider batching and filtered ingestion (e.g., only ingest messages that match risk profiles) instead of full‑volume pulls.
Risk: Preview instability and property churn
Graph beta APIs and preview properties can change. Avoid depending on undocumented or preview‑only fields in production workflows. Use $select to request documented properties and write code that tolerates property removal or renaming. Maintain feature flags in your integration to quickly disable reliance on preview properties at GA.
Risk: Sovereign cloud and government tenants lag
GCC, GCC‑High, DoD, and other sovereign cloud tenants traditionally receive features on a delayed schedule. If you operate in a sovereign environment, do not assume Graph parity or identical deprecation dates; confirm timelines with your Microsoft account team and Message Center notices.
Operational examples and design patterns
- Use time‑windowed bulk pulls: Query contiguous 10‑day windows with -ResultSize=5000 and advance your start/end windows to cover required retention. This minimizes request count while maximizing per‑call yield.
- Delta ingestion: Store the latest receivedDateTime on each run and request only messages after that timestamp for incremental pulls.
- Backoff and retry: Implement exponential backoff for 429 responses using the Retry‑After header. Log request IDs for Microsoft support escalations when you see unexpected throttling behavior.
- Query from service principal: Use certificate‑based app authentication with dedicated RBAC roles and record token use in your SIEM to support audit trails.
What to tell your teams and vendors now
- Security and SOC teams: Expect changes to ingestion cadence and potential gaps during migration. Coordinate a pilot week for the SOC to validate parity with the old streams.
- DevOps/Automation engineers: Begin converting scripts to V2 cmdlets or Graph calls, add robust retry logic, and centralize tracing to a small set of hardened service identities.
- Procurement and compliance: If you still depend on vendor appliances that use Reporting Webservice, get vendor timelines in writing and consider licensing or replacement strategies for vendor gaps.
- Executive stakeholders: Migration is operationally straightforward but requires scheduling, vendor coordination, and acceptance testing—build a cross‑functional plan with SLAs.
Strengths and opportunities
- A modern Graph surface unlocks standard SDKs, centralized OAuth token governance, and smoother integration with cloud‑native services.
- The V2 cmdlets preserve admin‑familiar semantics, reducing rewrite costs for PowerShell‑driven automation.
- Rate limits make service behavior predictable and protect shared cloud resources from noisy consumers.
- Graph’s schema and SDK support create future opportunities for richer integrations (webhooks, eventing, and advanced analytics).
Conclusion
The public preview of Message Trace on Microsoft Graph marks a meaningful modernization of Exchange Online telemetry. Administrators should treat the preview as an urgent migration opportunity: inventory existing dependencies, pilot Graph and V2 cmdlets in a non‑production tenant, and redesign ingestion patterns to respect the tenant‑level throttling rules (100 queries per 5 minutes; up to 5,000 rows per query). Cross‑check tenant Message Center notices for the exact deprecation date for Reporting Webservice in your environment—Microsoft’s public timeline has been revised and tenant‑specific messages may differ. Finally, code defensively: depend only on documented fields, implement robust retry/backoff behavior, and coordinate with vendors to ensure SIEM and compliance pipelines remain uninterrupted.
Source: Microsoft Exchange Team Blog
Message Trace Support Using Graph API is now in Public Preview | Microsoft Community Hub