Temporary email for verification: 1 address per profile

Nearly every sign-up ends with "we sent you a code", and an agent needs somewhere for that code to arrive. The quick answer is a temporary email service, and it works on the first site you try. It stops working at scale for three reasons, and the replacement is cheaper than it sounds: one domain you own, with every profile holding an address no other profile uses.

What is an email verification code for an agent?

An email verification code is a short number or string a site mails to the address given at sign-up, to prove the address belongs to whoever is signing up. The same step comes in two shapes.

For an agent the address is part of the identity. It is the one detail a site stores on every account, keeps for years and can compare across accounts, so where the code arrives matters as much as whether it arrives.

Why do temporary email services fail?

Temporary email services fail because the address is shared, public or already known to the site, and each of those is visible without any fingerprinting.

• Blocked domains. A site can check the domain against a list of throwaway providers before it sends anything. The open disposable-email-domains list calls itself a list of domains "often used to register dummy users in order to spam or abuse some services", and PyPI uses it "to block registration" with such domains.
• Shared inboxes. A temporary inbox that anyone can open by typing its address hands the code to anyone who does, and that code is a key to the account.
• Linked profiles. Every profile that signs up from the same throwaway provider carries the same domain, and a site that sees many accounts on it sees one operator.

We tried the other route too, reading a throwaway inbox inside the agent's own browser. On 14 August 2026 the list worked and the code often stood in the subject line, but opening a single message failed: the page redrew its list every second, and three references in a row were dead before the next call could use them. That finding is about throwaway inboxes, not about inboxes in general.

How does a catch-all domain give each profile an address?

A catch-all domain gives each profile an address because it accepts mail for any local part, so a new address needs no new account. The address is minted under your domain when the profile is bound, one per profile, and stays with that profile. Directory forms show the scale: in 100 directory submissions, 52 of the 100 forms asked for an account before anything else. Its local part should be random, such as a7f3k9q2@your-domain.com: a local part derived from a visible value, such as the profile's name, would be the very link a separate address is meant to prevent.

Plus addresses are the wrong shortcut. RFC 5233 describes subaddressing as "augmenting the local-part of an address with some 'detail' information", so anna+shop1@ and anna+shop2@ share the part before the plus sign. A site that sees both knows it is one person without reading a single fingerprint.

One link remains and is worth saying out loud: every profile of one mailbox shares its domain. The answer is the same as with proxies, several mailboxes on several domains, spread across the fleet. The email step is one of four walls in signing an agent in, and the only one where the answer is an address rather than a secret.

How does the agent read the code?

The agent reads the code with one tool call that waits up to 60 seconds and returns up to 25 recent messages for its own address, each with its age. The mailbox is read over IMAP by the layer below the browser, so no webmail login opens inside the profile the site is watching. The age lets the agent tell a fresh code from one that was waiting before it started, and a sign-in link is opened in the profile's tab without the agent ever seeing its address. Job portals ask for the address early: in a Workday job application the create-account step came 3 steps in and wanted an email address, a password twice and one consent box.

A catch-all folder is every bound profile's mailbox at once, which is where our first version went wrong.

The reader now asks the mail server for mail to its own address and checks the recipient again when the answer comes back. The inbox page of the documentation shows how a mailbox is set up and bound to a profile, and what the reply says when the filter found nothing. The permission prompts a browser draws during automation are covered in Permission prompts in automation.

Scalebrowser gives each agent its own isolated browser with a persistent identity, on your own machine, so a run stays signed in, handles the captcha and finishes without anyone watching it.

See how Scalebrowser does it

How many profiles can one machine run?

One machine can hold as many profiles as its disk allows, because a stored profile costs nothing while it is not running. What a machine limits is how many browsers are open at the same time, and that depends on its memory; a start the machine cannot carry is refused before the browser opens. How to size that for a fleet is covered in 100 browser profiles.