The browser and a mail client reach Hotmail through completely different doors, so an address working in one while failing in the other points at the client side door, the settings and authentication, rather than the address itself. The causes:

The server settings, most common on manual setup: Hotmail, Outlook.com and Live addresses all use the same modern servers, incoming imap-mail.outlook.com port 993 SSL, outgoing smtp-mail.outlook.com port 587 STARTTLS, and a client configured with old or guessed servers fails to recognize the account. Let autodiscovery handle it by choosing the Outlook.com or Exchange account type where the client offers it rather than manual IMAP, which resolves the servers correctly.

The authentication method, the modern wrinkle: Microsoft requires OAuth2 for these accounts now, the sign in through Microsoft's own page, and an older client offering only password authentication gets rejected in ways that can surface as not recognized. A client too old to speak OAuth2 to Microsoft either needs updating or, where the account allows it, an app password generated in the Microsoft account security page used in place of the normal password.

The address form itself, occasionally: very old Hotmail addresses on regional domains, hotmail.co.uk and the like, are valid but sometimes confuse clients expecting hotmail.com, worth confirming the exact domain is entered. And an address recently migrated or renamed carries its aliases, with the client needing the primary address rather than an alias for authentication.

The reliable path through all of it: use the client's built in Outlook.com or Microsoft account option rather than manual setup, sign in through the Microsoft page it presents and let OAuth2 and autodiscovery do the recognition. Manual IMAP with an app password is the fallback for clients that cannot do the modern sign in, and updating the client is the real fix when it is simply too old to speak Microsoft's current authentication.