Subscription bombing: the distraction is the attack

You come back from a meeting and your inbox has 2,000 new emails. Newsletter confirmations, account welcomes, "please confirm your subscription" messages. None of them are malicious. Each is from a real company, with valid signatures, properly authenticated. Your spam filter let them through because they are not spam.

This is subscription bombing, and the flood is not the attack. The flood is cover for one real email arriving in the middle of it.

What the data actually says

A new paper from EPFL's Mathias Payer and Candid Wüest in Communications of the ACM (15 April 2026) analyses 24 real campaigns totalling 46,970 unwanted emails, collected through the email security provider xorlab in late 2024. The numbers in it are sharper than the usual write-ups.

Volume. The average attack delivered 1,957 emails at 1,516 per hour. The largest wave hit 3,387 per hour. Victims normally receive fewer than 10 emails per hour, so the spike is obvious to anyone watching.

Targets. Upper management. The paper notes victims were "individuals in management positions, director and above, with roles involving external visibility." Their email addresses were either published online or follow obvious patterns (firstname.lastname@company). For an SME the people most at risk are the MD, finance director, and the executive assistant who can authorise things on their behalf.

Timing. Half of all attacks landed on a Friday. Eighty percent started between 8am and 10am, the target's local morning. None ran between 10pm and 7am. The attackers know the working week of the person they are hitting, and they pick the moment people are most likely to clear inboxes quickly without reading.

Filter bypass. 91.7% of the emails passed SPF, 74.3% passed DKIM. More than 70% scored 1 on Microsoft 365's spam scale, the lowest possible score, meaning they would land in the inbox by default. SPF and DKIM are the cryptographic stamps that prove an email genuinely came from the domain it claims; they pass here because the emails really did come from Mailchimp, HubSpot, and the rest. The "this is from a trusted sender" check works exactly as designed, which is the whole problem.

What it's hiding

The paper sets out four objectives. Three matter for SMEs.

A fraudulent purchase or transfer. The paper documents a 2024 case in which a victim later found, buried in their flood, a confirmation for a new iPhone bought on their credit card. Reddit reports include Walmart orders and flight bookings during attacks. The attacker had the payment details already; the flood was there to bury the confirmation email until it was too late to dispute.

A password reset elsewhere. The flood drowns a single real reset notification. The attacker already has enough to trigger the reset; they just need the victim not to notice for an hour.

A follow-up impersonation. This is the one to brief staff on. The paper quotes leaked Black Basta ransomware group chat logs from February 2025, almost verbatim: "I will flood their inboxes with spam, and you will call them pretending to be an IT admin, saying they need to install a spam filter. She installs AnyDesk, and we get in to install our software." Rapid7 documented several real incidents in 2024 using this exact pattern. The flood is the setup; the Teams call or WhatsApp message from "the helpdesk" is the actual attack.

Why defences struggle

This is not a spam-filtering problem. The emails are real, from legitimate senders, with valid signatures. Blocking Mailchimp or HubSpot blocks everyone's newsletters, not just the attacker's. The paper notes that 2FA, zero-trust access, and phishing simulations are all good ideas in general and none of them help here, because the attacker isn't trying to get into the email account. They're trying to get the victim to ignore one email inside it.

The market for this is straightforward. The paper documents publicly accessible services that charge around $1 per 1,000 emails for a standard list and $10 per 1,000 for a "high-quality" list with a better chance of landing in the inbox. Payment is in cryptocurrency. One service the authors examined had executed roughly 300,000 campaigns to date and was running 22.6 new campaigns per hour during the observation window.

What to actually do

For an SME this is mostly a process problem.

Treat a sudden inbox flood as an incident. If a director, finance lead, or EA reports a wave of newsletter signups, stop. Don't bulk-delete and move on. The flood is the signal that something else is being attempted at the same moment.

Check the high-value accounts first. Bank, payment processor, accounting tool, Microsoft 365 or Google Workspace admin, anything that can move money or change access. Look for resets, sign-ins, or transactions in the last hour. The notification you need is in there; the question is whether you find it in time.

Use a second channel for the obvious traps. If "IT" rings during a flood and asks you to install AnyDesk or any other remote tool, hang up and ring them back on the number you already had. If a payment request arrives during a flood, phone the requester. The whole point of the flood is to make the email channel untrustworthy for a couple of hours, so use a different one.

Set up out-of-band login alerts on the critical accounts. Most banks, Microsoft 365, Google Workspace, and AWS can notify you of a sign-in or password reset by SMS or to a separate address. A second channel is the thing the flood cannot drown.

Make your public-facing email patterns less obvious. If your finance director's address is finance@ or firstname.lastname@, expect them to be a target eventually. A dedicated alias for external contact (one that goes via a shared inbox) raises the cost of attack without making the person harder to reach.

The reason this attack works is not that it's clever. It's that the natural human response to 2,000 nuisance emails is to delete faster, not to stop and ask what they're for. If your team knows the pattern, they'll see it the next time it lands.

How Steelwise can help

Working out which accounts in your business need out-of-band alerts, and writing a short playbook for what staff do when an inbox flood starts, is the kind of practical incident planning we run for clients. Get in touch.