I will assume that bringing up an outgoing gateway running an old version of SmarterMail will not solve the problem.
It baffles me why an organization would want to send its high-volume mailings through their low-volume mail server, or why you permit this load on your systems. Bu the customer is always right, and your customers cannot wait while you beg SmaterTools to make this a development priority.
You need a product that you can customize. My experience is with Declude from
MailsBestFriend.com, which I have been able to customize heavily.
Here is how it could be solved today:
1) Create a SmarterMail outbound gateway to handle all outgoing mail, and integrate it with Declude. SM drops new messages into \spool\proc for Declude to evaluate, and Declude drops messages back into \spool when it is done. SM creates a .HDR file with summary information about the message, and a .EML file with the actual message. Messages which require no redirection will be returned to the /Spool folder of this gateway.
2) Create additional SmarterMail outbound gateways for each of the ESP destinations: sendgrid.net, customcontact.com, etc. These gateways will also be configured with Declude, but will not actually use it. Their entire function will be to wait for messages to magically appear in their /spool folder. These gateways will also be configured to ignore MX and instead forward messages to the gateway for the appropriate email service provider.
3) Write a Declude filter to check for the special MailFrom addresses. When a match is found, move the message into the /spool folder of the appropriate outbound gateway. For everything else, just exit the Declude processing loop so the message will be returned to the original gateway for delivery via MX lookup. I think this can be done with Declude's built-in capabilities using the MAILFROM variable and the COPYFILE operation. But I have not used OPYFILE, so it will need some tesing. If you run into problems,a windows script file can definitely get it done.