If the client wants to use company B for mailhost service, then the MX resource records published in the public DNS database must exist, to show the world where company B's SMTP Relay servers actually are. It's that simple. If they don't, then the world looks for A/AAAA resource records, and finds you, company A, which is not what the customer wants.
Once you are in that situation and the MX resource record set exists, there's nothing that you, company A providing the content HTTP service, need do that is special. Your HTTP servers, and the MTA that they talk to, are by default in the same situation as the rest of Internet. They do what everyone else does: They find out that the mail is to be delivered to a remote domain, look up the remote domain's MX resource record set, and push the mail off to the SMTP Relay servers listed therein.
This is really only a problem where you've actually done something to explicitly change this default on your machines — such as, for example, explicitly telling your MTS that the domain in question is a local one. Most MTSes work on the principle that anything not explicitly stated to be local is remote, so you have to explicitly do something to tell an MTS not to treat a domain as remote. (For qmail a domain is remote if it is not explicitly listed in locals or virtualdomains. For Postfix, a domain is remote if it is not explicitly listed as mydestination, a virtual alias, or a virtual mailbox. Other softwares have different mechanisms but the same dichotomy.)
Maybe this is your standard procedure for customers — you tell your MTS that the domain is local at the same time that you tell your content HTTP servers that the domain is associated with a particular "document root" (or whatever) and you tell your content DNS servers that the domain is in their database. If so, the simple answer is don't do that, then. Simply do not do the part that involves modifying your MTS to treat the domain as a locally hosted one.
