Rejected and Deferred Messages

Updated

This article describes how you can troubleshoot recently failed inbound delivery attempts by interrogating the Rejected and Deferred Messages queue in Message Center in the Administration Console.

About Rejected Messages

  • There are multiple reasons why Mimecast rejects messages, e.g., they contain a virus signature or were destined for a non-existent recipient. Message data cannot be retrieved in these cases; a rejection code is sent to the sending mail server, which sends a Non-Delivery Report (NDR) to the sender, and the rejection is logged in the Mimecast Rejection Log.
      • Messages rejected before acceptance and indexing into the Archive by the Mimecast gateway cannot be retrieved.  This includes the reasons listed in the Common Rejection Types and Resolutions section below.
      • Messages rejected after acceptance and indexing into the Archive by the Mimecast Gateway may be retrieved from the Archive by a Mimecast Administrator with Protected Content Administrator permissions. 
      • For example, a user has accidentaly clicked Block on a message in the Digest message, or Reject Message and Block Address in Mimecast for Outlook or Mimecast Personal Portal On Hold Messages. Or, an Administrator has rejected messages from the Held Messages queue by mistake.  In these cases, to continue receiving email from the address, remove the address from Blocked or Managed Sender lists, and retrieve those rejected items from the Archive.abc
The rejected message may be forwarded from the Archive by using the Forward option in the Message Details.  This requires Protected Content Administrator permissions. 

About Deferred Messages

  • When a new message is sent to Mimecast, the connection attempt goes through a default compliance check called Greylisting.  See Greylisting Policies - Configurations.
  • The first delivery attempt is logged in Deferred Messages while the delivery attempt is retried. These messages may subsequently be accepted, depending on the reason for the initial temporary failure. If a message is legitimate, you can view the information displayed to address the issue and verify the message is successfully delivered on the next send (or retry) attempt.
  • The sending mail server must make the next connection attempt between one minute and 12 hours after the initial connection attempt to be successful.

The metadata of Rejected and Deferred Messages is retained for a maximum period of 7 days.

Accessing Rejected and Deferred Messages

You can access Rejected and Deferred Messages, by using the following steps:

  1. Log in to the Mimecast Administration Console.
  2. Navigate to Message Center | Rejected and Deferred Messages.
  1. The Rejected message queue displays by default. You can click on the Deferred tab to view Deferred messages.
  2. Select a Message to display the failed delivery properties in the Message Details panel.
    From here, you can permit or block the item, depending on whether you consider the message legitimate, by clicking on Permit for Recipient, or Block for Recipient.
  3. You can export the message information displayed in the Rejected and Deferred Messages queue to an XLSX or CSV file. See Exporting Messages. 

Rejections are logged in daily CSV files for the life of a Mimecast account. See CSV Data.

Searching for Rejected / Deferred Messages

You can search for specific Rejected and Deferred Messages, by using either:

  • The search field searches all messages in the queue.
  • A filter and a search field to search for specific message information.

You can search for a Rejected / Deferred message using the search field, by using the following steps:

  1. Log in to the Mimecast Administration Console.
  2. Navigate to Message Center | Rejected and Deferred Messages.
  3. Enter your search criteria in the Search field.
  4. Either:
    • Press the Enter key.
    • Click on the Search icon.

You can search for a Rejected / Deferred message using the filter, by using the following steps:

  1. Log in to the Mimecast Administration Console.
  2. Navigate to Message Center | Rejected and Deferred Messages.
  3. Click on the All pull-down menu.
  4. Select from one of the following options:
    • Rejection / Deferral Type: Searches on the rejection or deferral type (e.g., "Anti-Spoofing Lockout").
    • From (Envelope): Searches on the sender's envelope header information.
    • To: Searches on the recipient's email header information.
    • Information: Searches on the message's content.
    • IP Address: Searches on the message's sending IP address.
  1. Enter your search criteria in the Search field.
  2. Either:
    • Press the Enter key.
    • Click on the Search icon.

 

Common Rejection Types and Resolutions

Some common rejection types and suggestions for resolving the issue are listed below:

Inbound Check Type Additional Requirements Description
IP Found in RBL The sending IP address is a known spammer and is either listed in a block list or the IP address has a poor reputation. Add the sender's details to a Permitted Senders policy (Configuring Permitted Senders Policies), and remove the sender from the block list.
Sender Failed to Retry This applies to unknown sending addresses where the sending email server has yet to re-attempt message delivery within 12 hours. The temporary fail check is part of the greylisting process. It can be bypassed by configuring Auto Allow Policies, Permitted Senders Policies, or Greylisting Policies.
Invalid Recipient Address The recipient's email address doesn't exist or is incorrect, so we cannot deliver the message. The sender must resend the message to a valid email address.
Virus Signature Detected An anti-virus signature has been triggered, and the message is categorized as malware. Anti-virus checks cannot be bypassed.
Spam Signature Detected An anti-spam definition has been triggered. The message is only rejected if there's a high content of spam words or phrases, with a score of 28 or higher. Anti-spam checks can be bypassed using a Permitted Sender policy.
Envelope Rejected / Manual Envelope Rejected A blocked sender policy has been triggered, preventing us from accepting the message. Delete or modify the Blocked Senders policy to exclude the sender's address (Configuring Blocked Senders Policies).
Rejected by Header-Based Blocked Senders - Block Policy for Header From A blocked sender policy has been triggered, preventing us from accepting the message. The policy is configured to scan the envelope or header address, as the error code describes. Delete or modify the Blocked Senders policy to exclude the sender's address.
Envelope Rejected - Block Policy for Envelope From Address
Rejected by Header-Based Manually Blocked Senders - Block for Manual Block
Anti-Spoofing Lockout - Inbound Not Allowed An Anti-Spoofing Lockout policy has been triggered. It blocks inbound messages from an external source destined for the internal domain, where the external source masquerades as an internal domain sender. Configuring Anti-Spoofing Policies will exclude the sender's address or IP address.
SMTP Code [Error Description] View the Mimecast SMTP Error Codes page for full details. Resolution is dependent on the recipient's MTA.
Invalid Sender Address The next hop mail server has blocked the sender's address. This is normally due to Sender Callback Verification failing and happens when <> (null addresses) are blocked.
IP Reputation Policy The sender's reputation has caused the rejection action. View the Configuring Reputation Definitions and Policies page for further details.
Message Size Limit Reached The message size is too large to be accepted by us. An Email Size Limits Policy will be in effect. See the Configuring Email Size Limits Policies page for further details.
Sender Location (RS) Found in Geographic RBL The message has been sent from an IP address in a blocked location. Configure Configuring Geographical Restriction Definitions and Policies where appropriate.

Malicious QRCode Detection

The message contains a QR code with a malicious URL payload.

An active URL Protection Policy has scanned the extracted URL payload from a QR Code and rejected it based on malicious content.

Common Deferral Types

Reviewing Deferred messages can be helpful when troubleshooting delayed inbound delivery attempts. The mail server must retry the connection to deliver the message successfully. The initial reason for the temporary failure will determine if the email is subsequently accepted. Some common deferral types and additional details for troubleshooting the deferral are listed below:

Deferral Type Deferral Details
Attempt Greylisting Indicates that the sending IP server has been subjected to greylisting. The triplet of information is temporarily failed until the mail server retries the connection.
Sender Dropped Connection The remote mail server deliberately dropped the connection.
Remote Server Timed out The remote mail server timed out during the SMTP conversation, usually while attempting to transfer the email content. A common cause for this is a firewall or other SMTP scanning product located within the sender's infrastructure that prevents the content of the message from being sent. This attempt is logged after ten minutes of inactivity from the remote server.
Connection Timed Out The initial connection is made to Mimecast, but the remote server doesn't continue with the SMTP conversation. Mimecast timed out the connection, waiting for the remote server to send data.
Message Ended Early This can be caused by previously infected files that haven't been cleaned correctly by an anti-virus pro- duct, and traces of the virus are left in the message. This can also be caused by firewall issues on the sender's side or incorrectly configured content rules on a security device.
Local CT IP Reputation Policy (Temporary) The sending IP address has a poor enough reputation for Mimecast to temporarily defer the email (with a 400 series code) but not poor enough to reject the email (with a 500 series code). The database used is dynamic and updates constantly. If the reputation of the IP address remains the same, the message is accepted in future attempts. If the reputation gets worse, the email is rejected.

Auto Allow Policies

Auto Allow policies allow inbound mail to be processed more efficiently by circumventing spam checks. They add external email addresses that internal end users have previously sent emails to in an Auto Allow database. When the external address sends a message to the internal user, Mimecast checks the database to see if the address is present. If so, the message bypasses the usual spam checks applied to inbound mail.

You can add an external sender's address to the Auto Allow database, by using the following steps:

  1. Ask the internal end user to send a message to the original sender, asking them to resend the message in question.
  2. When they do, the recipient is added to the Auto Allow database.
  3. When the sender re-sends the message, it bypasses reputation and spam scanning checks. See Configuring Auto Allow Policies.

See Also...

Related to

Was this article helpful?
14 out of 30 found this helpful

Comments

0 comments

Please sign in to leave a comment.