Secure Email Gateway:
Security Policies
Student Guide – L1
TABLE OF CONTENTS
MIMECAST EMAIL INSPECTION FUNNEL ............................................................................................................ 4
LESSON 1: POLICY BASICS .................................................................................................................................. 4
GATEWAY POLICY EDITOR......................................................................................................................................... 4
POLICY SPECIFICITY .................................................................................................................................................. 5
POLICY DETAILS ....................................................................................................................................................... 6
LESSON 2: GATEWAY SECURITY POLICIES ......................................................................................................... 7
CONFIGURABLE BLOCK / PERMITS ............................................................................................................................. 7
ANTI-SPOOFING ...................................................................................................................................................... 7
BLOCKED SENDERS ................................................................................................................................................... 9
PERMITTED SENDERS ................................................................................................................................................ 11
AUTO-ALLOW AND AUTO-ALLOW CREATION ........................................................................................................... 12
MANAGED SENDERS ............................................................................................................................................... 14
DNS AUTHENTICATION ........................................................................................................................................... 15
REPUTATION ........................................................................................................................................................... 17
GREYLISTING.......................................................................................................................................................... 18
SPAM SCANNING................................................................................................................................................... 20
SECURE DELIVERY AND RECEIPT ............................................................................................................................... 21
LESSON 3: DATA LEAK PREVENTION POLICIES ................................................................................................ 22
SECURE MESSAGING .............................................................................................................................................. 22
CONTENT EXAMINATION......................................................................................................................................... 24
LESSON 4: ATTACHMENT POLICIES .................................................................................................................. 29
SUSPECTED MALWARE............................................................................................................................................. 29
ATTACHMENT MANAGEMENT .................................................................................................................................. 30
LESSON 5: END USER NOTIFICATIONS OVERVIEW .......................................................................................... 31
DIGEST SETS ........................................................................................................................................................... 31
NOTIFICATION SETS ................................................................................................................................................ 33
©2021 Mimecast. All Rights Reserved
|1
Prerequisites
•
Experience with configuring and supporting Microsoft Exchange, Office 365 EOP or any other mail
server
Course Objectives
This course is designed to help Administrators understand the basics of the Mimecast Gateway Security policies. These
policies protect inbound and inbound email flow from spam, malware, phishing and targeted attacks.
Following this course, you should be able to:
•
•
•
•
•
Understand the Mimecast Email Inspection funnel
Explain how policies work
Identify the policies that are set up by default
Understand basic spam and virus protection concepts
Explain what each of the policies do and where to find them
©2021 Mimecast. All Rights Reserved
|2
How this Guide Works
This guide has been designed to follow the structure of the instructor-led training session. Here you will find the use
cases, walkthroughs and scenarios discussed during the session, as well as useful configuration and troubleshooting
tips. In addition, where we can provide you will find some frequently asked questions.
Scenario
These will highlight real-life use cases.
Troubleshooting / Knowledge Tips
These are intended to provide important points or facts that you should be aware of, as well as
helpful troubleshooting tip.
Discussion
There may be times in the course where the instructor asks participants to take part in a
discussion about a particular topic (e.g., to discuss something where there may be more than
one solution to a problem).
Warning or Alert
This is meant to provide you with a warning about something.
Disclaimer: During an instructor-led class, an instructor will demonstrate configuring certain policies, profiles, etc., in
the Administration Console. This is being done in an environment that is safe for demonstration purposes.
If you wish to follow along in your own environment, we advise as follows:
1. Follow along with the configuration steps and cancel instead of saving.
2. In an instance where you follow along configuring a policy, we advise you to set the “To” and “From” address
fields to reference pilot profile groups that have been configured beforehand. Navigate to Directories | Profile
Groups in the Administration Console and add the email addresses you want in the pilot groups. This will
ensure you are testing policies on a small subset of your user population and not your whole organization.
Please Note: Instructors will use Prefixes for some profile groups, definitions and policies. This is for training purposes
only. As an administrator, you would choose the naming conventions that work for you in your environment.
©2021 Mimecast. All Rights Reserved
|3
Mimecast Email Inspection Funnel
The graphic below represents the Mimecast Email Security Inspection funnel. The Secure Email Gateway applies a
dynamic, multi-layered approach to the analysis of inbound, outbound, and internal emails. From higher level
inspections such as DNS authentication, including SPF/DKIM/DMARC, to spam and virus protection.
Lesson 1: Policy Basics
Mimecast Gateway Policies are the set of rules applied to inbound or outbound messages that affect the flow of email
traffic. The most important policies you will need are very likely already built during your implementation depending
on the Mimecast products purchased.
When creating policies, learn more from the Gateway Policy Types article in our Knowledgebase.
To be more specific:
•
•
Definitions define what needs to happen.
Policies define when definitions are applied based on sender, receiver, time, and other parameters.
Some policies work on their own without a definition (for example, Greylisting and Anti
spoofing) whereas others require a link to a definition.
Gateway Policy Editor
The policy editor can be found under Administration | Gateway | Policies and is used to manage the policies and
definitions in the Administration Console.
Take note, there is a Definitions drop-down menu in the upper left and there are Definition buttons to the right of the
policies that require a definition. Both options will direct you to the definition for a particular policy type.
In the Policy Editor, you will see a Policy Name Column with the name of the policy and a Description Column that
provides detail. In addition, there are columns labeled Policies and Definitions. These have numbers that represent
the number of policies and definitions for each. They also have a Tell Me More button in the far right which will take
you to the relevant Knowledgebase articles.
©2021 Mimecast. All Rights Reserved
|4
Policy Specificity
Mimecast applies policies to messages based on specificity. The
more specific a policy is, the higher the priority.
For example, a policy specifying a single individual email
address is very specific and is favored above a policy applied to
everyone (which is the least specific of all). See the table below
and the article here to understand the different levels of
specificity.
Each policy performs an action that is applied to messages as
they are processed by the Mimecast Gateway. In many cases,
more than one policy of the same type (e.g., Blocked Senders) is
considered for the same message, but only the most specific
policy of that type is applied.
Specificity Level
Everyone
Internal Addresses
External Addresses
Email Domain
Freemail Domains
Address Groups
Header Display Name
Address Attributes
Individual Email Address
Description
This is the least specific of all from / to options and includes all email addresses.
All addresses internal to your account, typically found under Directories > Internal
Directories.
All addresses external to your account, typically found under Directories >
External Directories.
Enables you to specify one or more domain names to which the policy is applied.
Only available under the "Email From" section of Impersonation Protection
policies. Includes sender domains that are present on a Mimecast list of freemail
domains.
Enables you to specify a predefined Directory or Profile Group which could hold
domain names or individual addresses.
Only available under the "Email From" section of Impersonation Protection
policies when the "Addresses Based On" option has been set to "The Message
From Address" or "Both". This enables you to specify a Header Display Name.
Enables you to specify a predefined attribute and can only be used when
attributes have been configured.
This is the most specific of all from / to options and relates to a single email
address.
Using Policy Specificity
Mimecast uses a multi-threading process where policies are applied simultaneously but only the policy that matches is
applied.
There are some exceptions to this rule:
•
•
Content Examination
Content Examination Bypass
©2021 Mimecast. All Rights Reserved
|5
•
•
•
Impersonation Protection
Impersonation Protection Bypass
Smart Tag Assignment
These policy types are cumulative. When multiple cumulative policies match the From and To of a message, all those
cumulative policies are applied to the message and the appropriate action(s) taken.
Equal Specificity
For policies (except cumulative policies), where there is equal specificity between two (or more) policies of the same
policy type, the following logic is applied to decide which policy needs to be applied:
Recipient Trumps Sender: When there is equal specificity, the "Emails To" value receives a slightly higher score. This
means the Mimecast Gateway considers the recipient more specific than the sender.
Conditions: Where there is equal specificity, and the "recipient trumps sender" logic does not resolve this, a policy that
has a matching "Source IP Range" or matching "Hostname" validity condition is considered to be more specific.
Most Recently Created: Where there is equal specificity and the "recipient trumps sender" and "conditions" logic do
not resolve this, the most recently created policy is favored.
Use this article to see some specificity examples based on Messages From / Emails To Details as well as working with
groups.
Policy Details
When creating or editing a policy, there will be three sections:
1. Options: Here you enter a name for the policy and select either the
Action to take or the definition you are applying to the policy.
2. Emails From and To: Here you need to specify the conditions an email
has to have to activate the policy. This includes the Emails “From” and
“To” addresses.
3. Validity: Choose to enable / disable a policy, determine the time the
policy will be active, along with IP ranges if applicable.
Set policy as perpetual: Always On if you do not wish to provide a date
range for the policy to be valid.
Date Range: If you wish for your policy to be valid for a specific date
range.
Policy Override: If the Policy Override option is enabled, the policy will be considered before those that do not
have it enabled. When multiple policies have it enabled, those policies will follow the specificity rules to determine
which should apply to your email. If none of those policies apply, only then will your remaining non-override,
policies be considered using the specificity rules.
Bi-Directional: Applies the policy in the reverse mail flow so the policy is applied in both directions.
Source IP Ranges: If a Policy is configured with both a specific FROM variable and source IP address, only emails
which match both of these properties will trigger the Policy. Alternatively, if you would like to specify only the
source IP address, select the FROM variable as Everyone, and enter the desired IP address/range in the Source IP
Range field.
To navigate to a policy, go to Administration | Gateway | Policies and click on a policy to open it.
©2021 Mimecast. All Rights Reserved
|6
Lesson 2: Gateway Security Policies
There are features that are activated by default on all new Mimecast accounts that provide out of the box protection.
They are a starting point for your Mimecast journey, and can be left as they are or amended to build a configuration
that suits your needs.
Refer to this article entitled Out of the Box Settings for Mimecast Email Security. Many of these will be discussed in this
course. Those that are not will be covered in our level 2 courseware.
Configurable Block / Permits
In the top three layers of the Email Inspection funnel, we apply different methods of checking who is sending the
email. These checks are controlled by the following policies:
1.
2.
3.
4.
Blocked Senders
Permitted Senders
Auto-Allow
Anti-Spoofing
In the next section, we will take you into the Administration Console and discuss what these policies are used for and
the actions they perform.
Spoofing
Spoofing is the forgery of email headers, so messages appear to come from someone other than the actual source.
This tactic is used in phishing and spam campaigns, as recipients are more likely to open a message that looks
legitimate.
Envelope From and Header From
Sometimes spoofed emails don’t emanate from an attacker. Sometimes this traffic is from legitimate services such as
Survey Monkey or Mail Chimp. These services spoof (pretend to be internal) but they don’t do this in the “envelope
from” of an address. They will usually do this from the “header from” address, however either one of these can be
spoofed. The difference between the Envelope From and Header From is this:
•
•
Envelope From – This is the actual address that is stored behind the scenes
Header From – This is the email address that is displayed when you open an email in Outlook for example.
Anti-Spoofing
An Anti-Spoofing policy is used to avoid spoofing. Having one configured will ensure external messages appearing to
come from an internal domain are blocked. The policy is configured to apply anti-spoofing to email from your domain
to your domain.
Things to be aware of:
•
•
•
•
When an email is blocked/rejected by Mimecast, its content is not kept, so cannot be released, or recovered
by Mimecast, so it’s important that this policy is configured correctly.
If you find that you don’t have a default policy blocking mail from your internal domain to internal addresses,
you will need to create one.
Anti-spoofing can be applied automatically when a customer is registering a domain or sub-domain in your
Mimecast account.
If you have a third-party vendor such as MailChimp, Constant Contact or Salesforce that send email appearing
to be from you, you will need to create an Anti-Spoofing exception policy (outlined below) or an Anti-Spoofing
SPF Based Bypass.
©2021 Mimecast. All Rights Reserved
|7
Usage Considerations
•
•
Anti-Spoofing policies override addresses or domains permitted by users. For example, messages from a
domain added to a user's permitted senders list AND an Anti-Spoofing policy are rejected.
This is a “policy only” configuration.
Anti-Spoofing Default Policy
1. Navigate to Administration | Gateway | Policies
2. Click on the Anti-Spoofing policy in the Policy Editor
3. Open the Default Anti-Spoofing policy
Options
4. Policy Narrative: Default Anti-Spoofing
5. Select Option: Apply Anti-Spoofing (Exclude Mimecast IPs)
This will apply anti-spoofing except if an email is sent from one of Mimecast’s public IPs.
Emails From
6. Address Based On: Both
7. Applies From: Email Domain
8. Specifically: Enter the applicable internal domain you wish to block spoofs from.
Emails To
9. Applies To: Internal Addresses
10. Specifically: Applies to all Internal Recipients
Validity
11.
12.
13.
14.
15.
16.
17.
Enable / Disable: Enable
Set policy as perpetual: Always On
Date Range: All Time
Policy Override: Disabled
Bi Directional: Disabled
Source IP Ranges: No entries
Hostname(s): No entries
Policy Validity
Validity parameters control the application of a Policy to an email. An Active Policy is applied to
emails, and an Expired Policy is ignored by Mimecast. Validity can be controlled manually, and
Policies can also be automatically set to expire on a certain date. By default policies are set to
apply Eternally.
Note: Policy Validity also allows certain options to be applied to policies. For example, bidirectional policy application, policy override, and adding Source IP addresses.
For information on Policy Validity, click here.
Note: Messages rejected by the Anti-Spoofing policy can be seen in Message Center | Rejected and Deferred
Messages.
©2021 Mimecast. All Rights Reserved
|8
Anti-Spoofing Exception Policy
There may be instances where you want legitimate spoofed emails to come in to Mimecast (e.g. using a 3rd party
system to generate an email that you are sending inbound to your colleagues). This would require an Anti-Spoofing
expectation policy. The policy should be scoped as followed:
1. Click on the Anti-Spoofing policy in the Policy Editor
2. Open the Anti-Spoofing IP-Based Exception-Constant Contact policy
Options
3. Policy Narrative: Anti-Spoofing IP-Based Exception-Constant Contact
4. Select Option: Take no action
Emails From
5. Address Based On: Both
6. Applies From: Everyone
7. Specifically: Applies to all Recipients
Emails To
8. Applies To: Everyone
9. Specifically: Applies to all Recipients
Validity
18.
19.
20.
21.
22.
23.
24.
Enable / Disable: Enable
Set policy as perpetual: Always On
Date Range: All Time
Policy Override: Enable
Bi Directional: Disabled
Source IP Ranges: IP addresses of Constant Contact
Hostname(s): No entries
Note: Whenever a policy is scoped to be less specific (e.g., Everyone to Everyone), and you wish for it to be considered
before more specific policies, you must check the Policy Override button as outlined in the configuration above.
To access the policy, navigate to Administration | Gateway | Policies. To configure, see this article.
Blocked Senders
A Blocked Senders policy restricts messages to or from specific email addresses or domains. It can apply to inbound or
outbound messages, although is typically used to block inbound messages.
Default Blocked Senders Policy List
The following default Block Sender policies are created during your Mimecast account creation, and cannot be
changed by administrators:
•
An inbound Blocked Senders policy that references an empty group. You can populate this group by adding
email addresses / domains manually, or by importing a spreadsheet file. See the Importing Users via a
Spreadsheet page for full details.
•
An exception policy with the option set to External to a Relay Group and Take no action. This allows
addresses / domains known to your company and can be relayed via your mail server. For example, a staff
member that has left your organization, but their email address is being forwarded on to a different email
address.
©2021 Mimecast. All Rights Reserved
|9
•
An External-to-External Block Sender policy that prevents senders using your mail server as an open relay.
For example, we only accept messages from addresses belonging to your internal domains. Additional External
to External Blocked Sender policy cannot be created.
Usage Considerations
Consider the following before creating a policy:
•
•
•
Messages from blocked senders are rejected and logged in the Rejections Viewer. See the Message Center:
Rejected and Deferred Messages page for further details.
Blocked Senders policies override any configured Permitted Senders policies.
Blocked Senders policies override addresses allowed by individual users.
Blocked Senders Profile Group
There is a Blocked Senders profile group that is created by default on all accounts. Here, you will see which addresses /
domains are being blocked. Administrators can populate this group with additional email addresses or domains.
By maintaining the addresses in the Blocked Senders profile group, any address changes are automatically applied to
the Blocked Senders policy.
1.
2.
3.
4.
5.
Navigate to Administration | Directories | Profile Groups
Select the Blocked Senders folder
Take note of email addresses and domains listed here
Use the Build drop-down to Add Email Addresses or Domains
Save and Exit
Blocked Senders Default Policy
1. Navigate to Administration | Gateway | Policies
2. Click on the Blocked Senders policy in the Policy Editor
3. Open the Default Blocked Sender policy
Options
4. Policy Narrative: Default Blocked Sender
5. Blocked Sender Policy: Block Sender
Emails From
6. Address Based On: Both
7. Applies From: Address Groups
8. Specifically: Blocked Senders
Emails To
9. Applies To: Everyone
10. Specifically: Applies to all Recipients
Validity
11.
12.
13.
14.
15.
16.
17.
Enable / Disable: Enable
Set policy as perpetual: Always On
Date Range: All Time
Policy Override: Disabled
Bi-Directional: Disabled
Source IP Ranges: No entries
Hostname(s): No entries
To access the policy, navigate to Administration | Gateway | Policies. To configure, see this article.
©2021 Mimecast. All Rights Reserved
| 10
Permitted Senders
Permitted Senders policies ensure successful delivery of inbound messages from trusted sources.
Messages from permitted senders bypass our Spam Scanning, Greylisting and IP Reputation checks, avoiding the
possibility of being rejected or placed in the hold queue. This is useful in situations where the sender's mail server is
listed in an RBL, or for messages flagged by our content checks.
Note: A permitted sender messages are 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.
Usage Considerations
Consider the following before creating a policy:
•
It isn't necessary to create a policy for all trusted senders, only if a sender is having difficulty sending messages
to your end users.
•
End users have a personal permitted sender list. These are managed by them using The Digest Email, or when
logged onto the Mimecast Personal Portal or Mimecast for Outlook.
•
Referencing a user group enables you to minimize the number of Permitted Sender policies you need. The only
time a specific policy is required is if the domain entry contains a wildcard. This requires a separate policy to
permit by IP (everyone to everyone).
•
Blocked Senders Policies always supersede over Permitted Senders policies. This means that messages from a
domain or email address that are added to both a Blocked AND Permitted Senders policy are rejected. These
policies don't override default virus checks.
•
An entry on a user's blocked senders list in Managed Senders, whether it has been added by an administrator
or a user, is always superseded by a Permitted Senders policy if it relates to (P1) envelope addresses. Read
more on this here.
Permitted Senders Profile Group
There is a Permitted Senders profile group that is created by default on all accounts. Here, you will see which
addresses / domains are being permitted. Administrators can populate this group with additional email addresses or
domains.
By maintaining the addresses in the Permitted Senders profile group, any address changes are automatically applied to
the Permitted Senders policy.
1.
2.
3.
4.
5.
Navigate to Administration | Directories | Profile Groups
Select the Permitted Senders folder
Take note of email addresses and domains listed here
Use the Build drop-down to Add Email Addresses or Domains
Save and Exit
Permitted Senders Default Policy
1. Navigate to Administration | Gateway | Policies
2. Click on the Permitted Senders policy in the Policy Editor
3. Open the Default Permitted Sender policy
Options
4. Policy Narrative: Default Permitted Sender
5. Permitted Sender Policy: Permit sender
©2021 Mimecast. All Rights Reserved
| 11
Emails From
6.
7.
8.
9.
Address Based On: Both
Permitted Sender Policy: Permitted Sender
Applies From: Address Groups
Specifically: Permitted Senders
Emails To
10. Applies To: Everyone
11. Specifically: Applies to all Recipients
Validity
12.
13.
14.
15.
16.
17.
18.
Enable / Disable: Enable
Set policy as perpetual: Always On
Date Range: Eternal
Policy Override: Disabled
Bi Directional: Disabled
Source IP Ranges: No entries
Hostname(s): No entries
To access the policy, navigate to Administration | Gateway | Policies. To configure, see this article.
Auto-Allow and Auto-Allow Creation
An Auto Allow is a user-level permit that is generated by your users’ outbound messages. When an email is sent to an
external recipient, it will result in that external address being added as an “auto-allow” within the Managed Senders
area which then allows inbound emails from those external address to bypass Spam Scanning, Greylisting and IP RBL
checks that are performed by those types of policies.
While Auto Allow policies tell Mimecast how we should honor an Auto Allow entry, an Auto Allow Creation policy will
give you control over which of your users will generate Auto-Allow entries from their outbound emails and which will
not.
These messages are still subjected to DNS authentication. Failing SPF, DKIM and DMARC checks
can cause Mimecast to ignore this list entirely.
Usage Considerations
•
•
•
An Auto Allow entry is automatically deleted if no emails are sent to the address for 120 days.
Auto Allow database entries are maintained in an End User's Managed Senders List.
Auto Allow database entries are not generated when:
o Auto-responses are sent (including Out of Office messages).
o Suspected spam related messages are released, and the recipient subsequently replies to the sender.
Auto Allow Default Policy
1. Navigate to Administration | Gateway | Policies | Auto Allow
2. Click on the Auto Allow policy in the Policy Editor
3. Open the Auto Allow policy
Options
4. Policy Narrative: Default Auto Allow
5. Auto Allow Policy: Apply Auto Allow
©2021 Mimecast. All Rights Reserved
| 12
Emails From
6. Address Based On: The Return Address
7. Applies From: Everyone
8. Specifically: Applies to all Recipients
Emails To
9. Applies To: Everyone
10. Specifically: Applies to all Recipients
Validity
11.
12.
13.
14.
15.
16.
17.
Enable / Disable: Enable
Set policy as perpetual: Always On
Date Range: Eternal
Policy Override: Disabled
Bi Directional: Disabled
Source IP Ranges: No entries
Hostname(s): No entries
If you needed to make an exception to exclude certain addresses you can create an Auto Allow Creation policy with the
Select Option set to “Do Not Generate AAL Entries”. You would do this, for example, if you had a marketing group
mailbox sending out mass mailings and you did not want those external email addresses to be logged as Auto Allow
entries.
Auto Allow Creation Policy
1. Navigate to Administration | Gateway | Policies | Auto Allow Creation
Options
2. Open the AAL Creation policy
3. Policy Narrative: AAL Creation policy
4. Select Option: Do Not Generate AAL Entries
Emails From
5. Address Based On: Both
Applies From: Everyone
6. Specifically: Applies to All Senders
Emails To
7. Applies To: Everyone
8. Specifically: Applies to All Recipients
Validity
9.
10.
11.
12.
13.
14.
15.
Enable / Disable: Enable
Set policy as perpetual: Always On
Date Range: Eternal
Policy Override: Disabled
Bi Directional: Disabled
Source IP Ranges: No entries
Hostname(s): No entries
©2021 Mimecast. All Rights Reserved
| 13
To view Auto Allow Entries, navigate to Administration | Gateway | Managed Senders and use
the View menu to filter on these.
To access the policy, navigate to Administration | Gateway | Policies. To configure, see this article.
Managed Senders
Managed Senders are the email addresses that end users have blocked, permitted, or have been added to their autoallow list. Users can block or permit from either the Personal Portal, Mimecast for Outlook or a Digest Email.
An administrator can view, add, modify, or delete these entries. In fact, you may need to edit these entries to
troubleshoot some email delivery flow issues, or to prevent users from accepting email from dubious sources.
Usage Considerations
•
Administrators can manage a user's personal managed senders. Corrections may be necessary when a user has
incorrectly created an entry by:
o Using a digest set to block / permit an external email address.
o Using Mimecast Personal Portal or Mimecast for Outlook to block / permit addresses and / or domain
names.
o Sending a message to an external recipient, which adds the external address to their auto allow list.
•
Blocked Senders Policies always supersede Permitted Senders policies. This means that messages from a
domain or email address that are added to both a Blocked AND Permitted Senders policy are rejected. These
policies do not override default virus checks.
•
An entry on a user's blocked senders list in Managed Senders, whether it has been added by an administrator
or a user, is always superseded by a Permitted Senders policy.
•
Permitted / blocked addresses only apply to the user's primary SMTP address. If you update the user's primary
SMTP address, the personal managed senders list no longer applies, and the address must be re-added.
Managed Senders Page
To view the managed senders of a particular individual:
1. Navigate to Administration | Gateway | Managed Senders
2. Once here you can do any one of the following:
•
•
•
•
•
•
•
Search for an entry by entering the email address / name of the internal user
Block / Permit addresses / domains
Delete addresses / domains
Add / Import Managed Senders
Add Postini Approved and Blocked Senders
View Blocked Senders, Permitted Senders, Auto Allow Entries, Trusted Senders
Export Data
©2021 Mimecast. All Rights Reserved
| 14
The View menu can be used to filter by blocked, permitted, trusted senders and auto allow entries. Each entry displays
the sender / recipient address, along with the policy type. For more detail see Managing an End User’s Managed
Senders List.
DNS Authentication
What is DNS Authentication?
DNS Authentication combines three industry-standard email authentication technologies (DMARC, DKIM and SPF) that
allow domain owners to control who sends on behalf of their domains. It also validates the authenticity of inbound
messages.
•
SPF (Sender Policy Framework) is an open standard for email authentication. It ensures that any messages
sent using a domain come from permitted sources. It does this by checking the domain from the inbound
message's "From Address", to see if the originating IP address is listed in the domain's DNS record. If the IP
address is not listed, a failed result is returned.
•
DKIM (Domain Keys Identified Mail) adds a cryptographic hash or signature as a new header to outbound
messages. This ensures outbound messages haven't been altered after leaving the sending organization's mail
server, by matching the hash or signature to the DNS records. DKIM requires a public DKIM key to be published
in a TXT record in the DNS record for the sender's domain by the domain owner.
•
DMARC (Domain Based Message Authentication, Reporting & Conformance) is an email validation system
designed to detect and prevent email spoofing, that builds protection on top of the SPF and DKIM
mechanisms. It ensures messages are correctly authenticated using the SPF and DKIM email authentication
standards.
DNS Authentication Checks – Inbound and Outbound
DNS Authentication definitions are required for both inbound and outbound checks, prior to configuring DNS
Authentication policies. Consider the following before getting started:
•
Inbound Emails: DNS Authentication is helpful in preventing unwanted and potentially harmful messages from
reaching users. When enabled, checks are performed against all messages regardless of any auto allow or
permitted sender entries being present. This ensures any messages from the sender to these internal users are
not bypassed for spam checks. The following actions can apply, depending on the result of the inbound checks:
•
•
•
•
Reject
Ignore Managed / Permitted Sender entries
Take no action
Outbound Emails: If DKIM signing is required for outbound mail, your organization's DNS record must be
populated with the appropriate public key as part of a DNS Authentication Outbound Signing definition. The
private key of the same keypair must be populated in a DNS Authentication policy, along with the domain and
selector of that record. Once this policy is applied to outbound mail, messages that meet the policy criteria are
DKIM signed.
©2021 Mimecast. All Rights Reserved
| 15
•
Action Severity: If your definition settings conflict with each other, the most restrictive action wins.
SPF Inbound Check Actions
Different actions can apply, depending on the result of the inbound checks:
•
•
•
Take no action: No specific action is applied to the inbound message.
Reject: The inbound message is rejected.
Ignore Managed/Permitted Sender entries: Reputation, greylisting, and spam checks are performed on the
inbound message.
Inbound DNS Authentication Checks
Inbound DNS Authentication checks allow Mimecast to validate the sending systems using pre-configured DNS entries.
We've configured settings across all three DNS services (SPF, DKIM, and DMARC). These take no action if there are no
records found.
By default, we are looking for SPF, which means we are only verifying sending IP addresses in relation to the sending
domain based on their DNS SPF record. You can check DKIM or DMARC as well.
DNS Authentication definitions/policies control the types of email authentication checks performed when we send or
receive a message.
Note: Mail Transfer Agents (MTAs) can verify SPF or DKIM for inbound mail, if the sender publishes DNS entries for
them in their domain records.
SPF Settings
Description
SPF None
SPF Neutral
Recommended Setting
Ignore Managed/Permitted
Sender Entries
(Note: DNS Checks are still
performed)
Ignore Managed/Permitted
Sender Entries
SPF Soft Fail
Ignore Managed/Permitted
Sender Entries
SPF Hard Fail
Reject
SPF PermError
Ignore Managed/Permitted
Sender Entries
©2021 Mimecast. All Rights Reserved
SPF
Notes
The domain owner has not chosen to implement SPF,
meaning that senders using this domain do not need to
authenticate to send on its behalf. Therefore, it is
recommended to perform spam / reputation-based checks
to minimize the level of unwanted mail.
Neutral SPF results are for when the domain owner has not
specified whether a sender using this domain are permitted
to send on their behalf. With this in mind, messages
returning this SPF result should be spam scanned to
minimize the level of unwanted mail being received.
The Soft Fail result is generally considered to be a temporary
setting, whilst SPF is being configured. It does not cause any
restrictions to be applied. All that is added is a header value
containing the check result. However, once all the sending IP
Addresses are added to the relevant SPF DNS record, the
SPF failure action should be changed to Hard Fail. Therefore,
inbound messages with this result should have spam /
reputation-based checks applied rather than rejected.
Any inbound messages that result in an SPF Hard Fail should
be rejected. In these cases, the sender is not sending the
message from an authorized IP address.
PermErrors are similar to TempErrors. They can be caused
by incorrectly formatted SPF records being present and
| 16
SPF TempError
Ignore Managed/Permitted
Sender Entries
require DNS administrator intervention to correct. Messages
with this status should be accepted after having Spam /
Reputation based checks applied.
TempErrors are normally caused by transitory DNS issues
that cause SPF record lookups to fail. Due to the temporary
nature of this problem, messages should be accepted after
having spam / reputation-based checks applied.
The default definition is set to Ignore Managed/Permitted Sender entries which means Reputation, greylisting, and
spam checks are performed on the inbound message.
Default DNS Authentication Inbound Definition
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
Navigate to Administration | Gateway | Policies | DNS Authentication – Inbound
Click on the Default DNS Authentication Definition
Description: Default DNS Authentication Definition
Verify SPF for inbound mail: Enabled
SPF None: Ignore Managed/Permitted Sender Entries
SPF Neutral: Ignore Managed/Permitted Sender Entries
SPF Soft Fail: Ignore Managed/Permitted Sender Entries
SPF Hard Fail: Reject
SPF PermError: Ignore Managed/Permitted Sender Entries
SPF TempError: Ignore Managed/Permitted Sender Entries
Note: In this course, we will not cover the DKIM or DMARC settings. Please refer to the article below for further detail.
Default DNS Authentication Inbound Policy
1)
2)
3)
4)
5)
6)
7)
8)
9)
Navigate to Administration | Gateway | Policies | DNS Authentication Inbound
Policy Narrative: Default Inbound DNS Authentication Policy
Select Option: Default DNS Authentication Definition
Addresses Based on: Both
Applies From: External Addresses
Specifically: Applies to all External Senders
Applies To: Internal Addresses
Specifically: Applies to all Internal Recipients
Save and Exit
For further information on both inbound and outbound checks, read the DNS Authentication Configuration Guide.
Reputation
Reputation policies allow you to manually configure the reputation checks applied to inbound mail. Together with
reputation definitions, they provide granular control over the default reputation spam detection technologies we
apply. When an inbound message is rejected because of a reputation check, the event is logged in the Rejection
Viewer.
Reputation policies check the reputation of the sending IP against Mimecast Global Permitted List of IPs and Global
Block Lists (RBL). We use several block lists and give a score to the IP based on how many of those lists it matches (how
many hits it gets).
©2021 Mimecast. All Rights Reserved
| 17
By default, all block lists and reputation checks are applied to inbound mail. However, by
configuring a reputation definition, you can adjust or exclude some of these checks, or decrease
their sensitivity.
Reputation Definition
1.
2.
3.
4.
Navigate to Administration | Gateway | Policies | Definitions | Reputation Definition
Open the Reputation Definition
Description: Reputation Definition
Mimecast Global Permitted List
[Check inbound email against an IP address based permitted list. If the connecting IP address is present on the
permitted list, it bypasses the spam check.]
5. Global Block Lists
[If selected, all inbound email is checked for spam against 5 IP address-based block lists. This option is used in
conjunction with the "Number of Block List Hits" option]
6. Number of Block List Hits
[Specify a value to set the number of hits required before the sending IP address of a message is rejected.]
Reputation Policy
1. Navigate to Administration | Gateway | Policies | Reputation Policy
2. Open the Reputation Policy
Options
3. Policy Narrative: Reputation Policy
4. Select option: Reputation Definition
Emails From
5. Address Based On: The Return Address
6. Applies From: Everyone
7. Specifically: Applies to All Senders
Emails To
8. Applies To: Internal Addresses
9. Specifically: Applies to all Internal Recipients
Validity
10.
11.
12.
13.
14.
15.
16.
Enable / Disable: Enable
Set policy as perpetual: Always On
Date Range: Eternal
Policy Override: Disabled
Bi Directional: Disabled
Source IP Ranges: No entries
Hostname(s): No entries
17. Save and Exit
To access the policy, navigate to Administration | Gateway | Policies. To configure, see this article.
Greylisting
Greylisting is a default compliance check applied to all inbound messages not previously seen by the Mimecast Servers.
This helps to defend email users from unsolicited spam email.
©2021 Mimecast. All Rights Reserved
| 18
The vast majority of spam is sent from applications designed to "fire-and-forget" emails, where they attempt to send
spam to one or more MX hosts for a domain, but never attempt a retry. By using greylisting policies, any messages sent
from an incorrectly configured MTA aren't accepted.
The Greylisting Process
Greylisting looks at the following pieces of information for the delivery attempt:
•
•
•
IP address of the MTA
Envelope sender address
Envelope recipient address
With this information, we have a unique relationship for that particular SMTP session:
•
•
•
•
If we've never seen this information before, a server busy status (451 Resource is Temporarily Unavailable) is
issued. This is a temporary failure and is maintained for 60 seconds, forcing the sending server to queue and
retry.
A correctly configured MTA always attempts to retry the message's delivery. If the MTA retries after 60
seconds and before the 12-hour upper limit, the message is accepted.
If the message is not retried in this 12-hour period, an entry is logged in the Rejection Viewer as "Sender Failed
to Retry" (12 hours after the initial attempt). See the Message Center: Rejected and Deferred Messages page
for further details.
If the sending MTA attempts again after 12 hours from the initial attempt, the greylisting process restarts.
Usage Considerations
Consider the following before creating a policy:
•
•
•
All email connections that have been subjected to greylisting are logged in the Deferred Messages Queue.
Any sender email address, domain, or IP address added to the Auto Allow or Permitted Senders list isn't
subjected to greylisting.
A greylisting policy is created by default by Mimecast Support during the Implementation process, configured
to apply to all inbound traffic. There may be instances where you have trouble receiving email from legitimate
senders, whose MTA haven't been correctly configured. If the sender's MTA doesn't comply with RFC
standards, but their messages are deemed safe for your organization, you can create a greylisting bypass
policy.
Greylisting Policy
1. Navigate to Administration | Gateway | Policies | Greylisting
2. Open the Greylisting Policy
Options
3. Policy Narrative: Greylisting Policy
4. Select option: Apply Greylisting
Emails From
5. Address Based On: The Return Address
6. Applies From: Everyone
7. Specifically: Applies to All Senders
Emails To
8. Applies To: Internal Addresses
9. Specifically: Applies to all Internal Recipients
©2021 Mimecast. All Rights Reserved
| 19
Validity
10.
11.
12.
13.
14.
15.
16.
Enable / Disable: Enable
Set policy as perpetual: Always On
Date Range: Eternal
Policy Override: Disabled
Bi Directional: Disabled
Source IP Ranges: No entries
Hostname(s): No entries
To access the policy, navigate to Administration | Gateway | Policies. To configure, see this article.
Spam Scanning
Mimecast's multiple scanning engines examine the content of inbound mail by searching for key phrases and
identifiers commonly used by spammers. Based on the findings Mimecast will make a decision based on whether or
not an email is allowed through, held or rejected.
Considerations
Consider the following before configuring a definition or policy:
•
Our spam engine works by giving each email a spam score. A message with a spam score of 28 or higher is
automatically rejected in protocol and logged in the Rejection Viewer. This happens regardless of whether a
spam scanning policy is configured.
•
If an email address, domain name, or IP address is added as a permitted sender, the inbound message still
undergoes spam scanning, but the spam scanning definition action is not applied.
•
If a DNS Authentication policy applies to a message, but the permitted sender fails the DNS checks (e.g. SPF)
the message is still subjected to spam scanning.
MSOC will evaluate spam reports submitted by customers.
Spam Scanning Default Definition
1.
2.
3.
4.
5.
Navigate to Administration | Gateway | Policies | Definitions | Scan Definitions
Click on the appropriate folder (e.g., Default Definitions)
Open your Default Spam Scanning Definition
Description: Default Spam Scanning Definition
Spam Detection Level: Relaxed
[This sets the definition triggering threshold to 7 points and is recommended for users that only receive some
junk email. The other options are Moderate (5 points) and Aggressive (3 points). The default here is dependent
upon your region.]
6. Spam Detection Action: Hold for Review
[Messages triggered as spam are sent to the hold queue.]
7. Enable Graymail Control selected.
8. Greymail Detection Action: Tag Headers as Greymail
[The SMTP header is tagged with "X-Mimecast-Bulk-Signature: yes". With this header enabled, you can define a
rule in your email client to take action on greymail – for example, moving messages to a graymail folder.]
9. Configure Hold Notification Options section as desired.
©2021 Mimecast. All Rights Reserved
| 20
•
•
•
Notify Group - Notifies a pre-defined Group of users when the definition is triggered (e.g., Administrators).
Notify Recipient - Notifies the internal recipient when the definition is triggered.
Notify Overseers - Notifies users that are specified within the Content Overseers Policy.
Users can prevent messages from being classified as greymail by adding senders to their
Managed Senders list using a Mimecast End User Application like Mimecast for Outlook or the
Mimecast Personal Portal.
Spam Scanning Default Policy
1. Navigate to Administration | Gateway | Policies | Spam Scanning
2. Open the Default Spam Scanning policy
Options
3. Policy Narrative: Default Spam Scanning Policy
4. Select Message Scan Definition: Default Spam Scanning Definition
Emails From
5. Address Based On: The Return Address
6. Applies From: Everyone
7. Specifically: Applies to All Senders
Emails To
8. Applies To: Internal Addresses
9. Specifically: Applies to all Internal Recipients
Validity
10.
11.
12.
13.
14.
15.
16.
Enable / Disable: Enable
Set policy as perpetual: Always On
Date Range: Eternal
Policy Override: Disabled
Bi Directional: Disabled
Source IP Ranges: No entries
Hostname(s): No entries
To access the policy, navigate to Administration | Gateway | Policies. To configure, see this article.
Secure Delivery and Receipt
Since some organizations will not accept emails from you that are not sent with forced encryption, you will need to
understand how to set this up. Previously you would have set this up through your Exchange Server or Cloud Service,
but now you need to do this with Mimecast.
To set up forced encryption, you will need to use the Secure Delivery and Receipt policies that come with your
account. Secure Delivery and Receipt policies allow inbound and outbound messages to be received and sent securely
using Transport Layer Security (TLS) technology. TLS is designed to reduce the risk of eavesdropping, interception, and
alteration of mail sent across the internet as it encrypts data between the sending mail server and us.
Usage Considerations
Consider the following before configuring a policy:
•
Secure Delivery and Secure Receipt policies are required to ensure the entire transmission is encrypted
©2021 Mimecast. All Rights Reserved
| 21
•
•
•
TLS technology protects confidentiality and data integrity by encrypting connections between servers
Using TLS Requires an installed third-party certificate at each end of the tunnel
Mimecast supports connections using TLS 1.2, 1.1, and 1.0 for AES-256, MD5, and AnonDH
Secure Delivery and Receipt Defaults
The policies listed below are added to all new accounts to add email addresses or domains that must only be
communicated with using TLS.
•
•
•
A Secure Delivery definition called "Default Secure Delivery - Enforced TLS" is created with the "Enforced
TLS" option. This requires a publicly signed certificate from a root certificate authority. See the Configuring
Secure Delivery Definitions and Policies page for full details.
A Secure Delivery policy from "Everyone" to a group called "Enforced TLS Group". Add email addresses or
domains to this group so that email to them will attempt Enforced TLS.
A Secure Receipt policy from "Everyone" to a group called "Enforced TLS Group". See the Configuring Secure
Receipt Policies page for full details.
These policies are bi-directional so it will apply to both inbound and outbound email.
To access the Secure Delivery and Receipt policies, navigate to Administration | Gateway | Policies.
Lesson 3: Data Leak Prevention Policies
Secure Messaging
Mimecast Content Control and Data Leak Prevention (DLP) is an email security service that works in conjunction with
the other security services of Mimecast to deliver additional regulatory compliance controls and email content security
tools. Optional additions, such as Mimecast Secure Messaging and Mimecast Large File Send can also be added to give
additional security and functionality.
Since certain communications or files are so sensitive that delivering them via email using the open, public internet is
unacceptable, Administrators need a way for employees in their organization to send sensitive information securely.
Mimecast’s proprietary Secure Messaging lets you share sensitive information with people outside your organization
without a message ever leaving the confines of the secure Mimecast network.
How Secure Messaging works
•
When a sender decides to send a message via Secure Messaging, the
message goes through the same checks as standard email. It is then stored
in the Secure Messaging portal within the Mimecast cloud.
•
Mimecast then sends an email with a link to this portal to the message
recipient so they can use the link to view the message. The recipient will
need to login to the Secure Message portal to read the message.
©2021 Mimecast. All Rights Reserved
| 22
Sender Options
The important thing is that the sender can put limitations on what the recipient
can do with the message, depending on the configuration set by their
Administrator.
They may be able to decide not to allow printing, or they might set an expiry date
as to how long the recipient can access the message.
You can send and manage secure messages in
the various Mimecast end user applications:
•
•
•
•
Secure Messaging Portal
Mimecast for Outlook
Mimecast for Mac
Mimecast Mobile
Click here to access documentation on how to use Secure Messaging.
Configuring Secure Messaging
Secure Messages can be triggered by Content Examination, Mimecast for Outlook or the Secure Message Policy itself
as well as other end user applications (e.g., Mimecast for Mobile, Mimecast Personal Portal).
Below is an example of a Secure Messaging configuration to setup Secure Messaging in the Mimecast for Outlook
ribbon:
Secure Messaging Definition
1)
2)
3)
4)
5)
6)
7)
8)
9)
10)
Navigate to Administration | Gateway | Policies | Definitions | Secure Messaging
Create a folder or select and existing one (e.g., Secure Messaging Definition)
Choose New Secure Messaging Definition
Description: Secure Messaging Definition (Print, Reply, Reply All)
Message Permissions: Allow external recipients to print, reply and reply all
Message Expiry: 14 Days (external person will not be able to access the message after it has expired)
Allow Sender to Extend: 30 Days
Send Read Receipt (This setting allows a read receipt email to be sent to the sender of the secure message
when the recipient opens and views the message.)
Customize Internal Notification Banner (Enable this option if you’d like to change the default notification
banner added by Mimecast to internal secure messages.)
Save and Exit
There is NO POLICY required with the MFO configuration. You will need to apply
this definition to all users by way of options you select under an Application Settings
Definition.
©2021 Mimecast. All Rights Reserved
| 23
Configure in Application Settings
1)
2)
3)
4)
Navigate to Administration | Services | Applications | New Application Settings
Description: Secure Messaging Application Setting
Group: All Users
Authentication Profile: Default Application Settings Authentication Profile
Note: All other settings under General configure as you wish. More detail on Applications Settings can be found in
the Configuring Application Settings article.
Gateway Settings
5)
Enable Send as Secure Message
[This enables end users to send emails using Secure Messaging through Mimecast applications]
6)
7)
Secure Messaging Folder: Use Lookup and select the appropriate Secure Messaging Definitions folder
[This will pull in all the definitions under this folder]
Save and Exit
Secure Messaging options in the Mimecast For Outlook plugin are based on the
Secure Messaging folder chosen within Application Settings. All definitions within the
chosen folder will appear as options when applicable users click the Send Securely
button in their email client.
Content Examination
Overview
A Content Examination definition analyzes the content of messages (e.g., message body, subject and header), looking
for patterns and matches you provide. It sets the conditions under which a message is considered safe, and what
action should be taken if it isn’t.
Content Examination Policies can trigger:
•
Actions:
None
Hold
Delete
Bounce
•
Policies Override Options:
Secure Messaging
Secure Delivery
Group Carbon Copy
Content Examination Policies don’t apply based on policy specificity. They can apply to every single
message that falls under the scoping of the policy. In other words, multiple content examination
policies can be applied to a single message.
©2021 Mimecast. All Rights Reserved
| 24
Reference Dictionaries
Content Examination definitions can link to a reference dictionary. These are typically created by the administrator to
contain a list of words, phrases, or regular expressions. The email content is matched against a predefined set of text
entries.
Content reference dictionaries are added from the Insert menu inside a Content Examination Definition.
Each line in the word/phrase match list within the definition must have a scoring number in front of it, which is the
number that will be added to the message's score. Then if the total score matches the activation score, the action will
be taken on the message.
Multiple definitions can point to the same dictionary. We have a set of Mimecast-managed reference dictionaries that
you can use for credit cards, profanity, and healthcare. Custom reference dictionaries can also be created.
ALERT: Please note that while Mimecast supports the use of regular expressions, and may
recommend certain ones to use, we do not directly support the writing of the expressions
themselves and cannot provide troubleshooting based on how they are constructed - we can only
compare the regex you are using vs. message content to see if the content matched or not, if
troubleshooting is needed.
Entities
Entities allow administrators to search for sensitive information in messages and attachments, without the need to
create complicated word lists or regular expressions (regex). Entity groups are a collection of entities aligned by
category (e.g., PII, PHI or Financial). This allows administrators to search based on a subject area, rather than listing
individual entities to achieve the same goal.
How Entities Work
An entity consists of:
•
•
•
A validator: confirms that the structure of the content meets the defined standards for the item you are
looking for. For example, if looking for credit cards, the content must contain four blocks of four numbers, and
a check digit within the specified range.
A regular expression. This is applied to the target content, if the validator check passes. Should the validator
check fail, the content checks stop.
A word list. This is used to limit the number of false positives encountered by matching keywords for the
subject area. For example, credit card keywords are used when using the credit card entities. This helps
determine the context of the match and allows us to exclude a string of numbers that meet the credit card
checks but which isn't a credit card number. There is also an option to not require a keyword by using the
“_nkw” feature that goes after the entity.
Types of Entities
•
•
•
•
Credit Cards
Passport Numbers
Date of Birth
Social Security Number
©2021 Mimecast. All Rights Reserved
| 25
Note:
See the Content Examination Definitions: Using Reference Dictionaries and Content Examination
Definitions: Using Entities pages for more information.
Single Entity Example
The "creditcard" entity finds all credit card numbers, regardless of the credit card type. For example, the following
would match any credit card number found in the specified areas of an email (header, body, attachment), if it is within
proximity to a credit card entity keyword. This would be typed in the Word / Phrase match list of a Content
Examination Definition. See the "Credit Card" section of the Content Examination: Entity Keywords page for further
details.
•
1 detect creditcard
Other examples:
•
•
•
1 detect passport
1 detect DOB
1 detect SSN
Content Examination Definition Examples
•
Content Examination Keyword Trigger: If you want users to have the freedom to decide (on a per message basis)
to send something via Secure Messaging (if they don’t use MFO, MPP or Mimecast for Mac), the Administrator will
have to decide on a keyword, make it part of the configuration and tell their users what that keyword is and have
them use it in the “Subject” line, for example, the word “Secure” in brackets preceding a normal subject – [Secure]
Financial Documents.
•
Content Examination Dictionary Attribute: Your Administrator can set up a Content Examination Definition with a
Mimecast Managed Reference Dictionary or a Custom Reference Dictionary they create, that will either prevent a
message from being sent or send a message using Secure Messaging if the email contains certain text (e.g., credit
card number or profanity).
•
Content Examination Word / Phrase Match: Your Administrator can set up a Content Examination Definition with
a keyword (or words) in the Word / Phrase match list that will either prevent a message from being sent or send a
message using Secure Messaging if the email contains a social security number for example (or any other key
word).
The following configuration will Hold for Review all messages outgoing that contains profanity.
Content Examination Definition –Profanity Hold
1.
2.
3.
4.
5.
6.
7.
8.
9.
Navigate to Administration | Gateway | Policies | Definitions | Content Definitions
Choose the appropriate folder (or create one)
Click the New Content Definition button
Description: Profanity Hold Definition
Definition Type: Independent Content Definition
Activation Score: 1
Fuzzy Hash Setting – Do not use Fuzzy Hash techniques
Click the menu item Insert | Mimecast Managed Reference Dictionary
In the Link Content Reference field, click Lookup and click Select next to Profanity, add a comment Save and
Exit
10. Choose which contents to scan (Subject, Message Body)
©2021 Mimecast. All Rights Reserved
| 26
Inbound and Outbound Settings
Enable Inbound and Outbound Check
Policy Override Options
11. Policy Action: Hold for Review
12. Hold Type: Administrator
Notification Options
13. Notify Group: Administrator (Alerts)
14. Save and Exit
ALERT: If you are creating your first Content Examination policy and you are unsure of
the impact, select None as the Policy Action, and use a Notify Group | Administrator
alerts. Monitor how often you are getting notifications.
Content Examination Policy – Profanity Hold
1. Navigate to Administration | Gateway | Policies | Content Examination
2. Click the New Policy button
Options
3. Policy Narrative: Profanity Hold Policy
4. Select Content Definition: Use the Lookup button and choose Profanity Definition
Emails From
5. Addresses Based On: The Return Address
6. Applies From: Internal Addresses
7. Specifically: Applies to all Internal Recipients
Emails To
8. Applies To: External Addresses
9. Specifically: Applies to all External Recipients
Validity
10.
11.
12.
13.
14.
15.
Enable / Disable: Enable
Set policy as perpetual: Always On
Date Range: Eternal
Policy Override: Disabled
Bi-Directional: Disabled
Source IP Ranges: No entries
16. Save and Exit
In the following configuration, we will configure Content Examination to look for specific keywords, e.g., [Secure], etc.
and Send as a Secure Message based on the matches we find.
For Example: An administrator will notify their employees that if they wish to send something using Secure Messaging,
they can insert a key word – for example: [Secure] into the Subject of an email so it triggers a Secure Message.
Content Examination Definition – Keyword Trigger
©2021 Mimecast. All Rights Reserved
| 27
1.
2.
3.
4.
5.
6.
7.
Navigate to Gateway | Policies | Definitions | Content Examination
Choose the appropriate folder (or create one)
Click the New Content Definition button
Description: Content Inspection-Keyword Trigger
Definition Type: Independent Content Definition
Activation Score: 1
Fuzzy Hash Setting – Do not use Fuzzy Hash techniques
In the Word/Phrase Match List: For each word/phrase, enter a 1 and a space, and then the word or phrase Phrases must be in quotes
1 “[Secure]”
8. Case Sensitive
[Uppercase, Lowercase and Proper Case is matched exactly. If not selected, any case will be matched.]
9. Match Multiple Words
[The definition will search for repetitions of the listed words in the Word/Phrase Match List within the email.]
10. Choose which contents to scan (Subject for this example)
Inbound and Outbound Settings
Policy Override Options
11. Policy Action: None
12. Secure Messaging Override: Click lookup and choose the secure messaging definition that you wish to use.
Notification Options
13. Notify Group: Click Lookup and choose and Admin group - e.g., Administrator Alerts (default)
14. Save and Exit
Content Examination Policy – Keyword Trigger
1. Navigate to Administration | Gateway | Policies | Content Examination
2. Click the New Policy button
Options
3. Policy Narrative: Content Inspection-Keyword
4. Select Content Definition: Content Inspection-Keyword Trigger
Emails From
5. Addresses Based On: The Return Address
6. Applies From: Internal Addresses
7. Specifically: Applies to all Internal Recipients
Emails To
8. Applies To: External Addresses
9. Specifically: Applies to all External Recipients
Validity
10.
11.
12.
13.
Enable / Disable: Enable
Set policy as perpetual: Always On
Date Range: Eternal
Policy Override: Disabled
©2021 Mimecast. All Rights Reserved
| 28
14. Bi Directional: Disabled
15. Source IP Ranges: No entries
16. Save and Exit
Lesson 4: Attachment Policies
Attachment policies are those that are configured to scan attachments.
Suspected Malware
Suspected Malware policies, or Zero Hour Adaptive Risk Assessor (ZHARA), is our proprietary software that provides
early detection and prevention against zero-day malware and spam outbreaks. This provides protection against
previously unknown threats using deep level anomaly detection, and trending against our entire customer base.
What is a Suspected Malware Policy used for?
A Suspected Malware policy is created to ensure messages containing the following file types in a ZIP file, are held in
the hold review queue and marked as suspected malware:
EXE
MSI
COM
PIF
SCR
CPL
•
Encrypted ZIP files are not affected by this policy.
•
This policy works independently of any attachment management policy that you've created.
•
The policy can be bypassed via a Suspected Malware Bypass policy, but this is not recommended. If you do, a
new virus outbreak might go undetected while signatures are being updated.
By default, there is usually only one default Suspected Malware definition configured.
Suspected Malware Default Definition
Note under the Malware Definition Settings section, there are some options that do not need to be enabled if
Attachment Management is part of the Mimecast subscription.
1) Navigate to Administration | Gateway | Policies | Suspected Malware | Default Definition
2) Policy Narrative: Default Suspected Malware Definition
3) Suspected Malware: Enabled by default
[This option is enabled by default, and it is recommended to leave it enabled. The check provides additional
protection against (zero hour) viruses and will look out for specific file types found within archives.]
4) Archive limit: This option is enabled by default if Attachment Management is not part of the Mimecast
subscription and in which case it is recommended to leave it enabled. The check offers protection against
archives that might be malicious.
5) Policy Action: Hold for Review
6) Hold type: Administrator
7) Notify Internal Recipient: check
©2021 Mimecast. All Rights Reserved
| 29
Suspected Malware Default Policy
1)
2)
3)
4)
5)
6)
7)
8)
Navigate to Administration | Gateway | Policies | Spam Scanning
Click the New Policy button
Policy Narrative: Default Suspected Malware
Select Message Scan Definition: Default Suspected Malware Definition
Addresses Based On: The Return Address
Applies From: Everyone
Applies To: Internal Addresses
Save and Exit
Attachment Management
What is Attachment Management?
There are attachment-based policies to filter out possible malware by controlling for attachment size or types of files
that are allowed through.
Similar to Suspected Malware but extremely granular. There are several different policies that correspond with
Attachment Management.
There are 3 similar policies: Attachment Block on Size, Attachment Link on Size and Attachment Hold on size if you
navigate to Administration | Gateway | Policies. These policies are intrinsically matched with our default Attachment
Management policy.
Attachment Block on Size
Maximum attachment size: The sum total of all attachments (e.g., text, PDFs, etc.) in Kilobytes. If the attachments
exceed this number, the message will be blocked for user.
Attachment Link on Size
Sum total of all attachments: Instead of us delivering it to user’s email server, we will give them a link where they can
access attachments and download them.
Some companies have limited storage on their mail servers. This policy will allow attachments
to be directly downloaded from Mimecast to the local machine.
Attachment Hold on Size
Attachment Hold on Size requires administrator intervention to release the held attachment and because of this can
create administrative overhead.
Click here for more detail.
©2021 Mimecast. All Rights Reserved
| 30
Attachment Sets
You should have a default definition and policy configured for dangerous file types using Mimecast Best Practice to
block dangerous file types. This would be an Attachment Management Policy with a Definition called Attachment Sets
which is similar to suspected Malware but here you can granularly decide what you want to do BASED ON THE FILE
EXTENSION (block, allow or link).
Attachment Management Block Dangerous File Types Default Definition
1)
2)
3)
4)
5)
6)
7)
8)
9)
10)
11)
12)
Navigate to Administration | Gateway | Policies | Definitions | Attachment Sets
Click the folder called Dangerous File Types
Open the Default Attachment Management Definition – Block Dangerous File Types Definition
Description: Default Attachment Management Definition – Block Dangerous File Types
Default Block / Allow: Block Specified Content Types (Allow or Link All Others)
Allow Auto Updates: Enabled
Pornographic Image Setting: Do Not Scan Images
Encrypted Archives: Hold
Unreadable Archives: Allow
Encrypted Documents: Allow
Hold type: User
Content Types: Note all of the dangerous file types blocked with this policy
Attachment Management Block Dangerous File Types Default Policy
1)
2)
3)
4)
5)
6)
7)
8)
9)
10)
Navigate to Administration | Gateway | Policies | Attachment Management
Open the Default Attachment Management Policy – Block Dangerous File Types policy
Policy Narrative: Default Attachment Management Policy – Block Dangerous File Types
Addresses Based On: The Return Address
Applies From: Everyone
Specifically: Applies to All Senders
Email To: Everyone
Specifically: Applies to All Senders
In the Validity section, enable Bi-Directional
Save and Exit
Lesson 5: End User Notifications Overview
Digest Sets
Digest Set emails sent to end users allow them to release, block, or permit messages that are deemed to potentially
contain junk / spam content, or specific attachments. These messages are held in a quarantine area called the held
queue. Digest set emails can be configured to:
•
•
•
•
Define the frequency of the emails sent.
Specify the policies that will include messages in the emails.
Specify the actions end users can take on messages that are in the held queue.
Include your company's branding if this is part of your Mimecast subscription.
©2021 Mimecast. All Rights Reserved
| 31
Configuring a Digest Set Definition and Policy
A digest set definition and policy controls the frequency of the digest set
emails sent to end users, and specifies the policies used to include
messages in the digest set email.
The policies that can be used to control the digest set messages are:
•
•
•
Spam Scanning
Attachment Management
Content Examination
Select the boxes in the Digest Definition to apply the Digest Notification to inbound emails when they trigger Spam,
Content or Attachment Management Definitions.
Spam Scanning Digest Example:
If the spam detection action is set for hold for review in the spam scanning definition, the digest
can be utilized to inform the user of held messages, at which point it can be released or
blocked.
Frequency of Notifications
Digest Sets are only sent to internal users. The policy is set from Everyone to
Internal. These are sent specifically for an individual internal user that has
anything on user level hold.
Users can get a digest informing them of all spam caught by Mimecast. These
are set by default up to three times but can be sent hourly over a 24-hour
period. They can review these emails via their Mimecast client and can release
block or permit the sender for future communications.
Default Configuration
A default Digest Sets definition and policy is configured on Mimecast accounts as described in Configuring Digest Set
Emails. You can customize the default Digest Set or create new ones that are specific to your needs.
Digest Set Default Definition
1.
2.
3.
4.
Navigate to Administration | Gateway | Policies | Digest Sets | Definitions
Open the Default Digest Set Definition
Description: Default Digest Set Definition
Notice the options to apply the Digest Notification to inbound emails when they trigger Spam, Content or
Attachment Management Definitions.
5. See the times / days selected for when the Digests will be sent out
6. Make your desired changes.
7. Save and Exit
Digest Sets Default Policy
1. Navigate to Administration | Gateway | Policies | Definitions | Digest Sets
2. Open the Default Digest Set Policy
Options
©2021 Mimecast. All Rights Reserved
| 32
3. Policy Narrative: Default Digest Set Policy
4. Select Digest Set: Default Digest Set Definition
Emails From
5. Applies From: Everyone
6. Specifically: Applies to All Senders
Emails To
7. Applies To: Internal Addresses
8. Specifically: Applies to all Internal Recipients
Validity
9.
10.
11.
12.
13.
14.
15.
Enable / Disable: Enable
Set policy as perpetual: Always On
Date Range: Eternal
Policy Override: Disabled
Bi Directional: Disabled
Source IP Ranges: No entries
Hostname(s): No entries
Be aware, a notification sets definition and policy allows you to customize the digest set email
sent to end users.
Notification Sets
Notification Sets policies allow you to customize the notifications generated by Mimecast for certain email delivery
events. If no policy is configured, the default notifications apply. You can specify which notifications apply to different
end users, as well as user groups.
Some examples include notifying users when a message:
•
•
Has been modified (e.g., stripped attachments)
Did not complete delivery (e.g., bounced or held)
Normally, there is only one policy for the entire company, mostly scoped from everyone to everyone.
Under Notifications, you will see you have a set of notifications. You can see which ones are enabled and support
branding.
Evaluate Default Notifications
1) Navigate to Administration | Gateway | Policies |
Notification Sets | Definitions
2) Click on Default Notification Set
3) Open one (e.g., Hold for Review Notification)
©2021 Mimecast. All Rights Reserved
| 33
Editing a Notification Set
By clicking on a notification, you can modify the sender (by default they come from your postmaster address, but you
can change this to an internal administrator), the subject, as well as the body of the message in plain text or HTML (the
version transmitted is dependent on the recipient MTA), e.g. adding additional text to a digest instructing recipients
on its usage.
When amending the body of notification sets, you must leave some Mimecast components unaltered as the
notification delivery relies on them.
Note: More on Notification Sets can be found in the Configuring Notification Sets Definitions and Policies article here.
©2021 Mimecast. All Rights Reserved
| 34
© 2021 by Mimecast Services Ltd. The information posted in this guide is for use by
Mimecast customers only. Use of the guide is governed by the terms contained in the
user’s agreement with Mimecast. Information in this guide is subject to change
without notice. The Mimecast name and logo are owned by Mimecast Services Ltd
and its affiliates. All other names and marks are the property of their respective
owners.
©2021 Mimecast. All Rights Reserved
| 35