Free trial abuse across multiple accounts got through four separate fixes to our signup form in nine weeks, and every one of those fixes worked. One operation was farming a free promotional allowance, several accounts at a time. What finally identified it wasn't anything on the form but what the accounts did after they were in.

On 1 November 2026 we noticed five new accounts that had been created a few minutes apart. All five had claimed our seasonal promotion, which gives 100,000 free checks a month. None of them had a website. The names were nonsense. The email addresses were at a free mail provider and looked dot-scrambled, the way a trick we'd closed in September used to look. The traffic told the rest: one shared list of addresses, fed through the five accounts a slice at a time, so that five free allowances added up to one large one.

Fine. People do this. What stung was that we'd been here before, more than once, and each time we'd closed the door they came in through. So before we get to what we built this time, the earlier rounds. The shape only shows up when you lay them end to end.

Temporary mailboxes

The first accounts, on 29 August 2026, were all on throwaway mail domains, the kind where you get a mailbox for ten minutes and never think about it again. The cheapest kind of fake identity has the cheapest fix, so we built one. The list is ours to run: several sources merged into roughly 125,000 domains, picked on licensing grounds, because some of the biggest and most tempting lists can't be used in a commercial product at all. On top of that sits an allowlist, and it isn't optional. The raw feeds contain genuine mail providers, and unfiltered they would refuse real customers. Deciding what comes back out is the part that takes judgement. The form checks every signup against it. The refusal says why rather than failing silently, and someone here gets told about it.

Three days later, three accounts got in on throwaway domains anyway. The check hadn't failed. It was consulting a list that refreshed weekly, and their domains were newer than our copy. A fortnight on, the same thing again. So on 11 September we moved the refresh from weekly to daily. Early on we'd also had to fix the refresher itself, which rebuilt the list from scratch each run and would have quietly thrown away our own additions; a check that undoes itself is worse than no check. Before the check could change their behaviour, we had to fix the check.

Then it bit, and that morning is the whole story in miniature. On the morning of 13 September, two days after the daily refresh went live, at about a quarter past seven, a signup on a throwaway domain was refused. Within eleven minutes, three new accounts had been created on ordinary free-webmail addresses instead, from one rented server, each verified within a minute. The block had done its job perfectly. It had changed what they did. It had not changed what they wanted, and it had cost them about the time it takes to make a coffee.

The dots

The free-webmail provider they'd moved to ignores full stops before the at-sign and anything after a plus sign. So one mailbox can produce endless addresses that are all different as text, all deliver to the same inbox, and all sail past an "is this email already registered?" check, and email verification too, because the mail genuinely arrives.

We found it on 22 September and fixed it the same day, by comparing addresses in canonical form rather than as raw text. Lower-cased, plus-tag stripped, and for that one provider the dots stripped as well. We kept storing exactly what people typed, because dots still mean something at every other provider, and a fix that mangles a real customer's address does more damage than the trick ever did.

Choosing not to block them

By the middle of September it was clear this was one operation running several accounts, and we decided not to shut it down. Two reasons. Every round had surfaced a real hole in our own signup process, and a hole we know about is worth more than one we don't. And what they were taking was free-tier usage, which cost us effectively nothing. So we chose to fix what they found and leave the accounts alone.

That's a defensible trade for a small product where the abuse costs nothing real and touches no customer data. It's only defensible while both of those hold, and both changed on 1 November. Each of the five accounts carried the promotional allowance rather than the free tier, which is a different order of cost, and those we closed. The policy didn't survive contact with a bigger prize. It was never a policy so much as a price we were willing to pay until the price went up.

Real mailboxes

That fix held. It just stopped mattering. On 9 October there was a single new account on a real mailbox, from a rented server, then three quiet weeks, then the five on 1 November.

The five accounts at the top of this post looked dot-scrambled, and our first assumption was that the canonical check had missed them. It hadn't. They were five genuinely separate mailboxes named in the same style, so there was nothing to collapse. The dots had been the trick once. By this round they were decoration. Nothing about the email was fake any more.

Which moved the weak point to somewhere we should have looked first.

