Spam (confirmed) with Microsoft 365 senders

These types of problems will happen, and a good email filter should provide you with a way to solve them.   In the case of Office365, the required filter rule would be:

If ReverseDNS name ends with ".outlook.com"
AND the ReverseDNS name can be forward confirmed to the IP address
THEN bypass spam-filtering

But you cannot create this type of rule in UTM (or many other products).

The point here is that you need two pieces of information for ANY type of whitelisting rule:   one or more expected identifiers AND evidence that at least one of the identifiers is verifiable and therefore has not been spoofed.   Verification can be based on Source IP, host name, SPF, or DMARC.  Examples:

• A verified SPF and an expected FROM domain can be used to safely override a DMARC false positive.   
• A verified host name and an expected MAILFROM domain can be used to safely override an incorrect SPF policy that causes a false positive. 
• A trusted IP address can be used to safely whitelist a message from a trusted server that does not use a registered email diomain.   

What is consistent for all of these scenarios is that a safe whitelist rule requires at least one verified identifier.

In this particular case, you cannot know all of the Office365 servers, so you need to validate based on host name rather than IP address.   Usually, HELO name is preferred for server verification, because it should reflect the server organization while the ReverseDNS name might indicate the ISP organization.   Office365 is an exception.  Both HELO and ReverseDNS names use the same domain name, but ReverseDNS is the only name that consistently verifies using forward DNS lookups.   

Obviously, Office365 includes a lot of organizations  In this situation, you may prefer to lose some messages for awhile, rather than accepting the exposure created by a bypass rule.  But the choice should be yours.  You should not be constrained by the limitations of an email filter than cannot do two-attribute whitelisting.

There are a lot of products that do not allow two-attribute whitelist rules, so shop carefully when you start looking for your next email filtering product.  It seems obvious that UTM is not going to change much, and sooner or later we will all be looking for replacement technology.   For email, Sophos hopes that we will choose Sophos EMail (in the Cloud).   I don't have a firm answer on whether it provides safe whitelisting based on this approach, but I will not buy a product that cannot do so.

Interesting enough that Central Email does this already with the power of SophosLabs. 

So we are doing this and much more in the Central based approach. Because there is one additional part of Check, you can do: Its the message itself and the content of the message. 

Sophos Labs with the power of machine learning is focusing in such matter a lot because it is quite simple to create a spoofing Email address within outlook and simply spoof people all around the world. And as such, those emails are always "valid" to your checks. If you would start to rely on such checks alone, it could be easily avoidable by using Microsofts own infrastructure to spoof customers. Phishing nowadays has advanced in more detailed ways. 

Central Email uses FROM and envelope-FROM checks already to block and protect the spoofing and enhance this with the classic protection like SPF, DMARC etc. Also terms like Delay Queue are already included plus the known hosts. Central provides a single MX, we can use the information of all customers to enhance the methods of blocking / allowing the email solution. The best part: This is done by SophosLabs and not the customer. As a customer, i do not want to get into this allow/blocking part and think about this kind of stuff. It should simply block the bad stuff and allow the good stuff - right? 

Sophos Labs does some magic to fight against the next generation spoofing and phishing. See: https://ai.sophos.com/projects/phishing-detection/

You can see this in a short demo on the same website: https://ai.sophos.com/demos/sophos-ai-catbert-phishing-detection-model-demo/

Also there is a long defcon presentation about this: https://ai.sophos.com/presentations/def-con-28-ai-village-detecting-hand-crafted-social-engineering-emails-with-a-bleeding-edge-neural-language-model/

This is good.   I have no small frustration that Sophos has offered so many email filtering products but has been so slow to figure this out.    (2 PureMessage embedded products, 3 appliance products, and 1 discarded cloud product before this solution.)  But better late than never.

Feature Question:    

Another feature question:   Does Central Email have the ability to scan the entire Received chain to check for threat actors hidden behiind a forwarding operation?    Example:   John@alumni.example.edu is an auto-forwarding service provided by John's college.  Everthing gets forwarded to john@mydomain.com

John gets both legitimate mail and malicious attacks sent to the alumni address.  When it arrives at mydomain.com, the forwarding process replaces the originator reputation with the university's reputation.    To block the malicious content based on source identity, we need to scan the entire received chain, and block any IP address or host name that is on a configured blacklist.

This is also relevant for DMARC.   Mailing lists alter a message while forwarding it, to add list-specific identification.    How well can the neural network determine that a message has been through a mailing list, and what are my options to allow trusted mailing list traffic to ignore DMARC failures?

This is good.   I have no small frustration that Sophos has offered so many email filtering products but has been so slow to figure this out.    (2 PureMessage embedded products, 3 appliance products, and 1 discarded cloud product before this solution.)  But better late than never.

Feature Question:    

Another feature question:   Does Central Email have the ability to scan the entire Received chain to check for threat actors hidden behiind a forwarding operation?    Example:   John@alumni.example.edu is an auto-forwarding service provided by John's college.  Everthing gets forwarded to john@mydomain.com

John gets both legitimate mail and malicious attacks sent to the alumni address.  When it arrives at mydomain.com, the forwarding process replaces the originator reputation with the university's reputation.    To block the malicious content based on source identity, we need to scan the entire received chain, and block any IP address or host name that is on a configured blacklist.

This is also relevant for DMARC.   Mailing lists alter a message while forwarding it, to add list-specific identification.    How well can the neural network determine that a message has been through a mailing list, and what are my options to allow trusted mailing list traffic to ignore DMARC failures?