All About the Get-MailTrafficSummaryReport Cmdlet

Useful but Aging Cmdlet

The Get-MailTrafficSummaryReport cmdlet
Figure 1: Running the Get-MailTrafficSummaryReport cmdlet

I’m bemused when I see sites treat the Get-MailTrafficSummaryReport cmdlet as if it has some magical powers, like proclaiming it to be one of the top 10 cmdlets for email monitoring. The sad fact is that although the cmdlet is useful, it has aged without much progression over the last few years, which might be why Microsoft attempted to retire it in 2021. That venture failed because of customer feedback, but I’m insure why people feel so strongly about the cmdlet.

Summarizing Message Trace Data

Essentially, the Get-MailTrafficSummaryReport cmdlet takes the message trace data retained by Exchange Online for the last 90 days (give or take a day or two depending on background processing) and summarizes the data under various categories. The most popular are:

  • TopMailSender: Report the number of messages sent by different mail-enabled objects, including user mailboxes, shared mailboxes, and guest accounts. Separate counts are given for each proxy address assigned to a mail-enabled object.
  • TopMailRecipient: Report the number of messages received by different proxy addresses for mail-enabled recipients. As for senders, separate counts are available for each proxy address assigned to a mailbox.
  • TopMalware: Report malware (like Win32/Tnega.SM!MTB) detected in inbound messages.
  • TopSpamRecipient: Report the number of spam messages intercepted for mail-enabled recipients. I use different test accounts for articles. Within a week of publishing a test account’s email address in an article, I know that spam begins to arrive for that account. The report also shows spam addressed to mail-enabled recipients that no longer exist, like mailboxes belonging to deleted accounts.
  • TopMalwareRecipient: Like spam, but these messages are deemed by Exchange Online Protection to contain malware.
  • InboundTransportRuleHits: Report the transport rules which process inbound email. The report lists the individual rules and the number of messages processed by each rule. You can filter by the name of one or more transport rules by passing the names of the rules in the TransportRule parameter.
  • OutboundTransportRuleHits: Report transport rules which process outbound email.

The cmdlet supports reporting for Data Loss Prevention (DLP) rule hits. I don’t use categories like OutboundDLPPolicyRuleHits (DLP rules detected a policy violation in an outbound email) as much as the categories listed above.

The statistics generated by the cmdlet come from a data warehouse. As such, the information is not real-time in the same way that running Get-MessageTrace can report the progress of a message sent a few seconds ago. Having a time lag for usage data isn’t unusual within Microsoft 365. The normal delay before data becomes available is around two days.

Example of Get-MailTrafficSummaryReport

Most articles covering Get-MailTrafficSummaryReport focus on the top senders and top recipients reports. Looking at something different, here’s how to run a report for outbound messages processed by transport rules. The outbound shows that the transport rule to apply a disclaimer to responses for calendar meeting requests is the most popular in my tenant.

Get-MailTrafficSummaryReport -Category OutboundTransportRuleHits -StartDate $StartDate -EndDate $EndDate | Select-Object C1, C2, C3

C1                                   C2                  C3
--                                   --                  --
Calendar Disclaimer                  SetAuditSeverityLow 201
Automatic BCC                        SetAuditSeverityLow 22
Block Email to Tenant Admin Accounts SetAuditSeverityLow 11
Block Power Automate                 SetAuditSeverityLow 7

The cmdlet output uses C1, C2, and C3 (columns 1, 2, and 3) as non-specific header names because the various reports generate different pieces of data. Sometimes C1 is used for email addresses, and sometimes, like in this example, for the names of transport rules.


The alternatives to using the Get-MailTrafficSummaryReport cmdlet include:

  • Export message trace information to an external repository like Splunk. Organizations do this to retain data for longer than the 90 days supported by Microsoft and to gain more sophisticated querying capabilities. Here’s an example of a script written to extract large quantities of message trace data.
  • Use the Microsoft Graph reports API to work with the same data as appears in the usage reports in the Microsoft 365 admin center. The data is limited to a 90-day horizon and the email usage data is nowhere near as comprehensive as message trace data and doesn’t include access to data about spam, malware, and rule-based activity. The major advantage of this approach is the ability to build a picture of overall user activity across multiple Microsoft 365 workloads.

