List bombing explained

List bombing, also called subscription bombing, is an attack in which bots submit one person's address to hundreds of sign-up forms at once, so that confirmation and welcome messages bury that person's inbox. Attackers use the flood to hide a fraud alert or a password reset, or as cover for a fake help desk call. Every form that took part sent mail nobody asked for, and its owner pays with spam complaints, blocking and possibly blocklisting. The defense is a bot challenge verified on your server, a honeypot field, rate limits, a confirmation step that sends exactly one message, and monitoring for spikes.

What list bombing is

The M3AAWG Sender Best Common Practices (version 4.0, August 2026, section 4.2) describe a script that fills in hundreds of subscription forms with the same address. Each form then sends a confirmation, a subscription notice or another transactional message, and together they overwhelm the victim's mailbox for an extended period. No single form contributes much, which makes it hard for any one site to notice that it is part of the attack.

Spamhaus described an early large campaign in Subscription bombing: COI, CAPTCHA, and the next generation of mail bombs (September 2016). It started with government addresses, reached over 1,000 sign-ups per minute and left mailboxes unusable for long periods. Some of the mail came from account sign-ups on ordinary websites, so it looked legitimate.

A second form of abuse uses one form with many addresses. Amazon SES's listbombing notification describes an attacker who registers a very large number of addresses on a web-based form. Either way, your form mails people who never asked.

Why attackers do it

• To hide a security notice. M3AAWG's 2017 release on list bomb attacks explains that a fraudulent transaction alert or password reset notice can be lost in the flood, so the victim never sees it. The same tactic can lock journalists or activists out of their email.
• As cover for social engineering. The FBI and CISA advisory #StopRansomware: Black Basta (AA24-131A, May 2024, updated November 2024) describes affiliates who sent targets a large volume of email, often from website registrations and subscriptions, then called them posing as technical support, offered to fix it and asked them to install a remote access tool.
• As plain disruption. Spamhaus calls it a denial-of-service attack on the inbox.

Why it hurts the form owner

The victim did not sign up, so to them your confirmation is spam, and many will report it as such. Complaints count against your domain and IP address at mailbox providers; Gmail and Yahoo ask senders to keep the spam rate below 0.3% (Gmail and Yahoo sender requirements).

Beyond complaints:

• Blocking and account reviews. Amazon SES says list bombing can get your email blocked by mailbox providers, and that anti-spam organizations flag forms they find vulnerable to it; SES can place such an account under review and later pause its sending.
• Responsibility. Spamhaus's 2016 article puts the duty to secure a form on anyone whose web sign-up sends an email, not only on email platforms (email blocklists and delisting).
• Traps and junk on your list. M3AAWG's spam trap guidance lists forms that bots fill in among the ways traps reach a list (spam traps). Addresses that never confirmed and stay in your database will be mailed again by your next campaign.

Defenses

M3AAWG recommends combining several measures, which together make a form harder to recruit into an attack.

A bot challenge, verified on your server

Spamhaus calls a CAPTCHA the single best way to keep a form from becoming an attack vector, and M3AAWG lists it first: the form should not submit without a completed challenge. Use any challenge you like, such as Google reCAPTCHA or Cloudflare Turnstile, but check its token on your server:

• Google's reCAPTCHA verification docs say each response token is valid for two minutes and can be verified only once, to prevent replay.
• Cloudflare's Turnstile docs say a token is valid for 300 seconds and can be validated once, and that the widget alone does not protect your form: without the server-side check, an attacker can post a forged token straight to your endpoint.

Reject the submission when verification fails or the token is missing.

Honeypot and timing fields

M3AAWG suggests fields that a person never sees but a bot fills in, such as a second, hidden email field: drop any submission that fills it. Hide it so that keyboard and screen reader users skip it too. Two related ideas from the same list:

• Record when the page was loaded (or issue a key with it), and discard submissions that arrive faster than a person could type, or without the value at all.
• Give fields unusual names instead of the standard ones scripts look for, and move a form to a new URL after it has been attacked.

Rate limits

M3AAWG recommends limiting how often the same IP address can submit a form within a period of time, and, for a sender or platform that hosts many forms, watching for the same address being added to many different forms. Add a limit per address as well: one email address should not trigger more than one confirmation in a day, however often it is submitted. A site that serves one region can show the form only to visitors from that region, and only your own servers should be able to post to the backend that stores sign-ups.

A confirmation that sends one message

