This article contains information on configuring Permitted Senders policies, to ensure trusted senders' emails bypass certain checks, usage considerations, and step-by-step instructions for setting up these policies effectively.
Permitted Sender policies ensure the successful delivery of inbound messages from trusted sources. Messages from Permitted Senders bypass Reputation, Greylisting, and Spam Scanning Policies, avoiding the possibility of being rejected or placed in a Held queue. It is useful when the sender's messages are flagged by the aforementioned checks Mimecast performs.
Configuring Permitted Senders
See Policy Specificity for more information regarding the order in which Mimecast applies policies to emails.
This video explains the default best practice configuration.
Usage Considerations
Consider the following before creating a policy:
- Creating a Policy for all Permitted Senders isn't necessary, only if a sender is having difficulty sending messages to your end-users.
- End-users have a personal Permitted Sender list called Managed Senders. These are configured using the Digest Email, or when logged onto the Mimecast Personal Portal or Mimecast for Outlook.
- Referencing a Profile Group lets you minimize the number of Permitted Sender policies you need. A specific policy is only required if the domain entry contains a wildcard. This requires a separate policy to permit by IP (scoped as Everyone to Everyone).
- Blocked Senders Policies always supersede Permitted Senders Policies. This means messages from a domain or email address added to both a Blocked Senders AND Permitted Senders policy are rejected.
- An entry on a user's Blocked Senders list in Managed Senders, whether an administrator or a user has added it, is always superseded by a Permitted Senders policy if it relates to Envelope addresses. So, if an administrator wants to ensure a message is delivered, despite a user having the sender Blocked in their Managed Senders list, you must add the Envelope address to a Permitted Senders policy.
- If you have Targeted Threat Protection - Attachment Protection enabled, we recommend selecting the Dynamic Configuration under the Attachment Protection | Delivery Options setting when configuring this definition. Doing this takes the onus away from the administrator by giving control to users to decide who to permit. See Configuring Attachment Protection.
- These policies will not prevent virus checks, which always take place regardless.
Configuring a Permitted Senders Policy
You can configure a Permitted Senders policy by using the following steps:
- Log in to the Mimecast Administration Console.
- Navigate to Policies | Gateway Policies | Permitted Senders.
- Either select the:
-
- Policy to be changed.
- New Policy button to create a policy.
- Complete the Options section as required:
| Option | Description |
|---|---|
| Policy Narrative | Enter a description of the policy to allow you to identify it. |
| Permitted Senders Policy | Specify what action needs to be taken from the available options:
• Take no action: This setting means that the policy does not "permit" the relevant sending domain(s) and Spam actions, Greylisting checks, and RBL checks to be performed. Configuring Permitted Sender policies that apply to addresses found in Message Headers (P2) or Both (Check both Envelope and Header), Greylisting and RBL checks cannot be bypassed, as these are Envelope-based checks and cannot be bypassed. |
Based on the above options, you will see one of the following receipt events when viewing message details in the Mimecast Administration Console. These events include the check that was performed even though a Permitted Sender policy was applied:
-
- Email Received via Permitted Sender Perform Spam Scanning.
- Email Received via Permitted Sender Perform RBL.
- Email Received via Permitted Sender Perform Greylisting.
- Email Received via Permitted Sender Perform Spam Scanning And Greylisting.
- Email Received via Permitted Sender Perform Spam Scanning and RBL.
- Email Received via Permitted Sender Perform Greylisting and RBL.
- Email Received via header-based Permitted Sender Perform Spam Scanning.
Now that we may not bypass Greylisting, RBL, and Spam checks for inbound messages, it is important to check the results of these checks to understand why a message was not delivered. This is because we may no longer bypass all of these checks.
- Complete the remainder of the policy as necessary; refer to the Policy Basics if needed.
- Click on Save and Exit.
Comments
Please sign in to leave a comment.