We sell an API that scores IP addresses: send us one and we tell you whether it's a home broadband line, a mobile network, a hosting company or a VPN, and how much trouble it has been in. Our own signup form had never asked it a single question.

The five accounts were registered from hosting-provider addresses, the kind that belong to a rented server rather than a person. We knew this. We had already scored those exact addresses minutes earlier, without anyone noticing, because they'd been reading our public lookup pages first. Those pages sit behind a gate that scores whoever is reading them, as a side effect of deciding whether to serve the page, and it files the verdict. We don't know what they were looking at there, or why. But by the time they reached the form, their own address was already in our records with "hosting" against it, a few minutes old. The form never looked.

There's no good excuse for that, and we won't offer one. The form had a rate limit on it, and somewhere along the way a rate limit got mistaken for a check.

What we built this time

The signup form now scores the address the form is being submitted from. If that address is clearly owned by a hosting provider, the signup is refused. If it's borderline, the account is created with the ordinary free allowance instead of the promotional one.

We didn't guess where the line should go: we replayed every existing account's original signup address against the new rule. It would have refused nearly all of the signups that came from hosting addresses, and not one that came from an ordinary consumer internet provider. That's the cut-off we shipped, and why we can say it doesn't turn away normal people. We're not publishing the number; on its own, without a replay behind it, it's the wrong thing to copy.

The refusal isn't silent: it names our support address and alerts a person on our side. Some people sign up from a commercial VPN for perfectly good reasons, and a VPN exit looks like a hosting address to any scorer. A quiet "no" to that person loses a customer who never gets to explain. We'd rather read an email.

We shipped the fix. Given the history, we should have known better than to think that was the end of it.

3 November, from a phone

On 3 November, two days after we'd closed the five, another account appeared. Same operation, and we'll come to how we know. This time the signup came from a mobile phone on a consumer mobile network. A clean address, no reputation attached. The check we'd just built could not have fired, and there is no setting on it that would have caught this signup without also refusing ordinary people on their phones, which is most of the internet.

And the mailbox was on a throwaway domain again, except this domain wasn't on our list. The list had refreshed that same morning. This isn't a new failure. It's precisely the failure from 29 August, and again a fortnight after that: a domain newer than our copy of the list. We'd diagnosed that loop once and tightened it, weekly to daily, and daily still wasn't enough, because no refresh interval beats a domain that was registered this morning. Any blocklist is a record of who was using something last week, and the people using it right now are, by definition, the ones not on it yet.

Two fixes walked around in one signup, one by a phone and one by the calendar, and neither took any cleverness.

The phone is the part we keep coming back to. The first reading was adaptation. Then we went back through the cluster's registration addresses. Two of the late-August accounts had been registered from that same mobile network. They'd had a phone in their pocket the entire time, and used rented servers in between because rented servers were working. When those stopped, they reached for something they'd already used. It cost them nothing. The bypass existed before the check it bypassed had been written.

We spotted it anyway, and not from anything about the signup. The account's very first API calls came from the same shared-hosting server the earlier five had used, a box sitting behind a handful of WordPress sites. And one of those sites had already asked us about that phone, the day before. It had turned up there as a visitor, the site sent us the address to check, which is the whole of what it uses us for, and the answer went into our records along with everyone else's. The phone that registered the account was in there before the account existed.

Nothing about the identity connected the accounts. Different name, different mailbox, and a network the new check had nothing to say about. What connected them was what they did once they were in.

What the rounds add up to

Every fix we shipped was correct. The throwaway-domain check is still refusing throwaway domains. The canonical-email comparison still collapses dot-variants onto one mailbox. The signup-address score still turns away rented servers, measured so that it turns away nobody else. None of them is coming out, and between them they stop a great deal of traffic from people with less patience. Worth saying once, because the rest of this could read like two months of losing, and it wasn't.

