Default Connect Policies

Document created by user.oxriBaJeN4 Employee on Sep 23, 2015Last modified by user.oxriBaJeN4 Employee on Apr 2, 2019
Version 17Show Document
  • View in full screen mode

This guide outlines the default policies created during the Connect process. For ease, they are split between those relevant to your inbound, outbound, and both inbound and outbound email flow.

The implemented policies are dependent on the Mimecast services you have purchased.

Applies To...


  • Administrators on Mimecast accounts that have gone through the Connect process.


Inbound Email Flow


Spam Scanning


See the Configuring Spam Scanning definitions and policies page for further details.


As part of the inbound email security checks, Mimecast uses multiple content-based heuristic scanning engines. These examine the content of messages to look for key phrases, and other identifiers commonly used by spammers. These include content matching rules, DNS based definitions, checksum based definitions, and statistical filtering definitions.


The aim of Mimecast’s initial layers of defense is to reject unwanted spam and malware messages in protocol. However, there are occasions where Mimecast cannot determine if a message is wanted by the end user or not (e.g. promotional notifications, newsletters or advertisements). In such scenarios, you can configure spam scanning to check the content of all inbound email.


Spam scanning can be configured to apply to different levels of sensitivity and actions, should the policy be triggered. If an email address, domain name or IP address is added as a Permitted Sender, either on the customer account or globally, the inbound message will always bypass these content-based spam checks, but virus scanning will still apply.




See the Configuring Greylisting policies page for further details.


Greylisting looks at three pieces of information (which we will refer to as a "triplet" from now on) about any particular email delivery attempt:

  • The IP address of the host attempting the delivery.
  • The envelope sender address.
  • The envelope recipient address.


With this triplet, Mimecast has a unique relationship for that particular SMTP session. If we have never seen this triplet before, we issue a server busy status (451 Internal resource temporarily unavailable). This server busy status is maintained for 60 seconds, forcing the sending server to queue and retry. This is a 400 message (temporary error) and not a 500 message (permanent error). A correctly configured Message Transfer Agent (MTA) will attempt retries if given an appropriate temporary failure code for a delivery attempt.


If the message comes back after 60 seconds, and before the 12 hour upper limit, the message will be not be subjected to further greylisting. If the message is not retried within this 12 hour period, an entry is logged in the Rejection Viewer as “Sender Failed to Retry” (12 hours after the initial attempt). If the message returns after 12 hours, the greylisting process starts again. An Exchange server, by default, will retry email every ten minutes up until a certain point. Greylisting is applied to all inbound email by default.




See the Configuring Anti-Spoofing policies page for further details.


This policy is used to avoid spoofing. The policy is configured to apply anti-spoofing to email from your domain to your domain. When configuring this policy, administrators should ensure they don’t have external clients that send email appearing to be from the internal domain to internal users.


Permitted Senders


See the Configuring Permitted Senders policies page for further details.


If a permitted senders policy applies to a message, it is passed through the system without the application of any additional spam checks.

A permitted senders message is still subject to system wide message compliance and virus checks. Adding an address to the permitted senders list, just removes the message from additional spam checks.

Auto Allow


See the Configuring Auto Allow policies page for further details.


Auto allow lists produce the same result as a normal permitted senders list, which is the bypassing of spam checks. The policy asks Mimecast to review its sender / receiver database, to determine if an internal email sender has sent a message to the address from which a new message is arriving. This policy is used to build individual auto whitelist.

In general, the auto allow policy is set to apply from "Everyone" to "Everyone". The policy system offers flexibility for auto allow policies to only apply in certain cases, but the "Everyone" to "Everyone" is the most common application.

Auto Allow policies bypass greylisting policies and spam scanning policies for known senders.


Digest Sets


See the Configuring Digest Sets definitions and policies page for further details.


Mimecast will automatically create a digest set definition and policy.


Delivery Routing


See the Configuring Delivery Routing definitions and policies page for further information.


