Introducing more control over Direct Send in Exchange Online

My feedback is not so much regarding the RejectDirectSend option specifically (which is working fine and makes sense to prevent spoofing), but the accompanying Transport Rule to try and close the gap that DirectSend allows. It's important to note that we have a 3rd party Mail Gateway that our MX records point at, and Connectors for inbound and outbound traffic between EXO and that Mail Gateway. However, the fact that anyone can send messages to our EXO Smarthost is a major hole in our design. RejectDirectSend takes care of anyone using that for spoofing email from our own domains. However, it does not cover people sending in malicious email through the smarthost from external domains...hence the need for the Transport Rule. 

However, there are many use cases that make the Transport Rule difficult to implement. Most of these use cases are related to internal Microsoft Communications. For example:
1) messages from Microsoft systems (alerts, notifications, etc...) apparently use DirectSend so they must be excepted by the rule.
2) Internal forwards between internal users must be excepted.
3) If an external entity sends a calendar invite (through normal MX workflow), and that internal user forwards that calendar invite to another internal user, that has to be excepted by looking for a specific header.
4) If an internal user sends a calendar invite to an external person, and they accept/decline, that response has to be excepted by looking for a specific header, but you can't look for multiple headers in the same transport rule.
5) Finally, we have two tenants and we have outbound connectors that route messages between the tenants through each other's smarthosts. Those must be excepted, or we can add inbound connectors, but there is no way to restrict those connectors by TLS (no control over EXO certificates) or realistically by IP (because MS can change those IP's at any time). 

So all these exceptions in the Transport Rule create a ton of holes for spoofing. I would think there should be a way to carte blanche except system messages from Microsoft without allowing external spoofing of those addresses through DirectSend. Same with allowing forwards between internal users, and dealing with the calendaring issues. On the communication between tenants, why not set up a criterion in the inbound connector that says allow it if it comes from MS EOP IP Addresses, that MS keeps current behind the scenes. 

I'm glad we discovered this DirectSend issue, but now managing it is a real challenge.