Export (0) Print
Expand All

Message trace FAQ

Exchange 2013
 

Applies to: Exchange Online Protection, Exchange Online

Topic Last Modified: 2014-05-20

This topic presents messaging questions that a user may have, along with possible answers. It also describes how to use the message trace tool in order to get those answers and troubleshoot specific mail delivery issues.

When you run a message trace for messages less than 7 days old, the search results appear immediately. When such a message is sent to a recipient, it should take between 5-10 minutes to appear in the message trace data.

When you run a message trace for messages greater than 7 days old, the search results may take up to a few hours.

You can use the following remote Windows PowerShell cmdlets to run a message trace:

Get-MessageTrace - Use this cmdlet to trace messages that are less than 7 days old.

Get-MessageTraceDetail - Use this cmdlet to view the message trace event details for a specific message.

Get-HistoricalSearch   Use this cmdlet to view information about historical searches (searches for messages that are greater than 7 days old) that have been performed within the last ten days.

Start-HistoricalSearch – Use this cmdlet to start a new historical search.

Stop-HistoricalSearch- Use this cmdlet to stop an existing historical search that has a status value of NotStarted.

To learn how to use Windows PowerShell to connect to Exchange Online Protection, see Connect to Exchange Online Protection using remote PowerShell. To learn how to use Windows PowerShell to connect to Exchange Online, see Connect to Exchange Online using remote PowerShell.

The likely cause of a timeout error is that the query is taking too long to process. Consider simplifying your search criteria. You may want to consider using remote PowerShell, which has more liberal timeout requirements.

Possible reasons include the following:

  • The message was detected as spam.

  • The message was sent to quarantine due to a rule match.

  • The message was rejected

    • By the malware filter

      • Because a file attached to the message contained malware

      • Because the message body contained malware

    • By a rule

      • Because the action was Reject

      • Because the action was Force TLS and TLS failed to be established

    • By a connector because TLS was required and failed to be established

  • The message was sent for moderation and is awaiting approval or was rejected by the moderator.

  • The message was never sent.

  • The message is still being processed because there was a previous failure and the service is re-attempting delivery.

  • The message failed to be delivered to your mailboxes

    • Because the destination is not reachable

    • Because the destination rejected the message

    • Because the message timed out during the delivery attempt

To find out what happened, run the message trace (see Run a message trace). Try to specify parameter values in a manner that will best narrow down your search results. For example, you should know the sender and the intended recipient or recipients of the message, and the general time period during which it was sent. View the results, locate the message, and then view specific details about the message (see View message trace results for messages that are less than 7 days old or View message trace results for messages that are greater than 7 days old). Look for a delivery status of Failed or Pending to explain why the message was not received. Confirm that the message was sent, that it was successfully received by the service, that it was not filtered, redirected, or sent for moderation, and that it did not experience any delivery failures or delays.

Possible reasons include the following:

  • The message was released from quarantine.

  • The message was awaiting moderator approval and was released.

  • The message was spam that was not detected.

  • The message matched a rule that added you to the message.

  • The message was sent to a distribution list of which you are a member.

To find out what happened, run the message trace (see Run a message trace). Try to specify parameter values in a manner that will best narrow down your search results. For example, specify the recipient who received the message, set the delivery status to Delivered, and set the time period based on when the message was received. View the results, locate the message, and then view specific details about the message (see View message trace results for messages that are less than 7 days old or View message trace results for messages that are greater than 7 days old) One of the above-listed unforeseen events is likely the cause of your receiving the message.

Possible reasons include the following:

  • The message was detected as spam.

  • The message was sent to quarantine due to a rule match.

  • The message was re-routed because a connector sent it to another destination.

  • The message was rejected

    • By the malware filter

      • Because a file attached to the message contained malware

      • Because the message body contained malware

    • By a rule

      • Because the action was Reject

      • Because the action was Force TLS and TLS failed to be established

    • By a connector because TLS was required and failed to be established

  • The message was sent for moderation and is awaiting approval or was rejected by the moderator.

  • The message was never sent.

  • The message is still being processed because there was a previous failure and the service is re-attempting delivery.

  • The message failed to be delivered to the destination

    • Because the destination is not reachable

    • Because the destination rejected the message

    • Because the message timed out during the delivery attempt

  • The message was delivered to the destination but it was deleted before it was accessed (perhaps because it matched a rule).

To find out what happened, run the message trace (see Run a message trace). Try to specify parameter values in a manner that will best narrow down your search results. For example, you should know the sender and the intended recipient or recipients of the message, and the general time period during which it was sent. View the results, locate the message, and then view specific details about the message (see View message trace results for messages that are less than 7 days old or View message trace results for messages that are greater than 7 days old) Look for a delivery status of Failed or Pending to explain why the message was not delivered. Confirm that the message was sent, that it was successfully received by the service, that it was not filtered, redirected, or sent for moderation, and that it did not experience any delivery failures or delays. If the destination is not reachable, you can use the To IP to help troubleshoot connectivity issues.

