How can I tell that bots are creating customer accounts in my shop?

Typical signs are spikes in new sign-ups without matching orders, addresses at disposable services or domains without a mail server, links or promotional text in the name field, many accounts from the same network range and a growing stock of unconfirmed accounts. A single feature is not proof. The suspicion becomes reliable when several signals come together, for example a spike while the share of confirmed accounts falls at the same time.

Is double opt-in enough against fake sign-ups?

It keeps made-up and other people's addresses out of the newsletter, because the account only becomes active after the confirmation link is clicked. The accounts are still created, though, and every confirmation email to someone else's address is an email the recipient did not want. M3AAWG therefore recommends combining several protective measures (M3AAWG): confirmation email, rate limiting, an invisible field and a timing check.

Does a CAPTCHA at sign-up still make sense?

As a first measure, usually not. Under WCAG 2.2, picture puzzles need an alternative for different types of sensory perception (W3C), and they slow down real customers. The W3C note on CAPTCHA advises staying with a honeypot as long as it suffices (W3C). A puzzle is added when measurement shows that confirmation email, rate limiting and honeypot are not enough, and then with an accessible alternative.

May I simply delete fake accounts?

Unconfirmed accounts without orders can usually be deleted; Art. 5 (1) (d) GDPR even requires inaccurate data to be erased or rectified without delay (GDPR). Accounts with orders are better blocked, because accounting vouchers must be kept for eight years under Section 147 (3) of the German Fiscal Code (AO). The criteria, number and time of the cleanup belong in the record, the deleted content does not.

What should I do if a bot has registered a real stranger's email address?

The address receives no advertising: without prior express consent, advertising by email is an unreasonable nuisance under Section 7 (2) No. 2 UWG (UWG). With double opt-in active, the account stays unconfirmed and is deleted once the period expires. If the person concerned asks, information on the action taken must be provided within one month at the latest (GDPR).

What alert threshold makes sense for new sign-ups?

There is no fixed number for all shops. A sensible threshold is based on your own baseline per hour and weekday, for example a multiple of the usual value, combined with a minimum count against false alarms during quiet night hours. It is also worth watching the share of confirmed accounts. Planned campaigns such as a newsletter with a sign-up incentive are noted in advance so that real spikes do not trigger an alert.

Fake Customer Accounts: Stop Bot Sign-ups in Your Shop

A sign-up form is an invitation, and scripts are happy to accept it. When the number of new accounts jumps to a multiple of the usual level overnight without carts or orders following, the shop has rarely won new customers. Usually a program is working through the form in series. OWASP lists this pattern as an automated threat of its own under the identifier OAT-019 Account Creation and sums up the purpose briefly: accounts are created in bulk to be misused later (OWASP). For a shop, the damage shows up in three places: in the newsletter list, in the metrics and in first-order discounts. This article shows how to recognize bot sign-ups, which countermeasures do not slow down real customers, how a cleanup works in line with data protection law and how an alert threshold reports the next wave early.

Key takeaways

OWASP lists automated bulk sign-ups as a threat of its own, OAT-019 Account Creation (OWASP): fake accounts are created to be used later for purposes such as spam, laundering cash and goods or skewed reviews.
Fake accounts in the newsletter drive bounces and spam reports. Google requires senders to avoid ever reaching a spam rate of 0.30 percent (Google) in Postmaster Tools; a confirmation email before the first send keeps other people's addresses off the list.
You can recognize bot sign-ups by spikes without orders, disposable domains, links in the name field, many accounts from the same address range and a growing stock of unconfirmed accounts.
Confirmation emails, rate limiting with status code 429 (RFC 6585), an invisible form field and a timing check slow scripts down without stopping real customers with a picture puzzle.
When cleaning up, delete unconfirmed accounts without orders and block accounts with orders, because accounting vouchers must be kept for eight years (AO) under Section 147 (3) of the German Fiscal Code.
An alert threshold based on your own hourly baseline, combined with the share of confirmed accounts, reports the next wave before the newsletter goes out to fake accounts.

What lies behind fake accounts

