Policies - Frequently Asked Questions

This guide provides administrators with common troubleshooting solutions for various issues relating to policies. 
Common issues include:

• Basic configuration recommendations and best practice settings.
• General investigation into false positives and negatives.
• Confirmed false positives and false negatives.
• Errors returned by security policies (TTP scan errors, etc.).

This page should be read in conjunction with the Policy Specificity page.

General Policy Issues

Q:	How can I resolve general policy configuration problems?
A:	Any time a policy doesn't apply to a message as expected, check the following: Ensure the policy is scoped properly (including envelope/header, etc.). Ensure that default policies have not had IPs added to them. Confirm that the policy's definition is set to the expected values. If a policy should apply to all inbound mail, ensure it's set as "From Everyone, To Internal" (except for Impersonation Protect, which should be "External to Internal"). Consider if there are other policies that are taking precedence.
Q:	Our inbound mail is not being routed as expected. What could be the problem?
A:	First, confirm that your server's firewall is allowing connections to Mimecast. A test delivery route option can be used in your Delivery Routing Definitions. The policies should also be scoped correctly (i.e., Everyone to Internal for all inbound mail) and the delivery recalculated if any changes were made to policies. Details can be gathered from the Monitoring | Delivery menu item in the Administration Console.
Q:	Why aren't we receiving notifications for all policies?
A:	Ensure the specific notification type is included and enabled in the applicable Notification Set. See the Configuring Notification Sets Definitions and Policies page for full details.
Q:	What can we do about a user account that resulted in a virus false positive report?
A:	If possible, have the sender place the message in a password-protected zip and escalate the incident to Mimecast Support.
Q;	We received an error message that mentions RBL. How can this be checked?
A:	If the rejection information states which RBL, check that RBL in real-time. You can use an online tool, such as MX Toolbox.
Q:	I've applied a policy to a group of users, but it also seems to be applied to users that are in a sub-group attached to that group. Can this be changed?
A:	Not as such. Policies applied to a group automatically apply to all sub-groups within the group's hierarchy. To get around this issue, move the sub-group to the same level (or higher) as the group in the hierarchy.

Spam

Q:	Why are we receiving spam false negatives?
A:	Check the Receipt Event information to ensure it didn't bypass spam scanning, looking for any mention of Permit or Allow. For example: Received via Permitted Sender indicates a Permitted Senders policy was applied. Manual Permitted Sender and Auto-Allow indicate that a Managed Senders entry was applied. See the Receipt Events section of the Email Receipt and Delivery Views page for further information. Additionally, you can use the Report As buttons in the Mimecast Administration Console to escalate the information to Mimecast Support.
Q:	How can we resolve spam false positives?
A:	Escalate the issue to Mimecast Support, providing an original copy of the message if possible. You may need to place it in a password-protected zip to ensure it's safely received. See the Misreported Spam Messages page for further information.
Q:	How can we prevent certain users from sending spam outbound?
A:	Ensure the user does not have SMTP submission enabled, and place a block on the sender until internally resolved.

Anti-Spoofing

Q:	Why isn't our Anti-Spoofing policy working correctly?
A:	We recommend checking the following: For IP-based bypass policies (Everyone to Everyone, Take No Action) ensure that the Policy Override option is enabled. View the Configuring Anti-Spoofing SPF Based Bypass Policies  page for details. For SPF-based bypass policies, ensure the source IP is listed in the SPF record of the specified domain.

Attachment Management

Q:

Our Attachment Management policy is not being considered. What could be the issue?

A:

We recommend checking the following: Confirm the policy is set to the expected value (i.e., allow / deny). See the Configuring Attachment Management Definitions page for further details. Ensure there are no files within a file, specifically .ZIP files as the entire file is held if a single disallowed file is found. Ensure the file extension was not changed. We detect files based on data, not necessarily the extension. See Policies - Attachment Set - Frequently Asked Questions.

Content Examination

Q:	Why is our Content Examination policy failing to detect certain content?
A:	Ensure the correct message portion is being scanned (i.e., subject, body, attachments, and headers). See the Configuring a Content Examination Definition page for further details.
Q:	Can I receive support for custom Regular Expression configurations?
A:	Mimecast does not support custom Regex, and cases may only be escalated if you can prove the Regex triggered inappropriately. We recommend testing against regex101.com, or another testing platform. Alternatively, enable a policy set to take No Action but to Notify when it is triggered. Mimecast uses JavaScript for regular expressions.
Q:	Can more than one Content Examination policy be applied to the same message?
A:	Yes. Content Examination policies (like Targeted Threat Protection policies) don't stop processing a message once a policy is triggered. Take the example where there's one policy looking to hold messages sent to external addresses with the text CC#, and another looking to send external messages securely if "DRUG CODE" is found. Should a message contain both CC# and "DRUG CODE", the message is held by the first policy, but released and send via Secure Messaging by the second policy.

Digest Sets

Q:

How can I ensure Digest Sets notifications are correctly received?

A:

We recommend checking the following: Verify the schedule in the Configuring Digest Set Emails  page, keeping time zones in mind. The Administration Console time is based on your Mimecast's account's Data Center location. Check that the user has had mail held since the last digest they received. Search the archive for a notification set subject (e.g. "messages on hold for") and see if there is one for the applicable user.

Greylisting

Q:	We have an active Greylisting Bypass policy, but we're still not receiving certain legitimate messages. How can this be resolved?
A:	Ensure the address / domain used in the bypass matches the Envelope From address of the message. Greylisting is only based on the envelope address. As the message has not yet been transmitted at the time of the check, Mimecast does not know the Header From address.

DNS Authentication

Q:	How can we ensure DNS Authentication policies are configured correctly?
A:	We recommend checking the following: Confirm DNS records are properly configured. Compare the source IP to the sending domain's SPF record. Confirm that DKIM is not being signed at a hop previous to Mimecast (for outbound mail). Check delivery headers of the message (if delivered or held) to see which DNS checks passed or failed.

Permitted / Blocked Senders

Q:	Why are our Permitted / Blocked Senders policies resulting in errors?
A:	We recommend checking the following: Ensure default policies have not had IPs added to them. If the word Manual is mentioned in the rejection, the user’s Managed Senders may be conflicting with a Permit/Block policy. Refer to the Usage Considerations sections of the Permitted Senders and Blocked Senders policy pages for further considerations.

Secure Delivery

Q:	How can I ensure our outbound mail is secured via a Secure Delivery policy?
A:	Use a tool like CheckTLS.com to determine whether the recipient server is advertising STARTTLS, and whether they have a valid certificate. This confirms an insecure connection can be upgraded to a secure connection using SSL or TLS.

See Also...

• Policies - Policy Basics
• Policy articles