We are in the same boat now. Is there anyone that can guide in the right direction ?

See if this works:

I assume you are using the "External Domain" feature of SmarterMail, so that any username not recognized by SM will be forwarded to O365.    I infer that you wish they had the same feature, so that O365 would forward unrecognized names to SmarterMail.    But even if O365 has that feature, you cannot use it.   If unrecognized names are forwarded in both directions, an invalid name will enter a race condition that loops until one of the system (hopefully) detects the loop and discards the message.  Therefore, at least one side of a split domain must know the entire list of all users.   I will assume that O365 will be the system with the complete list because it lacks the external domain feature of SM.

Assume oscar@example.com is on O365, and sam@example.com is on SM.  How do you tell O365 to look for Sam on SmarterMail?    I would think you have this problem regardless of Microsoft tools like Teams.   The following suggestion is based on experience with Exchange 2010, not O365, but here goes:

1) You create a forwarding rule on O365 to send messages for sam@example.com, to sam@sm.example.com.   In Exchange 2010, this involved a contact entry and a transport rule.   In SmarterMail, we call it an alas.   You will have to map the concept to o365, but the net result is to make sam@example.com into a valid address without creating a mailbox for him.  [Repeat this configuratoin for every user on SmarterMail, and keep it updated as users come and go.]

2) The MX record for sm.example.com points to SmarterMail

3a) SmarterMail has a domain for sm.example.com and an alias that forwards locally from sam@sm.example.com to sam@example.com on the same server.  [This configuration is also repeated for every SmarterMail user.] 

3b) Alternatively, you could make sm.example.com a SmarterMail alias domain for example.com, so you do not need to configure any alias entries on the SmarterMail side.  This approach runs the risk that some replies may go out using the sm.example.com domain name instead of the preferred one.   This may require testing, and even if it occurs, it may be an acceptable risk.