This article contains information on troubleshooting email delivery issues, including steps to identify and resolve failed or delayed messages, analyze message tracking data, and confirm delivery or failure causes for both inbound and outbound emails.
Messages not being delivered, or being delayed in delivery, frustrates end users, causing them to raise support calls because they have received a non-delivery report or a message has not been received or delivered.
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 that 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 was not delivered:
- Obtain as much information as possible regarding the message (e.g., sender and recipient, date and time sent).
- Try to establish if the sender received an NDR or postmaster notification.
- Navigate to Message Center | Message Tracking and perform a search based on the information obtained.
- 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 Viewer | The 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 Messages or Archive Search | The 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 Queue | The message is currently queued on delivery retry. If the recipient's mail server is not currently accepting email or their DNS hosting service is experiencing issues, messages are queued on retry. |
| Accepted Messages or Archive Search | The 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 is not shown in Message Tracking, it could be that your internal mail server has not 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:
- Obtain as much information as possible (e.g., sender and recipient, date and time sent).
- Try to establish if the sender received an NDR or postmaster notification.
- Navigate to Message Center | Message Tracking and perform a search based on the information obtained.
- 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 Viewer | The 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 Viewer | The message was accepted by us, but your internal mail server has rejected it. |
| Accepted Messages or Archive Search | The 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 | |
| Held | The message has been placed on hold due to a content scanning policy (e.g. Attachment Management, Content Examination). |
| Connection Attempts | The message has been subjected to additional checks (temporary failure), typically as a result of greylisting or a real-time reputation check. |
| Accepted Messages or Archive Search | The 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 does not 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:
- Obtain as much information as possible (e.g., sender and recipient, date and time sent).
- Perform a search based on the information obtained.
- 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:
| Viewer | Description |
|---|---|
| Accepted Messages | Messages remain in accepted emails between two and 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 Search | Once messages are indexed, de-duplicated, compressed, and encrypted, they're archived. |
Comments
Please sign in to leave a comment.