outlook-auto-register: pure-protocol Outlook signup with a PerimeterX solver and a web console

What outlook-auto-register is for

Most Outlook signup scripts stop at sending the right HTTP requests. The README's own framing is that the engineering gap sits elsewhere: passing PerimeterX, rotating proxies, binding a recovery address during the proofs step, reading mail from the resulting token, managing batches, and checking whether accounts still work. outlook-auto-register is built as a pipeline that covers those stages rather than a request snippet.

The audience is narrow. It assumes Python 3.11 or newer, a residential proxy whose country matches the exit, and a captcha.run API key (CapSolver and EzCaptcha are listed as compatible). The README carries an explicit notice that the project is for study and research and that users must assess compliance with the Microsoft terms of service themselves. If you want a mail client or a supported Microsoft integration, this is the wrong repository.

The signup chain from OAuth PKCE to proofs

The README lays out the sequence in a single diagram. It starts at the OAuth login page with PKCE, moves to signup.live.com/signup where the page's ServerData is parsed, then calls CheckAvailableSigninName. From there it initializes risk with an empty continuationToken, preloads humanSensorUrl and the PX collector, and runs the first risk/verify with px metadata plus msaRiskVerifySignature.

If the response carries riskChallengeRequired, the tool falls back to captcha.run in press or silent mode and issues a second risk/verify with the challengeSolution and fresh px metadata. CreateAccount follows, then an slt login through oauth20_authorize.srf, then the proofs step where an external recovery mailbox or a Cloudflare catch-all address is bound. Getting the mail OAuth refresh_token is optional and can be skipped.

The code is split accordingly: register.py orchestrates, bootstrap.py handles OAuth and PX preloading, api.py holds the API calls and msaRiskVerifySignature, risk.py the two-step verify, captcha.py the captcha layer, and px_solver/ the solver itself. That layout matters if you plan to patch one stage, because the two risk/verify calls are separated from the captcha provider.

Installing it and running a first registration

The README's quick start clones the repository, creates a virtual environment and installs the pinned requirements, which are requests, python-dotenv, fastapi and uvicorn.

git clone https://github.com/lxf746/outlook-auto-register.git
cd outlook-auto-register

python3 -m venv .venv && source .venv/bin/activate
pip install -r requirements.txt

cp .env.example .env

After copying .env.example to .env you edit the recovery pool and Cloudflare domain settings. The README recommends writing the captcha key through the web console instead of .env, because the console reads it from SQLite first and treats .env as a fallback.

The recommended entry point is the FastAPI app, started with uvicorn on port 8890.

.venv/bin/uvicorn webapp.server:app --host 0.0.0.0 --port 8890

Open http://127.0.0.1:8890, add a residential proxy on the proxy pool page, then on the batch page fill in the captcha.run key, choose an output format and clear the dry-run checkbox before starting. The README states that dry-run is on by default on first use, so nothing is registered until you clear it. Results appear in the account pool page, where combos can be exported.

A single CLI run looks like this, with the six-segment graph_recovery mode as the recommended output.

OUTLOOK_MAIL_TOKEN_MODE=login_exe python main.py \
  --proxy 'gate.example.com:1000:user:pass-US-{sid}' \
  --country US -v

The proxy string takes a host:port:user:pass form with a {sid} placeholder for rotating gateways. Batch runs add --count and --concurrency, and the README shows REG_PROXY_RETRIES=6 alongside a conservative concurrency of 2. Two flags change the output: --skip-login stops before the OAuth step and produces no refresh_token, and --no-mail-token registers without exchanging for a mail token.

Proxy pool, output formats and where the data lands

Proxies live in SQLite at accounts/outlook.db rather than in an environment variable. The README describes pre-checks, success-rate statistics, sticky binding and rotation policy on top of that store, and notes that HTTP_PROXY_POOL is deprecated in favour of the console's proxy pool page. The CLI still reads HTTP_PROXY as a fallback, so a single-proxy run does not require the database.

Output format is a real decision, not a cosmetic one. The graph mode emits four segments: email, password, client_id and refresh_token. graph_recovery and login_exe emit six, appending the recovery email and its password. dual also emits six but the extra pair is a login_client_id and login_refresh_token, so the account carries two tokens for different purposes. The README's table maps the console dropdown labels (Graph four-segment, Graph six-segment recommended, IMAP six-segment) onto those modes.