My bet is that Microsoft’s focus will be on Graph-based usage reporting. It’s likely they will try to deprecate the Get-MailTrafficSummaryReport cmdlet in the future. With that in mind, I don’t plan to spend much time on this cmdlet going forward as I don’t anticipate any change in coverage or functionality. But if Get-MailTrafficSummaryReport does a job for you, continue using it until the future direction becomes apparent.

Learn how to exploit the data available to Microsoft 365 tenant administrators through the Office 365 for IT Pros eBook. We love figuring out how things work.

14 Replies to “All About the Get-MailTrafficSummaryReport Cmdlet”

  1. Get-MailTrafficSummaryReport doesn’t return any data after 6th June 23
    any date before this (within the 90day window) data is returned fine.
    Anyone else seeing this?

  2. Following on from my last comment (which hasn’t shown up yet)

    I’ve just tried running this report:
    Microsoft 365 Defender / Reports / Email & Collaboration / Top senders and recipients

    If I use dates before 6th jun23 it shows a graph and returns data

    Any date after the 6th Jun 23 empty graph and no data

      1. Hi Tony,
        I have had a support ticket open since Tue 13th but I’m getting no where they don’t understand what I’m try to tell and show them.
        I’ve been posting on pages that talk about this PowerShell command to see if anyone one else is seeing similar results.

        Some additional info for anyone following results as of this morning 19/06/23

        04/06/23 Data returned (Figures as expected)
        05/06/23 Data Returned (Figures as expected)
        06/06/23 Data Returned (Only one entry everything else missing )
        07/06/23 NO Data Returned
        08/06/23 NO Data Returned
        09/06/23 NO Data Returned
        10/06/23 NO Data Returned
        11/06/23 NO Data Returned
        12/06/23 NO Data Returned
        13/06/23 NO Data Returned
        14/06/23 NO Data Returned
        15/06/23 NO Data Returned
        16/06/23 Data Returned (only 5 entries all the rest missing This is a working day so there would be lots more!)
        17/06/23 Data Returned (only 5 entries BUT they are identical to 16/06/23! but I’m not sure if this is to soon to run this date?)

        If anyone is seeing the same sort of issue if they could post please.

  3. Still nothing except a daily message from MS:

    We are engaging with our next level team investigation still ongoing, once we get, we will connect with you.

    Still, we haven’t proper update, once we had we will connect with you.

    We are appreciating your patience.



    Microsoft 365 Support Engineer

    Can’t say I’m filled with confidence.

  4. I am also having issues with the TopMailSender flag. There is no data reported at all for some two weeks mid-June 2023, as above. However, I also am getting very strange results since this.

    I run this cmdlet on my own mailbox for a 1 week period last week and it reports only 4 mails sent. According to my sent box, it is >20. This is with the -Domain ALL flag. Without it, it only reports 2 items sent.

    1. Hi Andrew,
      I’ve heard back from a number of different people in different countries all with the same symptoms.
      I’ve been chasing Microsoft support about my case but I keep getting the next level is investigating than you for your patience.

  5. I’ve just had an email from MS saying the issue is now fixed. I have not had chance to check myself yet.

  6. I am now getting results from the command however after spot checking a couple of users the results are not correct!
    I also tried adding ‘-Domain ALL’ which increased some results and oddly decreased others!?
    I have reported this back to MS.

  7. Final response from Microsoft support it will not work for intra-org emails, only external emails!
    Their response:

    If you are trying to verify the sending mail data reports for the External senders, we will get the same results in Both Outlook applications and PowerShell outputs.
    If you are trying to match the mail sending reports for Internal users will not get the same results, it’s still on the features on yet to developed from our Product team.
    Currently the feature not available for users.

    Please can you confirm with the customer if the email was sent within the organization? basically were they intra-org sent emails.
    if that is the case, then the numbers won’t add up.
    This feature still not released from Microsoft end. There is no ETA.

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.