OutlookRegister: batch Outlook/Hotmail signup with OAuth2 refresh_token capture

What OutlookRegister actually does, and who the fork is for

OutlookRegister automates the creation of Outlook/Hotmail mailboxes and, in the same run, collects an OAuth2 refresh_token for each one. The README describes the pipeline as generate email and password, open the signup page, fill the form, solve a press-and-hold captcha, optionally bind a recovery email, enter the mailbox, run OAuth2 with a cookie-first approach and a fresh browser fallback, then append the token to Results/oauth2.txt. The output line format is email----password----client_id----refresh_token.

The audience is narrow. This is infrastructure for people who need many Microsoft mailboxes plus Graph credentials, not a consumer tool for opening one account. It is a community fork of LainsNL/OutlookRegister, and the fork's stated focus is registration plus OAuth2 hardening: recovery-email binding, multi-stage login challenges, cookie-first OAuth, batching, and interrupt-safe summaries. If you only want to read and send mail, this project is the wrong layer entirely: it produces credentials, it does not manage a mailbox.

The registration and OAuth2 flow, stage by stage

Each worker drives a browser through patchright, a Playwright-compatible automation layer listed in requirements.txt alongside playwright==1.53.0, faker, requests and nest_asyncio. The number of parallel browsers is the concurrent_flows value in config.json; tasks is a global cap on submitted tasks, and success_tasks is a separate global success cap that can be null.

Pacing is controlled by bot_protection_wait, which the README says the code multiplies by 1000 for delays, so the unit in the config file is seconds. Captcha handling is a mode switch, not a solver: captcha_strategy 0 is fully automatic, 1 is semi-automatic where you press the captcha and the rest runs, and 2 hands the browser off after the captcha UI appears with no programmatic OAuth for that task. max_captcha_retries adds press-and-hold rounds, roughly max_captcha_retries + 1 hold attempts.

Proxies are addressed as a pool. With proxy.mode set to single the tool uses single_port; with multiple it walks the inclusive range port_start to port_end, and max_per_proxy caps how many times a port can be selected before it is skipped. The README points at a companion project, Easy Proxies, as required for multi-port mode, meaning OutlookRegister consumes a local proxy pool rather than building one. When all ports are exhausted, or when a batch resets, the usage counters reset.

