Update 5/6/2025: We added information about new cmdlet throttling limit.
Today, we are excited to announce that the Public Preview of the new Message Trace in the Exchange admin center (EAC) in Exc...
Updated Aug 27, 2025
Version 13.0
Blog Post
These updates sound good, especially having 90 days eventually available, but some questions naturally appear around loss of pagination.
I'm a bit confused about StartingRecipientAddress replacing pagination.
We will not have unique recipients for the results of the first query, how will using this recipient as an anchor help in ensuring we get a true continuation of Message Trace logs with no entries skipped and minimum duplication?
I'm sure there is a good reason behind this, but I cant find an explanation why the choice for this continuation anchor was not NetworkMessageID of last entry of an incomplete query output.
Does the service somehow cache my last query output and knows where to pickup on next query as long as it has a StartingRecipientAddress that matches the last returned entry?
yeah I agree here. We have use cases where we collect the message trace for the journal service. All emails are send to the same recipient (journal address). I am thinking that we will have to make a request for a time window and for the next "page" is to move the start time parameter up to the last timestamp on the previous response.
Qingjun_ChenMicrosoft
Thanks alexandruliviunita and scaph01 for the feedbacks. Regarding StartingRecipientAddress, we will update the blog post to provide a more detailed explanation of how this parameter works and how it helps in retrieving subsequent records while minimizing duplication.
scaph01, In the new message trace, we recommend narrowing down the query duration and specifying filters to achieve the expected results more efficiently, which aligns with your thoughts.