The OWASP entry describes the approach as bulk account creation through the application's regular sign-up process, sometimes including a populated profile. As later uses it names, among others, spam, laundering cash and goods, spreading malware, damaging reputation and skewing reviews and surveys (OWASP). The synonyms on the same page include “Fake account” and “Massive account registration”. The distinction matters for defense: OAT-019 creates new accounts. Taking over existing accounts with stolen credentials follows a different pattern, which the article on account takeover and customer accounts covers.

The weaknesses the entry refers to are revealing: improper control of interaction frequency (CWE-799), improper enforcement of a single, unique action (CWE-837) and of a behavioral workflow (CWE-841) (OWASP). Translated into everyday shop operations, this means the gap is usually not a programming error. The form works exactly as it was built. It can simply be submitted as often and as fast as anyone likes, without anyone noticing.

A platform operator shows how large the volumes can get: according to its own figures, Microsoft blocked about 1.6 million bot sign-up attempts per hour between April 2024 and April 2025 (Microsoft). The figure refers to the group's own services and cannot be scaled down to a single shop. It does show, however, that account creation is automated on a large scale. A shop does not need to be a prominent target for this. It is enough that its form can be reached without any hurdle and that scripts find it.

What fake accounts are used for in a shop

Newsletter: sign-up via a checkbox in the registration form, often with other people's addresses. First-order discount: welcome codes tied to a new account. Advertising via the welcome email: promotional text or links in the name field that the shop copies into the greeting. Reviews: where only registered customers may leave a review. Stockpiling: accounts that are only used later for another purpose, exactly in the sense of the OWASP summary “for subsequent misuse”.

Why fake accounts strain newsletters and metrics

If the shop offers the newsletter sign-up directly in the registration form, fake accounts also end up on the recipient list. For sending, that means two things: addresses that do not exist come back as bounces. Real addresses that a script has slipped in for strangers receive advertising they did not ask for, and their owners report it as spam.

Legally, the second case is delicate. Under Section 7 (2) No. 2 of the German Act against Unfair Competition (UWG), advertising by electronic mail without the addressee's prior express consent is an unreasonable nuisance (UWG). The exception for existing customers in Section 7 (3) UWG requires, among other things, that the trader obtained the address in connection with the sale of goods or services (UWG). An account without an order does not meet that condition. If sending is based on consent, the controller must also be able to demonstrate under Art. 7 (1) GDPR that it was given (GDPR). A checkbox ticked by a script is weak evidence for that.

Deliverability suffers too. In its email sender guidelines, Google requires all senders to Gmail accounts to keep the spam rate measured in Postmaster Tools below 0.3 percent (Google). As a guideline, the same page recommends staying below 0.10 percent and avoiding ever reaching 0.30 percent (Google). Senders who send more than 5,000 messages per day to Gmail accounts have had to meet additional requirements since February 1, 2024 (Google). The same page advises confirming each recipient's address before adding it to a list and automatically unsubscribing recipients with multiple bounces (Google). The industry association M3AAWG (Messaging, Malware and Mobile Anti-Abuse Working Group) is more specific: how many campaigns and over what period is up to each sender, but it is generally considered best practice to remove an address from the list if it bounces consecutively at least two times over two weeks or more (M3AAWG). How authentication and deliverability of shop emails fit together is described in the article on DMARC and shop emails.

The third kind of damage is quieter. Fake accounts inflate the number of new customers and lower the ratio of sign-ups to first orders. Anyone who judges campaigns by new registrations is then partly judging scripts. If a welcome discount is tied to the new account, it can be claimed many times over across many accounts. How to protect new-customer codes against this is covered in the article on discount codes during Black Week; this article is about the account itself.

When the shop becomes a tool against third parties

In so-called list bombing, a script fills out hundreds of subscription forms with the same email address so that the victim's mailbox collapses under confirmation and welcome emails (M3AAWG). The individual shop notices little of this, because only a few sign-ups fall on it. The victim's complaints still hit its sending domain, and every confirmation email without rate limiting makes the shop part of the wave.

How to recognize bot sign-ups

No single feature proves that an account is fake. The picture only becomes reliable when several signals come together. The W3C note on the inaccessibility of CAPTCHA names exactly such heuristics: the volume of data requested, common sequences of pages visited, IP addresses and data entry methods (W3C). For a shop, five signals can be derived from this that are measurable without additional services:

