How to stop fake email signups: bots, throwaways and list bombing

Fake signups rarely look fake. They arrive as ordinary rows (an address, a first name, a timestamp) and only reveal themselves later as bounces, spam complaints, trials that never convert, or a blocklist listing nobody can explain. To stop fake email signups you first have to know which kind you're facing, because a bot, a throwaway inbox and a subscription-bombing attack each slip past a different defense. This guide sorts the five kinds of fake signup, shows what each layer of protection stops and what it misses, and gives you a block, warn or allow rule for every verification result.

The short answer#

No single check stops fake signups; a stack of cheap ones does. Put a honeypot field and per-IP rate limiting in front to drop simple bots, a CAPTCHA such as Cloudflare Turnstile to stop smarter ones, real-time email verification on the form to reject undeliverable and disposable addresses and suggest fixes for typos, and double opt-in so nothing receives marketing mail until a real person confirms. Then monitor signups by source so an attack shows up within hours, not at your next campaign.

Keep one limit in mind: verification judges the address, not whether the person typing it owns it. That's why subscription bombing, where the addresses are real, needs the other layers.

The five kinds of fake signup#

"Fake signup" covers five different problems. The fix depends on which one is hitting your forms, so diagnose before you build.

Bots filling your forms#

Scripts crawl the web, find forms and submit them: random strings at real domains (xk7q2v@gmail.com), invented domains, scraped addresses, or test runs of stolen data. Some put a spam link in the name field and let your welcome email (Hi {first_name}) deliver it for them. Bot signups inflate your list, hard-bounce when the address was invented, and pollute the engagement numbers you use to judge every campaign.

Disposable addresses#

A real person with a throwaway inbox. They want the discount code, the download or the free tier, and they give you an address built to stop existing shortly after. It may accept mail at signup, so it looks fine, but nobody will ever read your email there. The role, disposable and free breakdown explains why these come back risky rather than undeliverable, and you can test any domain with the free disposable email checker.

Typos that look like fakes#

Not every bad signup is malicious. jane@gmial.com is a real customer who hit one wrong key, and treating her like a bot loses someone you could have kept with a one-click "did you mean gmail.com?" prompt. Separate typos from fakes, because the right response is the opposite: help, don't block. The most common email typos follow patterns predictable enough to catch at the keyboard.

Subscription bombing#

This is the one that can hurt your domain. In a subscription bombing (or list bombing) attack, a script signs a victim's real address up to hundreds of forms at once, usually to bury a fraud alert or a password-change notice under a flood of welcome emails. Your form is the weapon, not the target.

What makes it dangerous is that the addresses are real and deliverable, so they pass every address check. The victim, drowning in mail they never asked for, marks it as spam, and those spam complaints count against your domain. A form that mails anyone who's been typed into it, with no confirmation, is exactly what blocklist operators treat as a source of unsolicited mail, so a bombing wave run through your form can get your sending IP or domain listed. An attacker's input list can also contain spam traps.

Free-trial and incentive abuse#

The same person signing up again for another trial, another first-order coupon or another referral bonus. They rotate disposable domains, plus-addressing (jane+2@gmail.com), Gmail's dot-insensitivity (j.ane@gmail.com lands in the same inbox as jane@gmail.com), or a fresh free-mail account each time. Most of these addresses are perfectly deliverable. The problem is the person, not the mailbox, so the fix lives in your own duplicate detection (compare a normalized form of each address while storing what was typed) and in signals beyond email, like payment details.

The layered defense, layer by layer#

Each layer is cheap and each is blind to something. Stacked in this order, they cover each other's gaps.

Honeypot field#

Add an input real people never see. Hide it with CSS rather than type="hidden" (many bots skip hidden inputs), wrap it in an element marked aria-hidden="true", and give it tabindex="-1" and autocomplete="off" so keyboard users and password managers leave it empty. If it arrives filled, return your normal success page and silently discard the submission. An error message only teaches the bot what to change.

Rate limiting per IP and per address#

Limit on the server, not in the browser, and count two things: submissions per IP and submissions per email address. Set the IP threshold well above what a busy office or a mobile carrier's shared IP produces, so real people behind a shared address aren't locked out. The per-address limit matters most against list bombing: the same address hitting your form several times in a few minutes is the signature, and it should never trigger more than one confirmation email in a given window.

