Message tracking

מאמר
02/22/2023

The message tracking log is a detailed record of all activity as mail flows through the transport pipeline on Mailbox servers and Edge Transport servers. You can use message tracking for message forensics, mail flow analysis, reporting, and troubleshooting.

By default, Exchange uses circular logging to limit the message tracking log based on file size and file age to help control the hard disk space that's used by the log files. To configure the message tracking log, see Configure message tracking.

Search the message tracking log

Message tracking logs contain vast amounts of data as messages move through a Mailbox server or Edge Transport server. When it comes to searching the message tracking logs, you have options:

Get-MessageTrackingLog: Administrators can use this Exchange Management Shell cmdlet to search the message tracking log for information about messages using a wide range of filter criteria. For more information, see Search message tracking logs.
Delivery reports for administrators: Administrators can use the Delivery reports tab in the Exchange admin center or the underlying Search-MessageTrackingReport and Get-MessageTrackingReport cmdlets in the Exchange Management Shell to search the message tracking logs for information about messages sent by or received by a specific mailbox in the organization. For more information, see Delivery reports for administrators.

Structure of the message tracking log files

By default, the message tracking log files exist in %ExchangeInstallPath%TransportRoles\Logs\MessageTracking. The folder contains log files that have different names, but they all follow the naming convention MSGTRKServiceyyyyMMdd-nnnn.log. The different log file names are described in the following table.

File name	Servers	Description
`MSGTRK`	Mailbox servers and Edge Transport servers	Log files for the Transport service.
`MSGTRKMA`	Mailbox servers	Log files for the approvals and rejections in moderated transport. For more information, see Manage message approval.
`MSGTRKMD`	Mailbox servers	Log files for messages delivered to mailboxes by the Mailbox Transport Delivery service.
`MSGTRKMS`	Mailbox servers	Log files for messages sent from mailboxes by the Mailbox Transport Submission service.

The other placeholders in the log file names represent the following information:

yyyyMMdd is the coordinated universal time (UTC) date when the log file was created. yyyy = year, MM = month, and dd = day.
nnnn is an instance number that starts at the value 1 every day for each log.

Information is written to the log file until the file reaches its maximum size. Then, a new log file that has an incremented instance number is opened (the first log file is -1, the next is -2, and so on). Circular logging deletes the oldest log files for a service when either of the following conditions are true:

A log file reaches its maximum age.
The message tracking log folder reaches its maximum size.

Notes:
- The maximum size of the message tracking log folder is calculated as the total size of all log files that have the same name prefix. Other files that do not follow the name prefix convention are not counted in the total folder size calculation. Renaming old log files or copying other files into the message tracking log folder could cause the folder to exceed its specified maximum size.
- On Mailbox servers, the maximum size of the message tracking log folder is three times the specified value. Although the message tracking log files are generated by the four different services and have four different name prefixes, the amount and frequency of data written to the moderated transport log (MSGTRKMA) is negligible compared to the other three logs.

The message tracking log files are text files that contain data in the comma-separated value (CSV) format. Each message tracking log file has a header that contains the following information:

#Software: The value is Microsoft Exchange Server.
#Version: Version number of the Exchange server that created the message tracking log file. The value uses the format 15.01.nnnn.nnn.
#Log-Type: The value is Message Tracking Log.
#Date: The UTC date-time when the log file was created. The UTC date-time is represented in the ISO 8601 date-time format: yyyy-MM-ddThh:mm:ss.fffZ, where yyyy = year, MM = month, dd = day, T indicates the beginning of the time component, hh = hour, mm = minute, ss = second, fff = fractions of a second, and Z signifies Zulu, which is another way to denote UTC.
#Fields: Comma-delimited field names that are used in the message tracking log files.

Fields in the message tracking log files

The message tracking log stores each message event on a single line in the log. The message event information is organized by fields, and these fields are separated by commas. The field name is generally descriptive enough to determine the type of information that it contains. However, some fields may be blank, or the type of information in the field may change based on the message event type and the service that recorded the event. General descriptions of the fields that are used to classify each message tracking event are explained in the following table.

