I’ve recently encountered an issue where malicious email was imported into the Zendesk platform, while it was successfully quarantined by Microsoft 365. In this post, I go over the options to mitigate this threat.

The problem lies in the fact that forwarding takes place prior to the email being processed by Microsoft 365’s spam and malware filters. This can lead to the forwarding of malicious emails, thus creating a potential security threat at whoever is receiving the email.

The same can be seen when running a message trace (sorted by datetime):

There are several methods to solve this issue, depending on the forwarding destination:

1. Mailbox Inbox Redirect Rule (partial successful)
   • Rule is triggered when email is delivered in the inbox, and processed after spam and malware policies.
   • Not supported by Zendesk as it is detected as “automatic submitted” email, and ends up in the suspended ticket list.
2. Exchange Transport Redirection Rule (fail)
   • Email is not delivered in the mailbox, but is successfully redirected.
   • SCL level can be used to not forward spam.
   • Email still bypasses malware & spam processing.
3. Third-party email security gateway (successful)
   • Requires all email to flow through a different gateway.
   • Requires MX record change.
   • All email is processed before it’s delivered to Exchange, and then forwarded.

In most cases, the Inbox rule would be sufficient. Since this is not supported by Zendesk, only a third-party email security gateway can solve this issue.

It’s unfortunate that Microsoft does not scan email before it’s forwarded and that there are no controls to configure this behavior. Internal forwarding is not an issue since email would still be scanned, but externally is since there is no control over remote policies.

Be careful when forwarding email to external recipients.