Greylisting Policies

Document created by user.oxriBaJeN4 Employee on Sep 12, 2015Last modified by user.oxriBaJeN4 Employee on Sep 26, 2016
Version 5Show Document
  • View in full screen mode

Greylisting is a default compliance check applied to all inbound email for connections not previously seen by Mimecast. Provided the senders mail server (Message Transfer Agent - MTA) complies with best practice guidelines (RFC compliance), the mail will be successfully delivered.


Greylisting looks at three pieces of information for the delivery attempt:

  • The IP address of the MTA
  • The envelope sender address
  • The envelope recipient address


With this triplet, Mimecast has a unique relationship for that particular SMTP session. If Mimecast has never seen this triplet before, a server busy status (451 Resource is Temporarily Unavailable) is issued. This server busy status is a temporary failure and is maintained for 60 seconds, forcing the sending server to queue and retry. A correctly configured MTA will always attempt to retry the email delivery. If the MTA retries after 60 seconds and before the 12 hour upper limit, the email will be accepted. If the message is not retried within this 12hr period, an entry is then logged in the Rejection Viewer as Sender Failed to Retry (12hrs after the initial attempt). If the sending MTA attempts again after 12 hrs from the initial attempt, then the greylisting process starts again.

By default, an Exchange server will retry email every 10 minutes until the email retries expire.

Any sender email address, domain or IP address that has been added to the Auto Allow database or a Permitted Senders Policy will not be subjected to Greylisting.


A Greylisting policy is created by default by Mimecast Support during the Implementation process. This is configured to apply to all inbound traffic. There may however be instances where you are experiencing difficulty receiving emails from legitimate senders, whose MTA has not been correctly configured. If the sender’s MTA does not comply with RFC standards, however their emails are deemed to be safe for your organization, then you can create a Greylisting bypass policy.



The vast majority of spam appears to be sent from applications designed specifically for spamming. These applications appear to adopt the "fire-and-forget" methodology. That is, they attempt to send the spam to one or several MX hosts for a domain, but then never attempt a retry as a correctly configured MTA would. By using Greylisting Policies, any emails sent from an incorrectly configured MTA will not be accepted. This helps in reducing a significant amount of spam.


All email connections that have been subjected to greylisting, are logged in Connection Attempts.

What you 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.
Select Option

Select whether to apply greylisting, or to take no action.

Definition required?


4 people found this helpful