Field name	Description
date-time	The UTC date-time of the message tracking event. The UTC date-time is represented in the ISO 8601 date-time format: yyyy-MM-ddThh:mm:ss.fffZ, where yyyy = year, MM = month, dd = day, T indicates the beginning of the time component, hh = hour, mm = minute, ss = second, fff = fractions of a second, and Z signifies Zulu, which is another way to denote UTC.
client-ip	The IPv4 or IPv6 address of the messaging server or messaging client that submitted the message.
client-hostname	The host name or FQDN of the messaging server or messaging client that submitted the message.
server-ip	The IPv4 or IPv6 address of the source or destination server.
server-hostname	The host name or FQDN of the destination server.
source-context	Extra information associated with the source field. For example: `CatContentConversion` `250 2.0.0 OK;ClientSubmitTime:<UTC>`
connector-id	The name of the Send connector or Receive connector that accepted the message. For example, ServerName\ ConnectorName or ConnectorName.
source	The Exchange transport component that's responsible for the event. These values are described in the Source values in the message tracking log section later in this topic.
event-id	The message event type. These values are described in the Event types in the message tracking log section later in this topic.
internal-message-id	A message identifier that's assigned by the Exchange server that's currently processing the message. The internal-message-id of a message is different in the message tracking log of every Exchange server that's involved in the transmission of the message. An example value is `73014444033`.
message-id	The value of the Message-Id: header field in the message header. If the Message-Id: header field doesn't exist or is blank, Exchange assigns an arbitrary value. This value is constant for the lifetime of the message. For messages created in Exchange, the value is in the format `<GUID@ServerFQDN>`, including the angle brackets (`< >`). For example, `<4867a3d78a50438bad95c0f6d072fca5@mailbox01.contoso.com>`. Other messaging systems may use different syntax or values.
network-message-id	A unique message ID value that persists across copies of the message that may be created due to bifurcation or distribution group expansion. An example value is `1341ac7b13fb42ab4d4408cf7f55890f`.
recipient-address	The email addresses of the message's recipients. Multiple email addresses are separated by the semicolon character (;).
recipient-status	The recipient status for each recipient separated by the semicolon character (;). The status values are presented for the recipients in the same order as the values in the recipient-address field. Example status values include: `To`, `Cc` or `Bcc` `250 2.1.5 Recipient OK` `550 4.4.7 QUEUE.Expired;<ErrorText>`
total-bytes	The total size of the message in bytes, including all attachments.
recipient-count	The total number of recipients in the message.
related-recipient-address	This field is used with EXPAND, REDIRECT, and RESOLVE events to display other recipient email addresses that are associated with the message.
reference	This field contains additional information for specific types of events. For example: DSN: Contains the report link, which is the Message-Id value of the associated delivery status notification (also known as a DSN, bounce message, non-delivery report, or NDR) if a DSN is generated subsequent to this event. If this is a DSN message, the Reference field contains the Message-Id value of the original message that the DSN was generated for. EXPAND: Contains the related-recipient-address value of the related messages. RECEIVE: May contain the Message-Id value of the related message if the message was generated by other processes, for example, journaling or inbox rules. SEND: Contains the Internal-Message-Id value of any DSN messages. THROTTLE: Contains the reason why the message was throttled. TRANSFER: Contains the Internal-Message-Id value of the message that's being forked. Message generated by inbox rules: Contains the Internal-Message-Id value of the inbound message that caused the inbox rule to generate the outbound message. Forked messages: Might contain the Internal-Message-Id value. For other types of events, this field is usually blank.
message-subject	The message's subject found in the Subject: header field. The tracking of message subjects is controlled by the MessageTrackingLogSubjectLoggingEnabled parameter on the Set-TransportService cmdlet. By default, message subject tracking is enabled.
sender-address	The email address specified in the Sender: header field, or the From: header field if the Sender: field doesn't exist.
return-path	The return email address specified by the MAIL FROM command that sent the message. Although this field is never empty, it can have the null sender address value represented as `<>`.
message-info	Additional information about the message. For example: The message origination date-time in UTC for DELIVER and SEND events. The origination date-time is the time when the message first entered the Exchange organization. The UTC date-time is represented in the ISO 8601 date-time format: yyyy-MM-ddThh:mm:ss.fffZ, where yyyy = year, MM = month, dd = day, T indicates the beginning of the time component, hh = hour, mm = minute, ss = second, fff = fractions of a second, and Z signifies Zulu, which is another way to denote UTC. Authentication errors. For example, you may see the value `11a` and the type of authentication that was used when the authentication error occurred.
directionality	The direction of the message. Example values include `Incoming`, `Undefined`, and `Originating`.
tenant-id	This field isn't used in on-premises Exchange organizations.
original-client-ip	The IPv4 or IPv6 address of the original client.
original-server-ip	The IPv4 or IPv6 address of the original server.
custom-data	This field contains data related to specific event types. For example, the Transport Rule agent uses this field to record the GUID of the mail flow rule (also known as a transport rule) or DLP policy that acted on the message. For more information, see View DLP policy detection reports.
transport-traffic-type	In on-premises Exchange, this field is blank or has the value `Email`.
log-id	A unique identifier for a row in the in the message tracking log. This field isn't important in on-premises Exchange organizations.
schema-version	Version number of the Exchange server that created the entry in the message tracking log. The value uses the format `15.01.nnnn.nnn`.