Sign-up spikes without orders: the number of new accounts per hour jumps to a multiple of the usual level without carts or orders following. An even rhythm around the clock, which real customers rarely produce, is also conspicuous.
Disposable and made-up domains: addresses at services for single-use mailboxes, domains without a mail server or random strings without a recognizable name in front of the @. Whether a domain accepts mail at all can be checked via DNS.
Links and promotional text in name fields: for example a first name “Claim your bonus” and a last name containing a web address. The target is usually the welcome email: the shop puts the name into the greeting and sends the promotional text under its own sender address.
Many accounts from the same address range: several sign-ups from one network range in quick succession. Depending on the setting, Shopware stores the IP address in full or with the last segments anonymized (Shopware documentation). For grouping by network range, this version is usually sufficient.
Unconfirmed accounts: if email confirmation is active, accounts with made-up addresses remain unconfirmed for good. A growing stock of unconfirmed accounts is a signal in itself.

Signal	How to measure	False alarm possible due to	Appropriate response
Hourly spike	New accounts against your own baseline	Newsletter, advertising, media coverage	Alert, check form and logs
Disposable domain	Domain comparison and DNS lookup	Customers who use such addresses deliberately	Require confirmation, discount only after an order
Link in name field	Patterns such as http, www or a domain ending in the name	rare	Reject the input with a clear message
Same address range	Accounts per truncated network range and hour	Corporate networks, mobile carriers, public Wi-Fi	Throttle rather than block
Unconfirmed account	Share of unconfirmed accounts after the confirmation period	Confirmation email in the customer's spam folder	Delete after the period, do not write to them

The false alarm column is not an afterthought. Mobile carriers and corporate networks put many people behind a few public addresses. A network range with many sign-ups can therefore also be a workforce that has just received the same email with a campaign link. That is why individual signals lead to review and throttling, and only a combination of several signals leads to blocking.

Countermeasures without a hurdle for real customers

The order of the measures determines who feels them. A sensible setup starts with protection that real customers do not even notice. The industry association M3AAWG explicitly recommends combining several solutions, because a form with several hurdles is harder to recruit for abuse (M3AAWG).

Confirmation email before the first login

The account only becomes active once the link in the confirmation email has been clicked. Shopware offers the double opt-in on sign-up option for this: after submitting the form, the customer receives an email with a link to complete the registration (Shopware documentation). M3AAWG describes confirmed opt-in as the highest standard because it keeps typos and maliciously submitted addresses out of ongoing mailings (M3AAWG).

Two details decide how well it works. The confirmation email should be simple and free of advertising so that it is not itself filtered as abuse (M3AAWG). And it should not repeat any free-text fields such as the name; otherwise the shop sends the promotional text from the name field along with the very first email. On WordPress sites without customer accounts, the simplest measure is to switch off open registration: the “Anyone can register” setting in the general settings decides whether anyone can create an account (WordPress documentation).

Rate limiting at the form

A person signs up once, a script submits the form in series. Rate limiting per network address targets exactly this difference. M3AAWG recommends limits that prevent forms from being submitted repeatedly by the same IP address over a period of time (M3AAWG). In nginx, the ngx_http_limit_req_module module handles this: it limits the request processing rate per defined key, in particular per IP address (nginx documentation). Slow rates are specified there per minute, and the module does not count requests with an empty key (nginx documentation). This makes it possible to limit only the submission of the form while viewing the page stays free.

register-rate-limit.conf

# http context: only submissions (POST) are counted, viewing the page stays free
map $request_method $register_limit_key {
    POST    $binary_remote_addr;
    default "";
}
limit_req_zone $register_limit_key zone=register:10m rate=6r/m;

# server context of the shop: storefront form and Store API
location ~ ^(/store-api)?/account/register$ {
    limit_req zone=register burst=5 nodelay;
    limit_req_status 429;
    # limit_req_dry_run on;   # for calibration: count, do not reject
    try_files $uri /index.php$is_args$args;
}