CAPTCHA or Cloudflare Turnstile#

A challenge stops most automated submissions, including the scripts behind list-bombing campaigns. Turnstile usually needs no interaction at all, which keeps friction low. The common mistake is checking only in the browser: the widget protects nothing unless your server validates the token with Cloudflare's siteverify endpoint before it accepts the signup, because a bot can post straight to your form handler without ever loading the widget.

Real-time email verification on the form#

Once the bot checks pass, call a verification API from your server before you save the address, and act on the result with the decision table below. Two rules: keep the API key server-side, and fail open. If the call errors or times out, accept the signup and catch it in your next clean. The serverless signup pattern has working code, and the Qualisend verification API returns the verdict, reason code, sub-flags and any did_you_mean suggestion in one response.

Hosted form builders work differently, because the respondent submits on the vendor's page and you can't reject inline from your own server. Qualisend's native connectors for Typeform, Jotform and Tally check each response as it arrives and give you a clean export; to stop a bad address before it reaches your CRM or ESP, route responses through an automation, as the Typeform, Jotform and Tally guides show. On WordPress you can block before the entry saves, with a validation filter: see the Gravity Forms guide and the WordPress forms guide for Contact Form 7 and WPForms.

Double opt-in#

Don't add anyone to a marketing list until they click a confirmation link. It's the one layer that defuses subscription bombing even when everything before it fails: the victim gets a single confirmation message instead of an ongoing newsletter, and an unconfirmed address never joins your list. Keep that confirmation email plain: no offers, no promotional content, and never echo user-supplied fields like the name, which is how bots smuggle links into your mail. The trade-offs are covered in single vs double opt-in.

Monitoring signups by source#

Prevention fails eventually, so make sure you notice. Track signups per hour by form, source and referrer, and alert when a source jumps far above its normal range. Watch three ratios per source too: the share of signups that fail verification, the share that are disposable, and the confirmation rate. A coupon form whose disposable share suddenly climbs has probably been posted on a deal forum. A form whose confirmation rate collapses while volume spikes is probably being used to bomb someone. Paid lead forms have their own version of this problem, covered in fake leads from lead ads.

Block, warn or allow: acting on each result#

Once an address has passed the bot layers, the verification result decides what happens to it. This is a sensible default:

The top three rows are near-universal. The rest depend on your business. A developer tool will see legitimate admin@ signups; an ecommerce store's customers are mostly on free mail; a B2B demo form may care about company domains but still shouldn't turn away a buyer using Gmail. Treat role, catch-all and free mail as context, not as fakes.

One note on timing: the instant result covers syntax, domain, disposable, role and typo checks, while the mailbox check can finish after your form has already responded. Act on the instant result at the form, and use the full result in a background step (before the welcome series starts or a trial is provisioned) so nobody waits on a slow mail server.

Cleaning up fake signups that already got in#

If fakes are already on your list, work through it in this order:

1. Find the window and the source. Sort recent signups by time and form. A bot run or a bombing wave usually shows up as a cliff: hundreds of signups in an hour from a form that normally sees a handful.
2. Stop mailing that segment. Pause welcome series and automations for it before the next send, so you don't keep generating bounces and complaints while you sort it out.
3. Verify the segment. Export it and run a bulk job, or, if the list lives in a connected platform such as Klaviyo, Mailchimp or ActiveCampaign, clean it in place and get the verdicts written back as tags or fields. Suppress undeliverable and disposable addresses. The list-cleaning guide covers the full loop.
4. Don't keep bombing victims because they verified. Addresses fed in by a list-bombing script are real, so they come back deliverable. If they arrived in the attack window and never confirmed or engaged, remove them anyway. These people never asked for your mail.
5. Watch the aftermath. Check your complaint rate in Google Postmaster Tools over the following days, and check your sending domain and IPs with the free blacklist checker. If you'd rather be told than keep checking, Blacklist Monitoring re-checks them every 24 hours and emails you when a listing appears.
6. Close the hole before you reopen the form. Add whichever layer the attack walked through, then turn the form back on.

From there, fold the fixes into your routine: the email list hygiene checklist covers the ongoing habits, and how to avoid email blacklists covers what else keeps a sending domain off blocklists.

Want to see what your forms are letting in? Check any address with the free email checker, then add verification to your signup flow with the verification API. New accounts get 100 free credits that never expire.