Frequently Asked Questions (FAQs)

The email contains an unsubscribe link and/or advertising, marketing, newsletter type content.

The email contains an attachment which is banned by the policy in place for the customer.

For trusted senders, a custom rule can be created to bypass this policy check.

• For more information on policies, please see this article: Policy Template

• For more information on custom rules, please see this article: Creating a Custom Rule

There may be a block rule in place. You can check this as at a glance in the Live Email Tracker. If there is a block rule activated for an inbound email, an “X” will appear beside the “Delete” status. Clicking this will show the rule. If there is no “X”, there is no existing block rule in place.

Alternatively, the policy in place on the customer domain may have certain spam categories set to “Delete” instead of “Quarantine”

If there is a successful SMTP handoff, you will need to perform a message trace internally. This connection log is the response from the receiving server/host. In the example below, the email has passed through our filters successfully and the recipient O365 server responded confirming that the email has been queued for delivery.

If it has been quarantined as spam, infomail, or impersonation, a regular allow rule is recommended.

Guide to create an allow rule: https://docs.emailsecurity.app/help-center/creating-an-allow-rule

If it has been quarantined as phishing or malware, there may be a certain URL(s) detected as malicious or other aspects of the email that are suspicious. A custom rule is recommend if you trust the sender and are confident that it is a false positive.

Guide to create a custom rule: https://docs.emailsecurity.app/help-center/creating-a-custom-rule

We try to ensure our detection is accurate as possible, however, from time to time false negatives do happen. Please email spam@meshsecurity.io with the original spam sample attached as an .eml file.

If you require more detail, or have any questions, an email to support@meshsecurity.io or opening a ticket through the MSP hub is more appropriate.

It is also recommend that you block the sender by either creating a global block rule or a block rule specific to the customer.

Guide to create a block rule: https://docs.emailsecurity.app/help-center/creating-a-block-rule

In typical mail flow, internal traffic should not be routed outbound through the MX records. Internal emails should stay within O365/within the local network. This is best practice in general and is not exclusive to Mesh.

If the email actually originated from a CRM or some other software third party software that uses the customer’s domain name, creating a custom rule with the sending envelope-from and IP address would be the best solution.

Creating same domain allow rules (from example.com to example.com, where example.com is the customer domain) is not advisable as it can allow spoofed emails. Hence the recommendation of using a different envelope-from and/or static IP.

Guide to create a custom rule: https://docs.emailsecurity.app/help-center/creating-a-custom-rule

There are two different scenarios where this may occur:

1 - The email was categorized as Malware, Phishing, or Banned. Regular allow rules or allow rules created by end users will only bypass spam, infomail, and impersonation verdicts. In this scenario a custom rule is required.

Guide to create a custom rule: https://docs.emailsecurity.app/help-center/creating-a-custom-rule

2 - There is no allow rule in place for the sender/domain. You can check this easily in the Live Email Tracker. If there is an allow rule activated for an inbound email, a checkmark will appear beside the “Deliver” status. Clicking this will show the rule. If there is no checkmark, there is no existing allow rule in place that match the criteria of the inbound email.

Guide explaining the different status types: https://docs.emailsecurity.app/help-center/email-statuses#EmailStatuses-Deliverwithacheckmark

You can import rules quickly and easily for your customers using a CSV file.

Guide to import import rules: https://docs.emailsecurity.app/help-center/import-rules-using-a-csv-file

Ensure you are following the correct format and guidelines. Please try some of our troubleshooting tips. If you are still running into issues, please open a ticket with support to investigate further.

Guide to CSV troubleshooting tips: https://docs.emailsecurity.app/help-center/import-rules-using-a-csv-file#ImportRulesUsingaCSVFile-TroubleshootingTips

Typically, third party providers will use a list of domains they own and a range of static IP addresses. To bypass our filtering, you will need to create a custom rule for each domain and/or IP range. This will ensure that we do not quarantine any of the phishing test emails.

Guide to create a custom rule: https://docs.emailsecurity.app/help-center/creating-a-custom-rule

By default, a release request from a quarantine digest is sent to all users with the administrator role on the end customer’s account. If more suitable, this can be changed to an MSP’s email address instead.

Guide to change template for digest requests: https://docs.emailsecurity.app/help-center/managing-quarantine-digest-settings#ManagingQuarantineDigestSettings-ReleaseRequests