One way to think of this is that the app has no way of knowing whether
mail.company.com are all run by the same person (or the same department, or the same company). There are many cases on the Internet where they’re not, and so the app has to assume that they’re totally unrelated. In that case, if the app is configured to connect to
mail.company.com and it receives a certificate that’s only valid for
bar.company.com, the app has to assume that this certificate is totally invalid. It can’t make the inference or guess that this might be run by the same person, because that would allow a number of kinds of attacks.
As the other folks in this thread have said, the app will simply not accept connecting to a service if it was configured to refer to that service by a name that is not listed in the service’s certificate. It simply has no way of knowing by itself whether or not two related-but-not-identical names are supposed to refer to the same computer. To get rid of the error, you have to make sure that the service is only ever referred to by names that are listed in a certificate that the server possesses, and that’s issued by a certificate authority that the clients trust.
From the point of view of the Outlook developers (for example), this is totally intentional, to stop a café owner from creating a machine simply called “mail” on their wifi network and then stealing your users’ passwords when their Outlook application auto-connects to it! (or to prevent people who connect their laptop to someone else’s corporate network from attempting to automatically log in to the equivalent services on that network, and thereby telling the other corporation their passwords)