The values in the example are a starting point, not a rule for every shop. Without its own setting, nginx answers rejected requests with status 503 (nginx documentation). A better fit is 429 Too Many Requests: the code indicates that too many requests were sent in a given amount of time (RFC 6585). The response page should explain the situation in plain language, and responses with this status must not be stored by a cache (RFC 6585). With limit_req_dry_run, the rule can first run in trial mode: requests are not limited, but excess requests are counted (nginx documentation).

Two pitfalls are part of the setup. If a proxy or load balancer sits in front of the shop, nginx needs to know the real visitor address; otherwise all customers share one counter. And Shopware accepts registrations not only through the storefront form but also through the Store API; the limit has to cover both paths. A WAF with bot protection adds more general rules against automated access to the rate limit.

Invisible field and timing check

A honeypot is a form field that people do not see but scripts fill in. Shopware ships this variant among its captcha solutions: an additional invisible field is offered, bots and scripts fill it in and are rejected (Shopware documentation). The W3C note on CAPTCHA considers the approach easy to implement, even in hand-authored markup, and recommends considering it (W3C).

So that the field does not catch real customers, it needs three precautions: it must also be hidden from screen readers, it must not be reachable with the Tab key, and the browser's autofill must not fill it in. If one of these is missing, it is precisely a customer with assistive technology or a password manager who fails the check. In addition, a timing check measures how much time passes between loading the page and submitting it. M3AAWG recommends discarding submissions that arrive faster than a realistic time to fill out the form or where the time stamp is missing entirely (M3AAWG). The limit should be generous, because autofill completes a form in seconds.

Checking the email domain without guessing

An address whose domain does not accept mail cannot confirm an account. RFC 7505 describes the so-called null MX record for this: a domain that does not accept email advertises a single MX record with preference 0 and an empty target, written as a dot (RFC 7505). A missing MX record alone, on the other hand, is no reason for rejection, because delivery then falls back to the domain's A or AAAA record (RFC 7505). So you can reject domains with a null MX and domains that do not resolve at all, but not every domain without an MX record.

Restraint is advisable with disposable domains. Block lists go out of date quickly and also hit customers who use such addresses deliberately to protect their data. It makes more sense to require confirmation and to release benefits such as a welcome discount only with the first paid order. Then a fake account is no longer worth it for the discount, and the customer with a single-use address can still buy.

Accessible checks instead of puzzles

Picture puzzles are a widespread countermeasure, but one with clear side effects. For CAPTCHA, WCAG 2.2 requires in success criterion 1.1.1 text alternatives that describe the purpose and alternative forms for different types of sensory perception (W3C). Besides the honeypot, Shopware offers a Basic CAPTCHA that shows a distorted combination of numbers and letters as a graphic, which the visitor must type out exactly (Shopware documentation). On its own, that is a purely visual check. Anyone who uses it needs an equivalent alternative for people who cannot read the image.

If the shop uses the same check at login, success criterion 3.3.8 also applies: a cognitive function test such as solving a puzzle must not be required for any step of an authentication process unless that step offers another method without such a test or a mechanism to assist; exceptions apply to recognizing objects and personal content (W3C). Independently of that, the W3C note on the inaccessibility of CAPTCHA draws a clear line: users should not be burdened beyond what security actually requires, and if a honeypot suffices, the honeypot should stay until evidence of robotic attacks dictates something else (W3C).

External verification services that analyze behavior and device data in the background often just shift the problem. They transfer data to third parties and need their own data protection review. As a rule, the combination of confirmation email, rate limiting and honeypot is the better starting point; a puzzle is only added when measurement shows that these three are not enough, and then with an accessible alternative. Since the German Accessibility Strengthening Act (BFSG) applies to many shops, an inaccessible registration is more than a convenience problem. How accessibility is maintained in ongoing operations is described in the article Web Accessibility: Keep Your Shop EAA-Compliant.

Cleaning up fake accounts in line with data protection

Once a wave has passed, the accounts remain in the database. Deleting them is right, but not across the board. Art. 5 (1) (d) GDPR requires personal data to be accurate and inaccurate data to be erased or rectified without delay (GDPR). An account with an invented name and someone else's address is exactly such a record, provided it concerns a real person. At the same time, the principle of data minimization in Art. 5 (1) (c) GDPR limits the analysis: only what is needed to prove the pattern is evaluated (GDPR).

