To a first approximation, what you're asking for is impossible. There's nothing special about Microsoft/Google/etc. accounts; they're just web pages where users POST some credentials (as text wrapped with TLS) and get back a token. You're asking for a tool that can prevent users from sending certain kinds of web requests to certain servers unless the requests contain certain strings. Put like that, hopefully you see how unlikely this is as an actual feature. You're trying to put restrictions on how web browsers are used, at a level where no web browser is designed to support such restrictions.
With that said, while actual total prevention is probably impossible, there are things you can do to make it much less likely to happen by accident or without lots of effort on the user's part. They will probably still be able to get around it if they really want to but it'll be clearly working around a restriction.
Deep packet inspection at the egress proxy
If your company uses a corporate proxy and prevents outbound connections that don't go through the proxy, and if that proxy supports TLS interception (using a private CA certificate installed on all corporate devices), then filtering credentials used is possible (at least for devices connecting to the Internet through the corporate network; you can't do anything about a device connecting through some other network e.g. outside the office or on a guest network at the office or through a personal WiFi hotspot). You would need to do the following:
- Identify the sites you care about (e.g. accounts.google.com, login.live.com, etc.)
- Set up interception for those sites at the proxy (if you already support interception for all sites, set up custom rules for these ones)
- On the relevant sites, examine the request to see if it's an actual login request (as opposed to e.g. the GET request for the page itself). Note that there will sometimes be a multi-step login process which may involve multiple requests; you specifically want the one where the email address is specified.
- Parse the email address out of the request (note that different sites may use different request formats e.g. JSON, XML, etc.)
- If the email address is allowed, forward it to the server as usual. If it is not allows (is a non-company-domain address), have the proxy respond to the request directly with an error.
I believe this approach is what at least some "Cloud Access Security Broker" products do.
Note that this will not necessarily fix situations where somebody has already logged in and still has a live session. Additionally, this kind of deep packet inspection will increase load on your proxy; make sure it can handle it. Finally, make sure you aren't inadvertently logging, or otherwise exposing, user credentials to anybody who isn't authorized to see them (in particular, you probably want to ensure passwords are masked out of any request logging you do).
Remember that any device connected to the Internet but not through the corporate proxy (e.g. through an employee's personal WiFi hotspot, or home Internet in the case of laptops/mobiles) will not be checked.
An alternative that works without a corporate proxy, but is much easier for a user to bypass even from the office, is to create a custom browser extension (or install a user script for an existing browser extension such as TamperMonkey). The extension/script would be active on the same set of identified login pages as above, and could work either at the DOM level (acting as a normal script on the page) or at the request level (similar to how e.g. ad blocking works). The script would check the email address submitted by the user to ensure it uses the company domain, and prevent the user from submitting the login request (and present an error message) if it doesn't.
Extensions and scripts are much easier to remove or disable - typically this doesn't require admin privileges, and it's very hard to prevent tampering with the extension configuration or scripts - but it may prevent non-technical users from bypassing the restriction, or at least make it obvious that they're bypassing something set up by IT and therefore violating company policy.