Event types in the message tracking log

Various event types in the event-id field are used to classify the message events in the message tracking log. Some message events appear in only one type of message tracking log file, and some message events appear in all types of message tracking log files. The events types that are used to classify each message event are explained in the following table.

Event name	Description
AGENTINFO	This event is used by transport agents to log custom data.
BADMAIL	A message submitted by the Pickup directory or the Replay directory that can't be delivered or returned.
CLIENTSUBMISSION	A message was submitted from the Outbox of a mailbox.
DEFER	Message delivery was delayed.
DELIVER	A message was delivered to a local mailbox.
DELIVERFAIL	An agent tried to deliver the message to a folder that doesn't exist in the mailbox.
DROP	A message was dropped without a delivery status notification (also known as a DSN, bounce message, non-delivery report, or NDR). For example: Completed moderation approval request messages. Spam messages that were silently dropped without an NDR.
DSN	A delivery status notification (DSN) was generated.
DUPLICATEDELIVER	A duplicate message was delivered to the recipient. Duplication may occur if a recipient is a member of multiple nested distribution groups. Duplicate messages are detected and removed by the information store.
DUPLICATEEXPAND	During the expansion of the distribution group, a duplicate recipient was detected.
DUPLICATEREDIRECT	An alternate recipient for the message was already a recipient.
EXPAND	A distribution group was expanded.
FAIL	Message delivery failed. Sources include SMTP, DNS, QUEUE, and ROUTING.
HADISCARD	A shadow message was discarded after the primary copy was delivered to the next hop. For more information, see Shadow redundancy in Exchange Server.
HARECEIVE	A shadow message was received by the server in the local database availability group (DAG) or Active Directory site.
HAREDIRECT	A shadow message was created.
HAREDIRECTFAIL	A shadow message failed to be created. The details are stored in the source-context field.
INITMESSAGECREATED	A message was sent to a moderated recipient, so the message was sent to the arbitration mailbox for approval. For more information, see Manage message approval.
LOAD	A message was successfully loaded at boot.
MODERATIONEXPIRE	A moderator for a moderated recipient never approved or rejected the message, so the message expired. For more information about moderated recipients, see Manage message approval.
MODERATORAPPROVE	A moderator for a moderated recipient approved the message, so the message was delivered to the moderated recipient.
MODERATORREJECT	A moderator for a moderated recipient rejected the message, so the message wasn't delivered to the moderated recipient.
MODERATORSALLNDR	All approval requests sent to all moderators of a moderated recipient were undeliverable, and resulted in non-delivery reports (also known as NDRs or bounce messages).
NOTIFYMAPI	A message was detected in the Outbox of a mailbox on the local server.
NOTIFYSHADOW	A message was detected in the Outbox of a mailbox on the local server, and a shadow copy of the message needs to be created.
POISONMESSAGE	A message was put in the poison message queue or removed from the poison message queue.
PROCESS	The message was successfully processed.
PROCESSMEETINGMESSAGE	A meeting message was processed by the Mailbox Transport Delivery service.
RECEIVE	A message was received by the SMTP receive component of the transport service or from the Pickup or Replay directories (source: `SMTP`), or a message was submitted from a mailbox to the Mailbox Transport Submission service (source: `STOREDRIVER`).
REDIRECT	A message was redirected to an alternative recipient after an Active Directory lookup.
RESOLVE	A message's recipients were resolved to a different email address after an Active Directory lookup.
RESUBMIT	A message was automatically resubmitted from Safety Net. For more information, see Safety Net in Exchange Server.
RESUBMITDEFER	A message resubmitted from Safety Net was deferred.
RESUBMITFAIL	A message resubmitted from Safety Net failed.
SEND	A message was sent by SMTP between transport services.
SUBMIT	The Mailbox Transport Submission service successfully transmitted the message to the Transport service. For SUBMIT events, the source-context property contains the following details: MDB: The mailbox database GUID. Mailbox: The mailbox GUID. Event: The event sequence number. MessageClass: The type of message. For example, `IPM.Note`. CreationTime: Date-time of the message submission. ClientType: For example, `User`, `OWA`, or `ActiveSync`.
SUBMITDEFER	The message transmission from the Mailbox Transport Submission service to the Transport service was deferred.
SUBMITFAIL	The message transmission from the Mailbox Transport Submission service to the Transport service failed.
SUPPRESSED	The message transmission was suppressed.
THROTTLE	The message was throttled.
TRANSFER	Recipients were moved to a forked message because of content conversion, message recipient limits, or agents. Sources include ROUTING or QUEUE.