Delivery routes determine the route to be used for inbound email delivery. By default, outbound emails will be delivered to the recipient using available MX records. However, if an outbound delivery route has been configured, this would override the MX record. Delivery routes require the specific route to be configured, and a policy to determine the flow of traffic. Alternate routes can also be created. This enables a failover option, should a customer’s primary route be unavailable. If multiple similar routes (the FROM and TO variables are the same) are configured, this results in a round robin (random selection) of these routes. This is also useful to balance mail server load.


Delivery routes contain the details of the delivery destination (e.g. the hostname or IP Address of the email server). Mimecast’s flexible routing policies allow emails to be delivered to a specific server based on a domain, group, attribute, or individual address.


DNS Authentication: Inbound Check


See the DNS Authentication - Inbound Checks page for further information.


DNS authentication is helpful in preventing unwanted and potentially harmful messages from reaching users. When enabled, inbound DNS authentication checks are performed against all messages regardless of any auto allow or permitted sender entries. The following actions can be applied depending on the result of the inbound checks performed:

  • Reject
  • Ignore managed / permitted sender entries
  • Take no action


By default, inbound DNS authentication policies are configured to ignore managed or permitted sender entries when a failure result is returned by the SPF, DKIM, and DMARC checks that are performed. This means that should one of the configured checks fail, the message will be subject to reputation and spam checks.


Outbound Email Flow


Stationery Assignment


See the Configuring Stationery Layout definitions and policies page for further details.


By default, a disclaimer will be applied to all outgoing email. The following examples show a couple of regional variations of this content:


Example 1 (UK & US):


"This email message has been delivered safely and archived online by Mimecast. For more information, please visit"


Example 2 (South Africa):


"The information contained in this communication from the sender is confidential. It is intended solely for use by the recipient and others authorized to receive it. If you are not the recipient, you are hereby notified that any disclosure, copying, distribution or taking action in relation to the contents of this information is strictly prohibited and may be unlawful.


This email has been scanned for viruses and malware, and automatically archived by Mimecast SA (Pty) Ltd, an innovator in Software as a Service (SaaS) for business. Mimecast offers email continuity, security, archiving and compliance with all current legislation. To find out more, contact Mimecast."


Message Actions


See the Configuring Message Actions policies page for further details.


A message actions policy is used to control usage features for Mimecast for Outlook, in conjunction with your Application Settings.


Inbound and OutBound Email Flow


Attachment Sets


See the Configuring Attachment Management definitions and policies page for further details.


Most malware is hidden in attachments. As such, it is important to restrict what attachments are allowed in and out of your environment. Attachment sets provide a list of attachments, that can be used to configure what file types should be allowed, blocked, linked, or held when being sent outbound or inbound into your Mimecast account. A default attachment set is created during the Connect process. It uses Mimecast's best practice dangerous file types, all of which are set to be blocked.


Attachment handling can also be applied to assist in reducing bandwidth and resource abuse by users. The largest part of a message is always the attachment, so enabling restrictions to attachments will assist with efficiency levels with regards to email processing and storage.

Attachment set policies are available on specific Mimecast subscriptions.

Blocked Senders


See the Configuring Blocked Senders policies page for further details.


Blocked senders policies are almost identical to anti-spoofing policies, but they are applied to all types of email: inbound and outbound.

It's more efficient to create a blocked sender policy against a profile group, and to maintain all suspect email addresses and domains into that profile group. This means that any number of specific email domains or email addresses can be blocked, without the need to create a new blocked sender entry for each offending domain or address.

A policy from "EXTERNAL" to "EXTERNAL" is created by default to prevent open relay out to another external environment. You cannot make changes to this policy. A new blocked senders policy can be created to override aspects of the default policy, but you cannot configure an additional "EXTERNAL" to "EXTERNAL" blocked senders policy.


If you wish to allow external email to relay to another email address, you can add this address to the "Relay" folder under Directory | Profile Groups (commonly used when forwarding from exchange to external contacts). There is a policy in place for this that is assigned to a relay folder.


Email Size Limits


See the Configuring Email Size Limits policies page for further information.


By default, the maximum acceptable size is 100 MB for legacy gateway customers, and 200 MB for customers utilizing the latest gateway.


Suspected Malware


See the Configuring Suspected Malware definitions and policies page for further information.


