How to use bought email accounts
Last updated: July 15, 2026
You bought an email account and now you have an address, a password and possibly three more fields. The fastest way in is the built-in reader on this site: open the account from your orders and the inbox loads, with no setup. To connect it to your own code, use the OAuth2 access token over IMAP or Microsoft Graph, not the password. That last sentence is the whole page in one line, and it is the part almost nobody gets right on the first try.
The reason it matters is that the rules changed. On consumer Microsoft accounts, an address and a password no longer authenticate an IMAP session; Microsoft switched basic authentication off for Outlook, Hotmail and Live accounts in September 2024. The tokens shipped with an account are therefore not a bonus field to ignore. On Microsoft stock they are the mechanism that makes programmatic access work at all, and this page explains what each one does, in what order to use them, and what to check when something returns 401.
What arrives with the account, field by field
Every account here arrives with at least two fields: the email address and its password. Many also carry three more, an OAuth2 access token, a refresh token and a client ID. Those five do different jobs, and confusing them is the most common reason a first attempt fails. The address is the mailbox identity, the string you paste into a sign-up form. The password authenticates the interactive web sign-in at Microsoft, and it is what you change if you intend to keep the account. The access token is a short-lived bearer credential that authorises protocol and API requests on the mailbox's behalf. The refresh token is the durable half of the pair; its only job is minting new access tokens as older ones expire. The client ID names the application the tokens were issued to. Whether a given batch includes the three token fields is stated on the product listing before you spend anything on it.
Why the interactive web login is the worst way in
Do not start by typing the address and password into the Microsoft sign-in page. The interactive web sign-in is where Microsoft runs its risk checks, and a first sign-in from an unfamiliar IP address, browser and country is close to the textbook description of what those checks exist to catch. That is the moment you are asked for a phone number, an alternate address or a second factor, and if you have none of them the session stops there. The account is not necessarily broken when this happens. You have used the one entry point that asks you to prove you are the original owner. Token-based access is a different path and a documented one: the access token was already issued against that mailbox, so presenting it to IMAP or Microsoft Graph authorises the request without opening a fresh interactive sign-on. This is ordinary OAuth2, the same mechanism the mail app on your phone uses. It is also not a guarantee, because if Microsoft invalidates the session the tokens stop working with it.
IMAP: what the credentials actually map to
IMAP is where most people go wrong, because the correct answer changed recently. Microsoft turned off basic authentication for consumer Outlook, Hotmail and Live accounts on September 16, 2024. Before that date you could point any mail client at the mailbox with nothing but an address and a password. You cannot now. The password does not authenticate an IMAP session on these accounts any more. The protocol itself was not retired, though, and this distinction is the useful one: Microsoft's developer documentation states that OAuth2 support for IMAP, POP and SMTP is available for Outlook.com users as well as Microsoft 365 ones. What changed is the authentication step. The client authenticates with the SASL XOAUTH2 mechanism, sending the access token where the password used to go, against outlook.office365.com on port 993. The scope that grants it is https://outlook.office.com/IMAP.AccessAsUser.All. Any client with real OAuth2 support for Outlook, Thunderbird among them, performs this exchange for you. Google has moved Gmail in the same direction.
Microsoft's own pages are not consistent about this, and it is worth knowing why before you conclude your account is faulty. The consumer support article says flatly that modern authentication is not supported if Outlook is configured for POP or IMAP, which reads like IMAP is finished. That line describes the Outlook desktop client's own POP/IMAP configuration, not the Outlook.com service, and the developer documentation for XOAUTH2 says the opposite in plain terms. The practical upshot: IMAP access depends on your client supporting OAuth2, not on the server permitting IMAP. Old software that only knows how to send a password will fail, and nothing on our side changes that. This area has been moving for two years, with deadlines both extended and enforced along the way, so treat any specific claim about it, including the ones on this page, as something to confirm against a small test batch rather than accept on faith. Connect ten accounts the way you plan to connect ten thousand.
Microsoft Graph: the access token and the refresh token
Microsoft Graph is the modern HTTP API for the mailbox, and it is usually the easier of the two paths. Where IMAP needs a client that speaks the protocol, Graph is a plain REST call: send the access token as a bearer token in the Authorization header and read messages back as JSON, from https://graph.microsoft.com/v1.0/me/messages. The mechanic worth internalising is the token lifetime. The access token is short-lived by design. Microsoft expires it on its own schedule, and when it does, every request starts returning 401. That is not the account dying, and it is the single most common false alarm we hear about. The refresh token is the long-lived half: you POST it to the Microsoft identity token endpoint along with the client ID and receive a fresh access token in return. The refresh token is what you store, the access token is what you treat as disposable, and the right trigger to refresh on is a 401 rather than a timer.
What the client ID is and why it is in the bundle
The client ID is the field people delete, because it looks like metadata rather than a credential. It is neither optional nor cosmetic. In OAuth2 a token is not merely issued for an account, it is issued to an application, and the client ID is that application's identifier. When you exchange a refresh token for a new access token, the identity platform needs to know which application is asking, and the answer has to match the application the token was issued to in the first place. Send a refresh token with a different client ID and the request is rejected. That is why the field ships with the account: without it the refresh token is inert, and the moment your access token expires you would have nothing left to present. It also answers a question people ask before buying, namely why an application is involved at all. Every OAuth2 token in existence is issued to a registered application. Keep the three token fields together as one record.
Reading mail with no setup at all, on the site and over the API
You do not have to configure anything to read mail. For Hotmail and Outlook, open the account from your orders and the built-in reader pulls the inbox into the browser, verification codes included, through the account's own credentials. No client, no tokens in your hands, no Microsoft sign-in page. Over HTTP there are two endpoints for the same job. GET https://api.xmailhub.net/api/publicapi/mailreader/:apiKey reads mail for an account, and GET https://api.xmailhub.net/api/publicapi/mailinfo/:apiKey returns the account's mail information. Both take your API key in the path, and that key lives on the API page in your account and can be rotated whenever you want. There is a third endpoint that needs no key at all: GET https://api.xmailhub.net/api/publicapi/stock returns live stock unauthenticated, which is handy for checking availability before you write the buying half of a script. Use the reader when you want an inbox now, and the API when the loop has to run without you in it.
The first hour with a new batch
Do three things before you scale. First, buy small. Fresh accounts are $0.004 and trusted ones are $0.040, so a ten-account test costs a few cents and will tell you more than any page can, this one included. Connect them exactly the way your production code will, because the failure modes are genuinely different across IMAP, Graph and the on-site reader. Second, store the whole record. Address, password, refresh token and client ID belong together in one row; the access token is the only field you can afford to lose, because you can always mint another. Third, change the password on anything you intend to keep, since until you do, the credentials exist wherever they existed before delivery. Be aware that changing the password on a Microsoft account can invalidate existing tokens, so decide which one your workflow actually depends on before you touch it. Nothing here promises an account will pass any given platform's checks, and no honest page can.
Frequently asked questions
Why does it ask for a phone number when I try to log in?
+
Because you are using the interactive web sign-in, which is where Microsoft runs its risk checks. A first sign-in from a new IP address, a new browser and often a new country is exactly the pattern those checks are designed to question, so it asks for a phone number, an alternate address or a second factor to confirm you are the original owner. This does not necessarily mean the account is dead. It means the web login is the wrong entry point for how you are using it. If the account came with OAuth2 tokens, use them against IMAP or Microsoft Graph instead, because token-based access authorises the request without opening a new interactive sign-on. If the account shipped without tokens, the web login is your only path and a challenge there is not something we can remove from our side.
Can I connect over IMAP with just the email and password?
+
Not on Microsoft consumer accounts. Microsoft switched off basic authentication for Outlook, Hotmail and Live accounts on September 16, 2024, so a password no longer authenticates an IMAP session on that stock. This surprises people who did it successfully a couple of years ago. IMAP itself still works: Microsoft's developer documentation confirms OAuth2 over IMAP, POP and SMTP for Outlook.com accounts, but the client has to authenticate with SASL XOAUTH2 and send the access token instead of the password, against outlook.office365.com on port 993. So the question is really whether your client supports OAuth2 for Outlook. Modern ones like Thunderbird do. Old scripts and appliances that only know how to send a password do not, and no setting on our side changes that. Google has moved Gmail the same way, so app-password and password-only access is narrowing generally.
My access token expired. Is the account dead?
+
Almost certainly not, and this is the most common false alarm we see. Access tokens are short-lived on purpose; Microsoft expires them on its own schedule, and once expired, every request returns 401 whether the mailbox is healthy or not. The refresh token exists for exactly this. POST it to the Microsoft identity token endpoint together with the client ID and you get a new access token back, then carry on. Do not throw an account away over a 401. Refresh first, and if the refresh also fails, then you have a real signal. It is also worth building the refresh on the 401 rather than on a timer, because guessing the lifetime is fragile and the error is unambiguous when it arrives.
What do I do with the refresh token?
+
Store it. It is the field that keeps the account usable over time. The access token that ships with the account will expire, and when it does the refresh token is what you exchange for a new one by POSTing it to the Microsoft identity token endpoint with the client ID alongside it. Treat it the way you would treat a password: it is a durable credential, so keep it out of source code, out of screenshots, and in whatever your project uses for secrets. If you are keeping a spreadsheet of accounts, the refresh token and the client ID belong in the row next to the address. People who only save the address, password and access token discover the problem an hour later, when the access token expires and there is nothing left to refresh with.
What is the client ID for, and can I delete it?
+
Do not delete it. In OAuth2, a token is issued to an application as well as for an account, and the client ID is that application's identifier. You need it every time you exchange the refresh token for a new access token, because the identity platform checks that the application asking is the application the token was issued to. Present a refresh token with the wrong client ID and the request is refused. It is not a secret in the way the tokens are, and it is not something you can substitute with your own app registration for an already-issued token. Just keep it stored with the other two fields as one record, and pass it in the refresh request.
How do I read the inbox without setting anything up?
+
Use the built-in reader. Open the account from your orders and the inbox loads in the browser, verification codes included, using the account's own credentials. There is no client to install, no IMAP host to configure and no Microsoft sign-in page to get through. It works for Hotmail and Outlook because both run on the same Microsoft backend. If you would rather do it over HTTP, GET https://api.xmailhub.net/api/publicapi/mailreader/:apiKey reads mail for an account and GET https://api.xmailhub.net/api/publicapi/mailinfo/:apiKey returns its mail information, both with your API key in the path. The reader is the right tool when you want one inbox now. The API is the right tool when the loop has to run unattended.
Should I change the password on an account I bought?
+
If you intend to keep it, yes, and quickly. Until you change it, the credentials exist wherever they existed before delivery, and changing the password is the only step that makes the mailbox solely yours. For a throwaway account you will use once and abandon, it is not worth the thirty seconds. There is one catch worth knowing before you do it: changing the password on a Microsoft account can invalidate tokens issued against it, so if your workflow depends on the refresh token rather than the web login, you may be trading one form of access for another. Decide which you actually need first. If you are keeping the account for months, the password is the thing to secure. If you are reading mail from a script, the tokens are.
Related pages
Need accounts to work with?
Live stock, fresh from $0.004, trusted around $0.040, tokens included on most Microsoft batches.
Open the store →