How should we contain an active subscription-bombing attack?
Severity: HighPause sending: Pause conditionally
Quarantine the signup cohort created after the suspected attack onset before it enters campaigns, because fake signups can corrupt audience data and harm list quality and deliverability. Protect the signup endpoint with baseline-derived rate limits, human or browser challenges, and confirmation gating. Do not delete unreviewed contacts; preserve legitimate consent and abuse evidence under the organization's retention policy.
First 15 minutes
- Quarantine contacts created after the suspected onset and segment them by signup time and source for review.
- Apply a rate-based rule scoped to the signup endpoint using thresholds derived from the legitimate signup baseline.
- Check whether the hosted platform has already throttled addresses repeatedly added to multiple audiences in a short period.
Now
- Quarantine the attack-era cohort, segment it for review, and retain consent and abuse evidence.
Next 24 hours
- Enable or repair human challenges and honeypot controls, and require confirmation gating before a submission becomes subscribed.
Next 7 days
- Tune signup-endpoint rate limits from legitimate traffic baselines and test aggregation keys for shared-network impact.
Technical checks
Engineering
- Measure normal signup traffic and test scoped WAF aggregation keys before enforcing a rate-based rule on the signup endpoint.
Marketing / CRM
- Confirm that the current form code enables the documented reCAPTCHA and honeypot controls, or that custom API flows have equivalent protections.
Verification criteria
- Verify that the scoped rate rule and human or browser challenges reject bot-like submissions without blocking the legitimate signup baseline.
- Confirm that submissions do not become subscribed until confirmation succeeds and that only reviewed spam records are deleted.
Escalation criteria
- Escalate to security and the form or WAF owner when the attack bypasses the tested aggregation keys, or when confirmation volume and business impact require a broader pause.
Prevention
- Keep human-interaction and honeypot controls enabled with current form code, or equivalent controls on custom API signup flows.
- Use confirmation gating and baseline-derived endpoint rate limits rather than a universal threshold.
Business impact
- A large fake-signup cohort can distort audience statistics and degrade list quality and deliverability.
Provider notes
- Mailchimp can throttle one address added to multiple audiences in a short period for 24 hours, but that hosted behavior is not a universal ESP control.
Open questions
- The attack onset, targeted addresses, signup endpoints, request distribution, confirmation volume, and proportion of legitimate signups are not provided.
- Hosted forms, embedded forms, custom APIs, ESP throttling, WAF aggregation keys, and confirmation workflows vary; Mailchimp and AWS controls are scoped examples.
Sources (6)
- About Fake Signups — What are spambots?Mailchimp
- About Fake Signups — How we prevent it > ThrottlingMailchimp
- About Fake Signups — How we prevent it > ReCAPTCHA and Honeypot fieldsMailchimp
- About Double Opt-in — How double opt-in works and Customize the double opt-in processMailchimp
- Using rate-based rule statements in AWS WAF — Rate-based rule overview and scope-down statementAWS WAF
- About Fake Signups — How to delete spam signupsMailchimp
