Policies: Frequently Asked Questions

Document created by user.oxriBaJeN4 Employee on Nov 27, 2018Last modified by user.oxriBaJeN4 Employee on Jul 18, 2019
Version 12Show Document
  • View in full screen mode

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?

If the rejection information states which RBL, check that RBL in real-time. You can use an online tool, such as MX Toolbox.




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” indicates 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 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 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?

Ensure the user does not have SMTP submission enabled, and place a block on the sender until internally resolved.




Q:Why isn't our Anti-Spoofing policy working correctly?

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 Anti-Spoofing 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:


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 Content Examination Definitions and Policies page for further details.
Q:Can I receive support for custom Regular Expression configurations?

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.


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?

We recommend checking the following:

  • Verify the schedule in the Digest Sets Definition, 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.




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 source IP to 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?

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?

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...