Source values in the message tracking log

The values in the source field in the message tracking log indicate the transport component that's responsible for the message tracking event. The following table describes the values of the source field.

Source value	Description
ADMIN	The event source was human intervention. For example, an administrator used Queue Viewer to delete a message, or submitted message files using the Replay directory.
AGENT	The event source was a transport agent.
APPROVAL	The event source was the approval framework that's used with moderated recipients. For more information, see Manage message approval.
BOOTLOADER	The event source was unprocessed messages that exist on the server at boot time. This is related to the LOAD event type.
DNS	The event source was DNS.
DSN	The event source was a delivery status notification (also known as a DSN, bounce message, non-delivery report, or NDR).
GATEWAY	The event source was a Foreign connector. For more information, see Foreign Connectors.
MAILBOXRULE	The event source was an Inbox rule. For more information, see Inbox rules.
MEETINGMESSAGEPROCESSOR	The event source was the meeting message processor, which updates calendars based on meeting updates.
ORAR	The event source was an Originator Requested Alternate Recipient (ORAR). You can enable or disable support for ORAR on Receive connectors using the OrarEnabled parameter on the New-ReceiveConnector or Set-ReceiveConnector cmdlets.
PICKUP	The event source was the Pickup directory. For more information, see Pickup Directory and Replay Directory.
POISONMESSAGE	The event source was the poison message identifier. For more information about poison messages and the poison message queue, see Queues and messages in queues
PUBLICFOLDER	The event source was a mail-enabled public folder.
QUEUE	The event source was a queue.
REDUNDANCY	The event source was Shadow Redundancy. For more information, see Shadow redundancy in Exchange Server.
RESOLVER	The event source was the recipient resolution component of the categorizer in the Transport service. For more information, see Recipient resolution in Exchange Server.
ROUTING	The event source was the routing resolution component of the categorizer in the Transport service.
SAFETYNET	The event source was Safety Net. For more information, see Safety Net in Exchange Server.
SMTP	The message was submitted by the SMTP send or SMTP receive component of the transport service.
STOREDRIVER	The event source was a MAPI submission from a mailbox on the local server.

Example entries in the message tracking log

An uneventful message sent between two users generates several entries in the message tracking log. You can see the results using the Get-MessageTrackingLog cmdlet. For more information, see Search message tracking logs.

This is an example of the message tracking log entries created when the user chris@contoso.com successfully sends a test message to the user michelle@contoso.com. Both users have mailboxes on the same server.

EventId    Source      Sender            Recipients             MessageSubject
-------    ------      ------            ----------             --------------
NOTIFYMAPI STOREDRIVER                   {}
RECEIVE    STOREDRIVER chris@contoso.com {michelle@contoso.com} test
SUBMIT     STOREDRIVER chris@contoso.com {michelle@contoso.com} test
HAREDIRECT SMTP        chris@contoso.com {michelle@contoso.com} test
RECEIVE    SMTP        chris@contoso.com {michelle@contoso.com} test
AGENTINFO  AGENT       chris@contoso.com {michelle@contoso.com} test
SEND       SMTP        chris@contoso.com {michelle@contoso.com} test
DELIVER    STOREDRIVER chris@contoso.com {michelle@contoso.com} test

Security concerns for the message tracking log

No message content is stored in the message tracking log. By default, the subject line of an email message is stored in the message tracking log. You might need to disable subject logging to comply with increased security or privacy requirements. For instructions on how to disable subject logging, see Configure message tracking.

שתף באמצעות