Welcome to the WP community then!
My two paragraphs are somewhat contradictory — shared login vs. individual login with self registration. What they have in common is ensuring “domain.com” is the only allowable email domain. If you are sticking with the shared login, checking the domain upon registration does not apply.
Which ever way you choose, you need to understand hooking filters and actions. (Or find someone who does) This is crucial to customizing anything in WP, so it’s well worth one’s time to understand this. Here’s one resource: https://developer.www.ads-software.com/plugins/hooks/
I suggest reading on through the Filters page, information after that is not currently important. The link is to inside the Plugins Handbook, but hooks apply equally to themes and WP core code.
The code developed to pull this off needs to be protected from updates of both WP and your theme. This can be done with either a Child_Themes or a custom plugin. There’s a brief summary of hooks at that plugin link that could serve as a review after reading the Hooks link above.
To check that a user login contains “domain.com” or whatever, use the “authenticate” filter. You are not actually authenticating, it’s more of a pre-check. So hook with a low priority number (<10) argument using the add_filter() function so your callback runs before the true authentication. Don’t forget to pass any other legitimate users besides those with “domain.com” emails. To pass the login on to true authentication, return null. To fail it, return a new WP_Error object, which will cause any subsequent authentications to pass on the error, preventing login.
You cannot alter logins with “authenticate”, only approve, pass on or fail. To alter login credentials, use the “wp_authenticate” action, where the credentials are passed by reference so you can alter them directly.
To ensure “domain.com” is the email domain for new registrations, use the “user_registration_email” filter. This is the actual user email, not the login name that may also be an email. Again, don’t forget to allow the emails of other legitimate users who may not be on “domain.com”. If you want to manage the actual user login, use the “pre_user_login” filter.
I have the feeling this is all quite overwhelming. It’s not as bad as it sounds. If you have any kind of coding aptitude and are able to grasp how filters work, you are ahead of most users and can probably pull this off. Besides the relatively standard code for hooking filters, the part that actually checks for domain.com is a one liner. The code for hooking a filter could be 4 lines or less, one of which is }. Anyone can do this with a little help if they are motivated enough.