OAuth2 is where the fork spends most of its effort. The README says it is cookie-first, then a new browser with injected cookies, using storage_state when possible, and that it handles intermediate pages: the personal/work account chooser, protect-account, email proof or the password path, the KMSI "No" prompt, consent, and code capture. The oauth2 block supplies client_id, redirect_url (default http://localhost), Scopes (typically offline_access plus a Graph default), and enable_oauth2. Setting enable_oauth2 to false means a registration success counts without a token, which is a useful split if you only care about mailbox creation.

Installing OutlookRegister and running a first task

The README gives a four-step install: clone, install Python dependencies, install the Chromium build that patchright drives, then copy the config template. The commands below are exactly what the README lists, with the repository URL left as the placeholder it uses.

git clone <this-repo-url>
cd OutlookRegister
pip install -r requirements.txt
patchright install chromium

The Python version badge in the README says Python 3.10+, which is a recommendation rather than a hard check in the documentation. After the install, copy the shipped template. On Windows the README uses copy; on Linux and macOS it uses cp.

cp config.example.json config.json

The README's own minimum instruction is to set the proxy block before anything else, and it warns to leave secrets empty in any copy you publish. That block uses the documented keys proxy.mode, proxy.type, proxy.host, proxy.single_port and proxy.max_per_proxy; the README does not prescribe a default port, so you substitute the one your proxy listens on. Then run the entry point:

python main.py

On success, token lines are appended to Results/oauth2.txt in the email----password----client_id----refresh_token shape, and logs land under log/. Pressing Ctrl+C stops the run: the README states the process writes a summary, then cleans browsers and profiles.

Recovery-email binding and the temp_mail dependency

The temp_mail block is only consulted when Microsoft shows the "Help us protect your account" page and binding is enabled. That is a conditional branch, not a normal step, so a run can complete without ever touching it. When it is enabled, the tool talks to a temp-mail API you deploy yourself: base_url, admin_password, domain, an optional name_prefix gated by enable_prefix, code_timeout for how long to wait for a verification code email, and poll_interval between inbox polls.

The README is explicit that admin_password must not be published. Treat that field as a credential for your own API deployment, not as a shared secret, and keep config.json out of version control; the repository ships config.example.json for that reason. There is no documented fallback if the temp-mail API is unreachable, and no documented retry budget beyond code_timeout and poll_interval, so a slow or broken mail service is a plausible failure point that the README does not address. If you cannot run a compatible temp-mail endpoint, set enabled to false and accept that any account that hits the protect-account page is skipped.

Batching, proxy weight resets, and what the tool cannot fix

batch_success_limit is the most easily misread field. The README says it resets in-process proxy weights and stats after a set number of successes and starts the next batch, while cumulative success and time keep counting. It also states plainly that this does not change a fixed proxy's real exit IP. So the setting rotates selection pressure inside the process; it does not rotate your network identity. If your proxy range is small or the exit IPs are shared, batching will not disguise that.

The same caution applies to the multi-port mode. OutlookRegister consumes a pool that Easy Proxies provides; it does not provision proxies. max_per_proxy only decides when a port is skipped, and counters reset when all ports are exhausted, which means a long run can cycle back onto ports it already used. Nothing in the README describes per-account rate limiting, cooldowns tied to Microsoft responses, or backoff behaviour when signup is refused. For a tool whose whole job is repeated signup against one provider, the absence of documented throttling is the largest gap. The captcha strategy modes exist because the press-and-hold challenge is not reliably solvable in software, and mode 2 exists specifically to hand the browser to a human.

How this differs from a standalone token tool

The closest real alternative in the same ecosystem is the author's own Outlook OAuth GetToken, described in the README as standalone token retrieval: it obtains an OAuth2 refresh_token for an existing Microsoft mailbox without running the registration workflow. The difference is the entry point. OutlookRegister creates the mailbox first and then fetches the token in the same session, reusing cookies from the signup flow and falling back to a new browser with injected storage_state. The standalone tool starts from an account you already have, so it skips form filling, captcha and proxy rotation for registration.

That split matters operationally. If your accounts already exist and only tokens are missing or expired, the registration half of OutlookRegister is wasted work and extra risk. Conversely, if you need both, running two tools means two configuration surfaces and two failure modes. There is also OutlookManage, listed as the account management companion that imports registered accounts and their OAuth2 credentials. Together the three cover create, token, and manage; OutlookRegister on its own covers only the first two.

Maintenance, licensing, and the cost of upgrades

The repository is not archived, and the last push was on 2026-07-27, which is recent enough that the project is not stale, but there are no retrieved releases. That means upgrades happen by pulling main, not by pinning a version. For a tool that drives a live third-party signup flow, that is a real cost: Microsoft can change a page, and the README documents no rollback path, no version compatibility matrix, and no changelog. Your only recovery is a git checkout of an earlier commit.

Dependencies are pinned only partially. requirements.txt pins playwright==1.53.0 but leaves faker, requests, patchright and nest_asyncio unpinned, so a fresh pip install can pull newer versions of four packages than the author ran. The README badge claims MIT, and the repository contains a LICENSE file, but the licence field is reported as NOASSERTION, which means the classifier could not confirm the terms. Read LICENSE yourself before redistributing or bundling this, and note that the project is a fork of LainsNL/OutlookRegister, so upstream terms may also apply. None of this is legal advice; it is a reason to check the file rather than the badge.

Editorial conclusion

Adopt OutlookRegister only if you already run HTTP/SOCKS proxies and hold a Microsoft client_id for the OAuth2 step, and you accept that the output is plain-text credential lines on disk. Do not adopt it if you want a normal Outlook mailbox, if you cannot legally create the accounts, or if you need a supported, documented interface: it is a community fork with no releases, the README does not document rollback or rate limits, and the licence file is present but classified NOASSERTION. Before running anything, read config.example.json, confirm the proxy block (mode, type, host, single_port or port_start/port_end) matches infrastructure you control, and check whether the OAuth2 client_id you intend to use permits the redirect_url you configure.

Frequently asked questions

Official sources

1. daimon3332/OutlookRegister on GitHub
2. Issues
3. README