Double opt-in keeps victims off your list, because they never click. On its own it does not stop the flood: Spamhaus noted that many abused lists already used confirmed opt-in, and the confirmations themselves were the problem. So keep that one message harmless:

1. Send a single confirmation per address, and do not resend it when the same address is submitted again.
2. Send nothing else, no welcome series or offers, until the person confirms. Amazon SES gives the same advice.
3. Keep the confirmation plain and free of advertising, as M3AAWG recommends, and where you can, send it from servers apart from your bulk mail (transactional vs marketing email).
4. Expire and delete unconfirmed sign-ups after a short period.

M3AAWG also suggests a header that marks mail sent in response to a web form, so mailbox providers can spot a flood. Its specification, draft-levine-mailbomb-header, is an expired individual Internet-Draft, not a standard.

Server-side validation

Validate each address on your server when the form is submitted, behind the same bot check and rate limits, so bots cannot spend your credits. Validation fixes typos and turns away malformed and throwaway addresses, but it cannot stop list bombing by itself: the victim's address is real, and its mailbox accepts mail.

Some results help anyway. The reason abuse_linked means the address is associated with spam, abuse or automated sign-ups; its status is valid and its action is remove. At a sign-up form, the recipe is to accept such results and flag them rather than block the person, so hold flagged sign-ups out of your marketing sends until they confirm.

Monitoring

M3AAWG lists abnormal list growth, a sudden jump after steady growth, as a warning sign. Watch for:

• sign-ups per minute well above your normal rate, especially at night or from one network;
• a falling confirmation rate, since victims and bots do not click;
• many sign-ups from one IP address or a narrow range, or one address submitted again and again;
• spam complaints about the confirmation message itself (feedback loops).

When an alarm fires, tighten the challenge, pause confirmation mail from that form and move the form if needed.

If your form was used

1. Stop the mail first: pause the form or its confirmation step.
2. Add the missing defenses above before you reopen it.
3. Delete sign-ups from the attack window that never confirmed.
4. If an anti-spam organization or your platform has flagged you, Amazon SES suggests a permission pass: ask your list whether people still want your mail, and keep only those who say yes.
5. Watch your complaint rates and any blocklist listing until they are back to normal (sender reputation).

Questions

Does double opt-in stop list bombing?

It keeps victims off your list, but your confirmation still lands in the flood. Combine it with a bot challenge and rate limits, and send at most one confirmation per address.

Can email validation detect list bombing?

Not on its own. The victim's address is usually a working mailbox. Validation catches malformed, mistyped and throwaway input, and a result such as abuse_linked can flag an address for review, but the bot challenge and rate limits are what stop the attack.

What should someone do if their inbox is being bombed?

Check banks, shops and email accounts directly for activity they did not start, since the flood may hide an alert. Be wary of anyone who calls or messages offering to fix the spam: the CISA advisory describes exactly that move.

Try it

See how an address checks out with the free email checker, or add checks to your form with the email verification API.

Related

• Sign-up form validation.
• The valid status: addresses to remove.
• Glossary: double opt-in.
• Test addresses to try every branch of your form handler.

Related guides

• Double opt-in (confirmed opt-in)
• Spam traps explained
• Email blocklists explained
• Sender reputation explained
• Email feedback loops explained
• All guides

Sources

• M3AAWG: Sender Best Common Practices, version 4.0 (August 2026): section 4.2 on list bombing and form defenses, 4.1 on confirmation messages, 2.7 on abnormal list growth.
• M3AAWG: M3AAWG Recommends Adding New Email Header to Mitigate List Bomb Attacks from Subscription Sign-Up Forms (November 2017): why attackers bomb inboxes, CAPTCHA advice.
• M3AAWG: Help! I Hit a Spam Trap!: bot-filled forms as a trap source.
• Spamhaus: Subscription bombing: COI, CAPTCHA, and the next generation of mail bombs (September 2016): the 2016 campaign, CAPTCHA plus confirmed opt-in.
• CISA: #StopRansomware: Black Basta (AA24-131A): email bombing followed by fake technical support calls.
• AWS: Reputation metrics messages (Amazon SES): listbombing notification, blocking risk, CAPTCHA, confirmation and permission pass.
• Google: Verifying the user's response (reCAPTCHA): token lifetime and single use.
• Cloudflare: Validate the token (Turnstile): token lifetime, single use, server-side validation.
• IETF: A Message Header to Identify Subscription Form Mail (draft-levine-mailbomb-header): status of the proposed header.

How we wrote this: drafted by the email-validation.org team with the help of AI writing tools, from our product documentation and the sources linked in the text.