Attackers use unprotected signup forms to bury a victim's inbox in confirmation mail. How the attack works, why your domain absorbs the damage, and how to close the door.
A subscription bomb is a denial-of-service attack executed entirely through legitimate signup forms. The attacker takes one victim's email address, feeds it into thousands of unprotected newsletter and account-creation forms, and every one of those forms dutifully sends a confirmation message. The victim receives several thousand emails in an hour, and the real objective is usually concealment: buried somewhere in that flood is a purchase receipt or a password-reset notice the attacker does not want read. The senders are collateral. Your form did exactly what it was built to do, your domain sent unsolicited mail to somebody who never asked for it, and the complaints arrive at your reputation rather than the attacker's.
Why the damage lands on you
Confirmation mail generated by an attack is indistinguishable from ordinary traffic at the point of sending and highly distinguishable at the point of receiving. The victim marks it as spam, usually in bulk, and every one of those complaints is attributed to your sending domain and IP. Because a campaign targets the same victim across thousands of senders at once, the receiving provider observes a coordinated wave and treats participation in it as a quality signal about each participant. Worse, the address lists harvested for these campaigns include spam traps by sheer statistical accident, and a form accepting unvalidated input at volume will eventually mail one. The sender that suffers most is simply the one whose forms are easiest to script.
Detecting it while it happens
The signature is a shape rather than a single metric. Signup volume rises sharply out of pattern, confirmation rates collapse because nobody confirms an address they never entered, and the new addresses cluster oddly: heavy skew toward one mailbox provider, a run of near-identical local parts, or a burst from a narrow IP range or a single referrer. In addition, the ratio of form submissions to page views goes wrong in a way ordinary traffic never produces, which makes it the most reliable single alert if you have both numbers available. Set alerting on that ratio and on submissions per minute, because by the time complaint data surfaces in Postmaster Tools the attack is two days old.
Closing the door
Defences in the order they pay off
- 1
Require confirmed opt-in, without exception
Double opt-in caps the damage at exactly one message per address and keeps unconfirmed entries out of your list entirely. It converts a reputation catastrophe into a nuisance, and it is the single highest-value control here.
- 2
Rate-limit by source and by fingerprint
Cap submissions per source per minute and per hour. Attackers distribute across proxies, and rate limiting still forces cost onto them and flattens the burst enough for the other controls to work.
- 3
Add an invisible challenge
A modern risk-scoring CAPTCHA blocks scripted submission without showing real users a puzzle. Pair it with a honeypot field that humans never see and automated clients reliably fill in.
- 4
Delay and batch the confirmation send
Holding confirmations for a short interval allows a spike detector to suppress the batch before transmission, which is the difference between sending two thousand messages and sending none.
- 5
Add a circuit breaker
An automatic halt on the confirmation stream when submission rate crosses a threshold, alerting a human rather than continuing. The false-positive cost is a few delayed signups; the false-negative cost is your domain reputation.
- 6
Never send content before confirmation
Welcome series, lead magnets, and coupon codes queued at submission time turn one unwanted message into a sequence, and every message in it is another complaint.
The uncomfortable framing is that this is an application security problem that surfaces on a deliverability dashboard, which means it usually falls between two teams. The form belongs to whoever owns the web property, the fallout belongs to whoever owns email, and the controls that prevent it are cheap only if they are built before the first attack. A signup endpoint that accepts unlimited unauthenticated submissions and immediately sends mail on their behalf is, functionally, an open relay with better branding.
Frequently Asked Questions
Does a CAPTCHA alone solve it?
Should we block disposable or unusual domains?
Is the confirmation email itself a compliance problem?
Can our ESP detect this for us?
Key Takeaways
- Attackers script thousands of signup forms against one victim address, usually to bury a transaction notice
- The complaints and trap hits land on your domain, because your infrastructure sent the mail
- Detect on submissions per minute and the submission-to-pageview ratio, not on complaint data that arrives days later
- Confirmed opt-in caps the damage at one message per address and is the highest-value control available
- Add rate limiting, an invisible challenge, and a circuit breaker on the confirmation stream before you need them
Related articles
Half-Year Review: Email in the AI Inbox Era
Six months that rearranged the reading layer: Gemini in Gmail, Microsoft rejecting outright, DMARC finally a standard. What the first half of 2026 means for senders.
Backscatter: The Bounces You Never Sent
When spammers forge your domain as their envelope sender, the bounces come to you. What backscatter is, why it happens, and how to stop causing and receiving it.
Per-Provider Playbooks: Operating Gmail, Microsoft, and Yahoo Differently
The big three score senders differently, expose different data, and fail in different ways. One operating playbook per provider beats one averaged strategy.