Mail containing the following file types in a ZIP file, are held in the hold review queue and marked as suspected malware:

  • EXE
  • COM
  • PIF
  • SCR
  • CPL
  • MSI


Encrypted ZIP files are not affected by this system. The intended recipient receives a notification and will need to ask their administrators to release the message. This system works independently of any attachment management policy that you may have created and can be bypassed via a suspected malware bypass policy  We do not recommend that you implement such a policy, as it means new virus outbreaks might go undetected while signatures are being updated. This ensures comprehensive protection for all customers regardless of their individual settings.


The default suspected malware definition and policy are implemented by default for all inbound emails.


Archive Limit Reached / Archive Extract Error


See the Configuring Message Passthrough policies page for further details.


Archived limit reached means that one of the following limits has been reached:

  • 5 levels of .ZIP file recursion.
  • 10,000 files per .ZIP file.
  • Maximum unpacked file size 100 MB.
  • Total maximum unpacked size 2GB.
The "Archive Extract Error" gets thrown for unsupported .ZIP files (e.g. .ZIPX).

As the platform was not able to correctly extract the archive it couldn’t be examined against your policies and definitions. The message is automatically placed in the on hold queue, allowing you to examine it and take appropriate action.


To allow such items to be received without being placed on hold, configure a Message Passthrough policy. This stops the platform from examining the communication, and policies configured for particular components of a message no longer apply. We recommend that you configure the message passthrough policy to be as specific as possible. For example:

  • Policy Options: Do not explode message content.
  • Applies From: Individual email address.
  • Specifically: Enter the sender email address.
  • Applies To: Individual email address or domain.
  • Specifically: Enter the recipient email address or domain


Suspicious Message Structure


See the Suspicious Message Structure page for further details.


Items placed in the hold review queue due to “Suspicious Message Structure”, indicate the message has not been correctly structured, based on RFC822 and RFC1123 (Request for Comment) documents published by the Internet Engineering Task Force. Mimecast provides extensive checking based on the structure and make up of these messages to prevent any malicious or dangerous email from entering a mail environment. Although it is common that many mail servers and clients do not conform to the RFC standards, we are flexible on the format we accept and hold only the problematic instances. The notification the recipient receives is similar to the following:


This is a content alert notification message.


The message indicated below matches content alert policies set by the System Administrator(s).


Message information:


Sender : sending address


Intended Recipient : recipient address


Message Subject : subject


Message Date : date and time


Message Status : The message has been placed on HOLD - action required


Content Policies Triggered:


- This message is badly structured and may contain dangerous content


Some of the reasons for messages being placed in the hold queue “Suspicious Message Structure” can be the following:


Incorrect encoding of a message


An example would be if we have received a message that has been encoded by a system in a binary format. This can result in a corrupt email, mail folder on the recipient's mail folder, or mail program. It’s unlikely that the file will even be usable, and the sender should try and send the message again.


See the Content-Transfer-Encoding: binary page on the Microsoft website for further details.


Mail format that should not be sent over the internet


An example could be a message that has a WINMAIL.DAT attachment with a number of formatting irregularities. This format is only supported by Microsoft Exchange, as the .DAT file contains formatting components for a specific email client application. The sending machine should not allow messages with this formatting to traverse the internet, as not all mail servers can interpret the file.


To get around the above issue, Microsoft recommends the following resolutions on their website:


Messages that are placed in the hold for review queue and subsequently determined to be safe can be released so by carrying out the following actions:

  • Select the message in question and proceed by clicking on “Release Selected Items”.
  • If the sending party can't resolve the issue on their end, you can prevent these messages from being placed on hold by configuring a Message Passthrough policy.


The policy should be set up with:

  • Policy Options: Do not explode message content.
  • Applies From: Individual email address.
  • Specifically: Enter the sender email address.
  • Applies To: Individual email address or domain.
  • Specifically: Enter the recipient email address or domain


Application Settings


An application settings definition is enabled for all internal users and provides access to all Mimecast user tools. This default definition cannot be edited, but additional definitions can be created to apply to specific user groups. See the Configuring Application Settings page for further details.


See Also...


3 people found this helpful