Define the scope: set criteria, such as the period of the wave, unconfirmed, no order and one of the signals above, and count the matches before anything is deleted.
Delete unconfirmed accounts without orders: they contain no business transactions. Newsletter entries for the same addresses are removed as well.
Block accounts with orders instead of deleting them: accounting vouchers must be kept for eight years under Section 147 (3) of the German Fiscal Code (AO). Shopware also points out that when a customer account is deleted, data subject to legal retention periods, such as order information, is retained (Shopware documentation).
No mass email to the addresses: a message about the deletion sent to many strangers' addresses generates exactly the complaints you want to avoid.
Keep a record: note the criteria, number, time and the person who carried it out, without repeating the deleted content in the record.
Plan for backups: deleted accounts remain in backups until these are overwritten as scheduled. How retention and deletion fit together for backups is described in the article on GDPR-compliant backups.

If a person whose address was used without their knowledge gets in touch and requests access or erasure, the deadline from Art. 12 (3) GDPR applies: information on the action taken must be provided without undue delay and at the latest within one month of receipt of the request (GDPR). A prepared reply for exactly this case saves time and follow-up questions. Analyzing a wave also requires server logs; how long IP addresses may remain there is described in the article on shop server logs.

An alert threshold for new sign-ups

Often a wave only becomes noticeable when the next newsletter produces bounces and complaints. A metric that measures directly at the form reports earlier: new accounts per hour and per day, compared with your own baseline. M3AAWG explicitly counts monitoring sign-up forms among the measures for detecting bot abuse (M3AAWG). The threshold is set up in five steps:

Step 1

Measure the baseline

Record new accounts per hour over several weeks, separated by weekday and time of day. Look at campaign weeks separately so that they do not distort the normal value.

Technically, a query on the customer table or an evaluation of the log lines for the registration path is often enough. How log analysis and alerting work together is shown in the article on log monitoring and alerting. The same logic of baseline and spike also protects checkout against card testing attacks. With IPv6, one more point comes in: attackers there easily change their address within their network range. A limit per single address then has less effect, and the alert threshold on the total count becomes all the more important.

What maintenance takes care of

Sign-up protection is not a one-time setting. Updates can change forms, extensions open new sign-up paths, such as a newsletter field in the footer, and attackers adapt their scripts to the defenses. We apply security updates for the shop system and extensions through our security updates after testing them on a staging environment and then check the shop's functions. In Shopware maintenance, every update runs on a staging environment first, supplemented by manual tests for custom adjustments; registration including the confirmation email belongs on that checklist. In WordPress maintenance, forms are explicitly part of the automated checks.

Confirmation email

Account active only after the click, email without advertising and without free-text fields.

Rate limiting

Submissions limited per network address, response with status 429 and a clear message.

Invisible field

A honeypot that also stays hidden from screen readers and autofill.

Domain check

Reject null MX and non-resolving domains, do not block disposable addresses across the board.

Alert threshold

New accounts per hour against the baseline, plus the share of confirmed accounts.

Cleanup

Delete by criteria, block accounts with orders, record everything in the log.

In monitoring, new sign-ups and the confirmation rate can be tracked as application-specific metrics with their own alert threshold, calibrated to the shop's load profile. GDPR updates support double opt-in and retention periods. Which services are included and to what extent is set out in the SLA maintenance contract; the services page gives an overview of all components.

Sources

This article is based on data from: OWASP, Automated Threats to Web Applications, OAT-019 Account Creation; Microsoft, Cyber Signals Issue 9 (April 2025); Google, Email sender guidelines (Gmail Help); M3AAWG, Sender Best Common Practices, Version 4.0 (August 2026); IETF, RFC 6585 and RFC 7505; nginx documentation, module ngx_http_limit_req_module; W3C, WCAG 2.2 and Inaccessibility of CAPTCHA (Group Draft Note, December 2021); Shopware documentation, settings Basic information and Log-in & sign-up; WordPress documentation, Settings General Screen; Regulation (EU) 2016/679, General Data Protection Regulation (GDPR); German Act against Unfair Competition (UWG), Section 7; German Fiscal Code (AO), Section 147. All information was checked against these sources on October 15, 2026.