Possible reasons include the following:

To find out what happened, run the message trace (see Run a message trace). Try to specify parameter values in a manner that will best narrow down your search results. For example, you should know the sender and the intended recipient or recipients of the message, and the general time period during which it was sent. View the results, locate the message, and then view specific details about the message (see View message trace results for messages that are less than 7 days old or View message trace results for messages that are greater than 7 days old) The events section will tell you why the message was not yet delivered. When viewing the events, the timestamp information will let you follow the message through the messaging pipeline, and tell you how long the service takes to process each event. The event details will also inform you if the message being delivered is extremely large or if the destination is not responsive.

Messages can be marked as spam for several reasons. For example, the sending IP address may appear on one of the service’s IP Block lists. A message can be marked as spam due to the content of the actual message, such as when it matches a rule in the spam content filter. The message trace tool only tracks spam content filter events; connection filter events (such as blocked IP addresses) are not traceable. For more information about spam filtering, including spam content filtering, see Anti-spam protection.

To find out why a message was marked as spam, run the message trace (see Run a message trace), locate the message in the results, and then view specific details about the message (see View message trace results for messages that are less than 7 days old or View message trace results for messages that are greater than 7 days old). When the content filter marks a message as spam, if it is sent to the Junk Email folder or the quarantine, it will have a status of Delivered. You can view the event details in order to see how the message arrived at its destination. For example, it may inform you that the message was determined to have a high spam confidence level, or that an advanced spam filtering option was matched. You will also be informed of the action that occurred as a result of the message being marked as spam, for example if it was sent to quarantine, stamped with an X-header, or if it was sent through the high risk delivery pool.

Messages are detected as malware when its properties, either in the message body or in an attachment, match a malware definition in of one of the anti-malware engines. For more detailed information about malware filtering, see Anti-malware protection.

To find out why a message was detected to contain malware, run the message trace (see Run a message trace). Try to specify parameter values in a manner that will best narrow down your search results. Set the delivery status to Failed. View the results, locate the message, and then view specific details about the message (see View message trace results for messages that are less than 7 days old or View message trace results for messages that are greater than 7 days old) If the message was not delivered because it was determined to contain malware, this information will be provided in the events section. For example, the following is a sample Detail: Malware: “ZipBomb” was detected in attachment file. zip. You will also be informed of the action that occurred as a result of the message containing malware, for example if the entire message was blocked or if all attachments were deleted and replaced with an alert text file.

To find out which transport rule (custom policy rule) or Data Loss Prevention (DLP) policy (Exchange Online customers only) was applied to a message, run the message trace (see Run a message trace). Try to specify parameter values in a manner that will best narrow down your search results. Set the delivery status to Failed. View the results, locate the message, and then view specific details about the message (see View message trace results for messages that are less than 7 days old or View message trace results for messages that are greater than 7 days old) If the message was not delivered because its contents matched a rule, the events section will let you know the name of the transport rule that was matched. You will also be informed of the action that occurred as a result of the transport rule match, for example if the message was quarantined, rejected, redirected, sent for moderation, decrypted, or any number of other possible options. For information about how to create Exchange transport rules and set actions for them, see Transport rules.

Rule ID-1 is returned when the message trace encounters a transport rule that no longer exists. (The transport rule could have been modified or deleted after the original message was sent.)

You should be aware of the following when using the message trace tool:

  • IP-blocked messages: Messages blocked by IP reputation block lists will be included in the spam data for real time reports, but you cannot perform a message trace on these messages.

  • Redirected messages: If a recipient is rewritten by a transport rule or because the spam action for the domain is set to Redirect to email address, the message is not traceable in a single search. The original message can be traced until to the point when the recipient is changed. After that, the message is not traceable under the original recipient. You can trace the message again using the new recipient.

  • MAIL FROM: The message trace tool uses the MAIL FROM value presented at the initiation of the SMTP conversation as the Sender in a search, regardless of what the DATA section of the message shows. The message may show a Reply-to address or different From: or Sender values. If the email message was sent by a process and not by an email client, there is an increased likelihood that the sender in the MAIL FROM will not match the sender in the actual message.

  • Transport rule updates: When a message matches a transport rule, the rule ID is stored in the message trace and real time reporting databases. If you trace one of these messages, or drill down on rule details in a report, the message trace and real time reporting user interfaces dynamically pull the current rule information from the hosted services network based on the rule ID in the reporting database. If you have changed the attributes of that particular rule since the message was processed (changed it from Reject to Allow, for example), the rule ID stays the same in the message trace and real time reporting returned results, but the Exchange admin center will show the new transport rule properties. You can use the auditing reports feature in order to determine when the rule was changed and the properties that were changed.

  • Spam-filtered messages: When the content filter marks a message as spam, if it is sent to the Junk Email folder or the quarantine, it will have a status of Delivered. Drill down to the event details in order to see how the message arrived at its destination.

 
Was this page helpful?
(1500 characters remaining)
Thank you for your feedback
Show:
© 2014 Microsoft