But lay the rounds end to end and the shape is hard to miss. Four fixes inside nine weeks, faster than we'd have guessed. Each cost them a few days at most and cost us next to nothing to build. Three of the rounds were escalations: each fix changed their method and left their goal alone. The fourth wasn't an escalation at all. It was the first hole reopening, and it reopened because that defence has a floor you cannot get under. We run the list ourselves, refresh it daily and maintain the allowlist by hand, and it still wasn't enough. The rate limit was never the hole; it worked as configured and they stayed under it, because a counter can't tell a rented server from a busy office sharing one address. And the new check does nothing against one person with a phone they'd already shown us in August. It's a filter on bulk rather than a gate on people, and for two days we'd treated it like a gate.

What held up were signals that only exist once someone is already through the door. Where their requests come from. What they ask for. Whether several accounts quietly share any of it. None of that is available at the moment of signup, which is the moment every form wants to decide.

If you run a site or a shop

None of this needs a developer or anything from us. This is the order we'd follow again, cheapest first.

• Refuse throwaway email domains, and say why. Most signup tools can do this already; turn it on. It takes an afternoon and removes the laziest tier of abuse. It won't stop anyone willing to register a domain of their own, and whatever list you rely on will be a day or two behind the newest ones. Check that real mail providers can't end up on it.
• Treat dotted and plus-tagged addresses as one mailbox. If your form asks whether an email is already registered, ask it in a normalised form, or several accounts can quietly share one inbox. Keep the address as typed for sending mail.
• Look at where a signup comes from, not just how many there are. Counting alone can't tell you what kind of connection a signup arrived on, and that is the part that matters. Whether the address belongs to a hosting provider, a VPN or an ordinary home line is cheap to find out. Draw the line by replaying your existing customers against it.
• Never refuse silently. Say what happened and how to reach a person; the quiet "no" is the one that loses a good customer.
• Give promotions their own bar. If a free allowance is what makes the fraud worthwhile, a borderline signup can be let in without it. Refusing the perk is far cheaper than refusing the person.
• Then watch the account, not the form. The things that gave this away only existed once the account did: which addresses they use, what they go after, and whether two accounts that look unrelated are doing the same thing. A handful of new accounts whose first actions all come from one place are one account.
• Expect to do this more than once. Each fix is still worth making. Just don't mistake any of them for the last one.

We still don't know who this is, or whether the shared-hosting box is theirs or borrowed. We're not going to lower the bar at the front to find out. The front door is where you do the cheap, correct, necessary work, and we'll keep doing it. It's just not where this gets settled, because whatever we build there, the way round it is usually something they already own, or something that didn't exist when we last looked. The thing we watch now is the account after the welcome email, not the form before it.

Frequently Asked Questions

Does blocking disposable email domains stop fake signups?

It stops the cheapest kind, where someone uses a ten-minute mailbox, and that alone is worth an afternoon. It does not stop anyone willing to use a real free-webmail account or register a throwaway domain of their own, and any list you check against will lag the newest domains by at least a day, because a domain registered this morning is on nobody's list yet.

Why didn't a signup rate limit catch accounts created minutes apart?

Because a rate limit only counts. It cannot tell four signups from a rented server apart from four signups from an office where everyone shares one address, so it has to be set loosely enough for the office, and anyone who knows it is there simply stays under it. Knowing what kind of address a signup comes from is what separates the two cases.

Should I block signups from datacenter or hosting IP addresses?

Refusing addresses that clearly belong to hosting providers stops bulk, scripted registration, and in our replay it would have refused nearly all such signups without touching one from a consumer internet provider. Set the line by replaying your own existing customers rather than guessing, and never refuse silently, because commercial VPN users look like hosting traffic and some of them are good customers.

Can an IP check on the signup form stop a determined person?

No. It filters bulk, not people. One person on a phone over a consumer mobile network has a clean address that no sensible threshold can refuse, and in our case they had used that phone before we wrote the check. What held up were signals that only exist after the account was created: where its requests came from and what it shared with other accounts.

What is the email dot trick and how do I stop it?

Some free mail providers ignore full stops before the at-sign and anything after a plus sign, so one inbox can produce endless addresses that are all different as text, all pass an "already registered?" check and all receive the verification email. Compare addresses in a normalised form when checking for duplicates, while keeping what the person typed for sending mail, since dots are meaningful at most other providers.