Why Mass Signups Do Not Work
Stage: the hundredth signup. In control: the platform, and it is patient.
1. The plan breaks on everything except the address
Bulk account creation fails on the parts of you that are not an email address. The address is the piece people spend all their effort on, because it is the piece that is easy to change, and it is close to the least informative thing the receiving platform collects.
By the time a form is submitted, the platform is holding a set of observations that arrived without anyone typing them. The address sits in that set as one field among many, and it is the field with the shortest memory. Everything else in the set outlives it.
This is why the experience of mass signup is so misleading. The addresses work. The accounts appear. The failure comes later and comes to all of them at once.
2. The platform correlates the things you did not fill in
What links two accounts together is rarely the mailbox they were registered from. It is the material that comes along for the ride.
The device and browser produce a bundle of characteristics: screen dimensions, installed fonts, graphics rendering quirks, language and time zone settings, the exact combination of features the browser reports. Individually these are common. Together they narrow a population of millions down considerably, and they do not change when you change your address.
Payment instruments identify a person more firmly than anything else on the form, and any account that reaches a paid step inherits that identity permanently. A phone number does the same job with slightly more effort. Delivery addresses tie physical accounts together the moment two of them ship to the same door.
Timing is the signal people forget. The interval between opening a page and submitting it, the order in which fields are completed, whether values were typed or pasted, and how evenly spaced the registrations are across an hour all describe a process rather than a person. Fifty accounts created with identical rhythm are fifty accounts stamped by the same machine.
3. The device signal outlives the address by a wide margin
A device characteristic survives everything a person normally does to look new. Clearing cookies does not touch it. A private window does not touch it. A different mailbox does not touch it, and neither does a different network provider, because the signal is not carried by the connection.
Compare the effort. Getting a new address takes one click and costs nothing. Genuinely changing what the device looks like means new hardware or tooling built specifically to lie about it, and the tooling has a signature of its own, because a browser that reports an impossible combination of properties is more distinctive than one that reports an ordinary one.
That asymmetry is the whole reason the address is the wrong thing to focus on. It is the cheapest variable to change, which also makes it the weakest one for the platform to rely on and the least useful one for you to vary. The public address you used is not what connects the accounts, which is a separate matter from whether the address is accepted at all, discussed in when the same address comes back.
4. The accounts live for weeks and then close together
The failure has a characteristic shape in time, and the shape is what fools people.
Registrations succeed. Nothing is refused. The accounts sit there working normally for days or weeks, and every one of them looks like a small success. Then a batch of them closes on the same afternoon, because the link between them was established after the fact rather than at the door.
Retrospective analysis is cheaper for the platform than real-time blocking, and it is more accurate. A cluster is easier to see once it has behaviour to look at, and there is no urgency to act on the first account when acting on the ninetieth catches all ninety. The delay is not a gap in the defence. It is the defence.
The practical consequence is that early success carries no information. A month of accounts working is exactly what a month of undetected accounts looks like.
5. Whatever was sitting on the accounts goes with them
The loss is rarely limited to access. Accounts accumulate things, and closures take the things with them.
Balances and stored credit vanish, and recovering them means proving ownership of an account that was closed precisely because ownership looked artificial. Order history disappears along with any warranty registration attached to it. Loyalty points, referral credits, accumulated ranks and unlocked content go the same way. Purchased items that only exist inside the account are gone in the same motion.
There is also the collateral damage nobody plans for: the one account in the cluster that was legitimate. If your ordinary account shares a device signal, a card, or a delivery address with ninety others, it joins the cluster, and it closes with them. The genuine account is not exempt because it was genuine. It is simply part of the group.
6. Bulk handout stops at our end too
This service does not help with the volume side, and that is deliberate rather than a limitation nobody got around to fixing. The guest inbox is one at a time, and asking for a new address deletes the previous one immediately. A free account holds ten inboxes, which is a working number for a person and a useless one for a farm. There is no programmatic access, for reasons set out in why there is no API here.
The point of the design is that the service exists for the person with a form in front of them, funded by advertising, running on a pool of domains that is shared and finite. Bulk consumption spends that pool on one user at the expense of everyone else who needs an address today.
7. There is no route around this on offer here
This page does not describe a workaround, and the omission is not an oversight.
What passes for a workaround in this area is either commercial anti-detection tooling or straightforward violation of a service's terms, and both arrive at the same destination by different roads. The tooling is itself detectable, sold to many customers who all end up sharing its signature, and it never removes the payment instrument or the delivery address from the picture.
Where the underlying need is legitimate, it is almost never solved with more addresses. Sometimes what is wanted is a second profile the service already supports, and sometimes the requirement dissolves once you notice the account was never needed at all.
The handover
Control at this stage belongs entirely to the platform, and it exercises it at a time of its choosing rather than yours. What the platform learns about you from the address alone is a smaller and more commercial story, told in what an address is worth as a lookup key. If the reason multiple accounts were attractive was a form asking for one identifier too many, when the form wants a phone number covers the field that ties accounts together harder than any mailbox does. For the single ordinary signup that started all this, a fresh address from the front page remains the entire toolkit you need.
Read next
Storing an Address Without Breaking It
Keep what the user typed, compare a normalised copy. Trimming, case, lengths, and the unique index that stops two accounts on one address.
The Signup States Nobody Tests
Registration is a state machine. Expired tokens, repeat signups, two open tabs, an address change mid-flow: where the bugs actually live.
The Address as a User ID
An address changes, leaks into URLs and has no stable form. Keep an internal id and make the address an attribute. What breaks otherwise.