Mail token mode is a separate axis. graph reads mail through the Graph API immediately after registration, outlook_rest uses the Outlook REST API, login_exe and recovery use the Thunderbird scope covering IMAP, POP, SMTP, EWS and Mail.Read/Send, and dual issues both. The README describes login_exe as the seller-style configuration, which tells you which mode the surrounding ecosystem tends to expect.

Proof binding is the part that decides whether an account is usable

The README is blunt here: skipping proofs is associated with a high ban rate, and OUTLOOK_SKIP_PROOFS=1 is described as debugging-only. The default is 0. Two backends exist for it. The imap backend reads a pool file where each line is email followed by four hyphens and a password, and logs into a third-party IMAP host to read the Microsoft one-time code. The cf_domain backend instead generates random addresses under a domain whose catch-all is already enabled in Cloudflare Email Routing, then pulls the code through a self-hosted Cloudflare Worker mail API.

The .env.example exposes the knobs for both. For cf_domain, OUTLOOK_CF_WORKER_API_URL must be the Worker API root (the apimail subdomain), not the mail or admin web address, and OUTLOOK_CF_WORKER_ADMIN_TOKEN is marked sensitive. OUTLOOK_CF_USE_NEW_ADDRESS defaults to 0, meaning random catch-all addresses are used without registering them through the Worker's /admin/new_address endpoint. OUTLOOK_CF_MAIL_LIMIT defaults to 50 for alias-specific addresses and OUTLOOK_CF_FORWARD_LIMIT to 100 for a shared forward mailbox, which the comments justify by saying a busier shared inbox needs a deeper pull to reach the newest message. OUTLOOK_CF_RECOVERY_PLACEHOLDER defaults to cf_domain because a catch-all recovery address has no password to put in the sixth segment.

Limitations and the cases where this is the wrong tool

The dependency list is short, but the operational dependencies are not. A residential proxy is listed as required, with the proxy's country matching the exit, and a captcha.run key is recommended. Neither is bundled. The PerimeterX solver is a moving target by nature, and the README does not document a fallback for the case where the solver stops working and captcha.run also fails; the two risk/verify calls simply do not complete.

There is no rollback story. The README does not document what happens to a partially created account when proofs fail after CreateAccount, and there is no release history in the repository to fall back to, since no releases were retrieved. The licence file is present but reports as NOASSERTION, so the terms are not machine-identifiable from the repository metadata alone; read LICENSE directly before depending on it.

The tool is also the wrong choice outside its niche. If you need to read mail from an existing account, a normal IMAP or Graph client is simpler and does not require a proxy pool. If you need a supported way to provision Microsoft accounts in an organisation, account creation through this pipeline is not that, and the README's own notice says users bear the consequences of what they do with it.

How it differs from browser-automation signup scripts

The obvious alternative is a browser automation script driving a real Chromium session through the signup pages. The difference is not speed, it is what you have to keep alive. A browser approach inherits the page's own JavaScript, so the risk and fingerprint signals are produced by the browser, and the maintenance burden shifts to selector changes and headless detection. outlook-auto-register instead implements the Fluent Web API calls directly, including a pure-protocol PerimeterX solver, and treats captcha.run as a fallback when the server demands a challenge.

That choice buys headless operation on a machine with no display and no browser binary, which is why the requirements file contains only requests, python-dotenv, fastapi and uvicorn. The cost is that every server-side change to the risk flow has to be reimplemented in Python, and the two-step verify with msaRiskVerifySignature is the part most exposed to that. A browser script would absorb some of those changes for free. A second alternative is a plain HTTP script that posts the signup form and skips proofs; the README's comparison table positions that as the common case and argues the skipped proofs are what raise the ban rate. That is the trade this project is asking you to accept.

Editorial conclusion

Adopt it if you already run residential proxies, hold a captcha.run or compatible key, and can supply a recovery mailbox pool or a Cloudflare catch-all domain, because the six-segment output depends on proof binding. Do not adopt it if you need a supported Microsoft integration or cannot accept that account creation may violate the Microsoft terms of service. Verify two things before trusting a batch: that OUTLOOK_RECOVERY_BACKEND resolves to a backend you have actually tested, and that the default dry-run flag in the batch page is off only when you mean it.

Frequently asked questions

Official sources

1. Issues
2. lxf746/outlook-auto-register on GitHub
3. README