Permanent MX Resolution Failure Policies

Document created by user.oxriBaJeN4 Employee on Apr 25, 2016Last modified by user.oxriBaJeN4 Employee on Sep 26, 2016
Version 4Show Document
  • View in full screen mode

Permanent MX Resolution Failure policies allow Administrators to specify a threshold of delivery attempts. After the threshold is reached, an outbound message should be hard bounced if the MX resolution performed by the Mimecast Message Transfer Agent (MTA) results in a permanent failure.

Permanent MX resolution failures are typically observed for non-existing / unknown domains.

Occurrences of bounced deliveries can be found under the Bounces section. There are 2 types of bounces:

  • Hard bounces: the recipient server has rejected the communication.
  • Soft bounces: the MTA has reached the final retry.


To check if MX resolution for a domain is likely to result in a permanent failure, you can use free online tools like MX Toolbox. If the transcript option reports there was “NO_ERROR”, even when reporting a time-out, this indicates that the domain does exist. If the transcript reports there was a “NAME_ERROR”, it is highly likely that a permanent failure was encountered and that the domain is unknown.




By default the Mimecast MTA issues a delivery warning notification to the internal sender of an email, should it not have been able to deliver a message to the recipient server in 6 attempts. This typically equates to one hour after sending. If the Mimecast MTA hasn’t managed to deliver the message in 30 delivery attempts, which typically equates to 4 days after sending, it issues a delivery failure notification to the internal sender of the message. Such a retry cycle is common for MTAs in order to cater for transient issues.


Administrators might want to instruct the Mimecast MTA to take items out of the outbound delivery queue faster than this, should it fail to deliver the item. This can be done using the Permanent MX Resolution Failure policy, but only if the recipient domain is truly unknown (e.g. it has not been registered). This is useful when the internal sender has misspelled the recipient domain. By hard bouncing the message earlier, the internal recipient will realize the mistake sooner.


What You'll Need


  • An Administrator Console logon with access to the Services | Gateway | Policies menu item.


Creating a Policy


To create a policy, follow the instructions in the Creating / Changing a Policy article, but using the following options:


Policy NarrativeProvide a description for the policy to allow you to easily identify it in the future.
Number of Delivery Attempts

Set the number of delivery attempts after which a message will be hard bounced should MX resolution result in a permanent failure (typically observed for non-existing domains). Supported values are from 0 to 30. When set to 5 and outbound delivery attempt 5 results in a permanent MX resolution failure, the item will be hard bounced immediately.

Definition Required?