Troubleshooting Email Delivery

Document created by user.oxriBaJeN4 Employee on Sep 11, 2015Last modified by user.oxriBaJeN4 Employee on Aug 20, 2018
Version 3Show Document
  • View in full screen mode

Messages not being delivered, or being delayed in delivery, frustrates end users causing them to raise support calls because they've received a non‐delivery report or a message hasn't been received or delivered.

Troubleshooting_Scenarios.png

An administrator must be able to troubleshoot these queries and determine why email delivery was delayed or has failed. For successfully delivered messages, having the ability to search and review the emails' headers and transmission details, allows you to prove delivery or chains of custody.

 

Using the information available from the end user and our viewers and queues can vastly decrease the time spent determining what happened to a message. 

We log all connections whether successful or not.

Troubleshooting Scenarios

 

When troubleshooting email delivery, it's helpful to group these queries into scenarios which can apply to both inbound and outbound emails:

 

Outbound Email

 

An outbound message not being delivered could be a result of either a failed or delayed delivery of the message. Follow the troubleshooting steps below to determine why the email wasn't delivered:

  1. Obtain as much information as possible regarding the message (e.g. sender and recipient, date and time sent).
  2. Try and establish if the sender received an NDR or postmaster notification.
  3. Select the Message Center | Message Tracking menu item and perform a search based on the information obtained.
  4. From the results, select the message, and analyze the information provided.

 

Below are the possible viewers and queues, and email troubleshooting scenarios:

 

Failed Delivery
Bounce ViewerThe message is accepted by us, but cannot be delivered to the next hop mail server. Typical reasons for the bounce could be due to an incorrect recipient email address, or if the email has a large attachment.
Accepted Emails or Archive SearchThe message is accepted by us and delivered to the next hop. However there may be a failure further along in the message's delivery. Delivery of the message can be confirmed by reviewing the delivery transmission data of the message.

 

Delayed Delivery
Delivery QueueThe message is currently queued on delivery retry. If the recipient's mail server isn't currently accepting email, or their DNS hosting service is experiencing issues, messages are queued on retry.
Accepted Emails or Archive SearchThe message is accepted by us and delivered to the next hop. However there may be a delay further along in the message's delivery. Delivery of the message (including date / time) can be confirmed by reviewing the delivery transmission data of the message.

If this message isn't shown in Message Tracking, it could be that your internal mail server hasn't delivered it to us, or has bounced the message.

Inbound Email

 

An inbound message not being received could be a result of either a failed or delayed delivery of the message. Follow the troubleshooting steps below to determine why the message hasn't been received:

  1. Obtain as much information as possible (e.g. sender and recipient, date and time sent).
  2. Try and establish if the sender received an NDR or postmaster notification.
  3. Select the Message Center | Message Tracking menu item and perform a search based on the information obtained.
  4. From the results, select the message and analyze the additional information provided.

 

Below are the possible viewers and queues, and email troubleshooting scenarios:

 

Failed Delivery
Rejection ViewerThe message was rejected by us in protocol. This is typically based on the sender's details (email address, or IP address) or email content.
Bounce ViewerThe message was accepted by us, but your internal mail server has rejected it.
Accepted Emails or Archive SearchThe message was accepted by us and delivered to the next hop. However, there is a failure in delivering it internally. Delivery can be confirmed by reviewing the delivery transmission data of the message.

 

Delayed Delivery
HeldThe message has been placed on hold due to a content scanning policy (e.g. Attachment Management, Content Examination).
Connection AttemptsThe message has been subjected to additional checks (temporary failure) typically as a result of greylisting or a real-time reputation check.
Accepted Emails or Archive SearchThe message was accepted by us and delivered to the next hop. However, there is a delay in delivering it internally. Delivery (including date/time) can be confirmed by reviewing the delivery transmission data of the message.

If the message doesn't show in Message Tracking, it could be that it was rejected prior to Mimecast.

Proving Message Delivery

 

There may be occasions when you need to prove a message was delivered, confirm the mail servers involved, or determine the date and time it was delivered by us. To do this:

  1. Obtain as much information as possible (e.g. sender and recipient, date and time sent).
  2. Perform a search based on the information obtained.
  3. From the results, select the message and analyze the transmission information. This includes reviewing the receipt and delivery view and what policies were applied to the message.

 

Depending on when the email was sent determines which viewer to use to perform a search:

 

ViewerDescription
Accepted EmailMessages remain in accepted emails between two to six hours. During this time messages are compressed, encrypted, indexed and moved to the archive. Alternatively, a message may remain in accepted emails until it reaches its final state (e.g. successful or failed delivery).
Archive SearchOnce messages are indexed, deduplicated, compressed and encrypted, they're archived.
2 people found this helpful

Attachments

    Outcomes