A bot used our newsletter form to flood strangers' inboxes. Here is what we fixed.

Short answer: In late October 2026 a bot typed more than 180 strangers' email addresses into our blog's newsletter signup, so our confirmation email landed in inboxes that never asked for it. This is called subscription bombing, and it is usually cover for fraud. It used up our email provider's daily limit and our Friday digest failed. We fixed it the same day with a human check before any email is sent, a two-step confirm, one confirmation per address per day, and a daily cap. Then we moved the site's email to Amazon SES in Sydney.

What happened

On 28 October our blog got seven new newsletter signups. That felt nice. On 29 October it got 70. By 9am on 30 October there were another 106.

None of them were real readers.

A bot was typing strangers' email addresses into the signup form in our footer. Mostly US consumer addresses, with some .gov and .edu ones mixed in. Our form did exactly what it was built to do. It sent each address a "please confirm your subscription" email. More than 180 people got an email from us they never asked for.

It cost us too. Our email provider at the time, Resend, has a free limit of 100 emails a day, and that count includes mail received, not just mail sent. The bot burned through it. When our first Friday digest tried to go out, it failed: 0 of 18 sent. (Three of those 18 turned out to be strangers too, as you will see below.)

Then it got stranger. Three of those strangers ended up fully subscribed. They never clicked anything. The mail-security software at their workplaces opened the confirm link automatically while checking it for danger, and our site took that as a yes.

What is subscription bombing?

Subscription bombing is when an attacker signs one person's email address up to hundreds of newsletters, shops and forums at once. The victim's inbox fills with confirmation emails within minutes. Proofpoint describes bursts of more than 1,500 emails an hour.

It looks like spam. It is usually cover for something worse.

Switzerland's National Cyber Security Centre explained it in February 2026. Attackers who already have access to someone's bank or online shop account make a transaction, then flood the inbox so the one real alert gets buried. Proofpoint reports the same trick used to hide password resets. Microsoft has described attackers flooding an inbox and then phoning the victim, posing as IT support, offering to fix the spam. In the cases it tracked, a ransomware group it calls Storm-1811 used fake support calls like this to get remote access to people's computers.

So where does a small business come in?

Your form is the tool. Attackers need hundreds of legitimate websites that will email any address typed into them, with no check that a human did the typing. Proofpoint notes that bots scan the web for signup forms without a CAPTCHA. Because the emails come from real businesses, spam filters let them through.

You are not the target. You are the delivery truck. But you still pay: your email quota, your sending reputation, and your name in a stranger's inbox on what might be the worst day of their month.

We had two defences already. A hidden "honeypot" field, which is a box humans never see but bots often fill in, and a limit on signups from any one internet address. Neither stopped it.

How to tell if it is happening to you

Look for these signs:

• A sudden burst of signups with no matching rise in traffic, and no new post to explain it.
• Addresses that do not fit your audience. We are a Gold Coast consultancy. A run of US webmail and .gov addresses was a giveaway.
• Confirmations nobody confirms. Real readers mostly click. Bombed addresses mostly do not.
• Quota warnings or failed sends from your email provider.
• "Confirmed" subscribers who never open anything. Some of these are a security scanner, not a person.

If you see two or more of these, check today. Open your signup list for the past week, sort it by date and read the addresses.

The fixes, in order of value

Here is what we shipped the same day, ranked by how much each one matters.

1. Put a human check in front of the email. We added Cloudflare Turnstile to the signup form. It only loads when someone starts typing, and for most people it is invisible. No email is sent until it passes. This is the fix that actually stops the bot, and it is what the Swiss NCSC recommends: verify before you send a confirmation.

2. Make confirming a two-step action. The link in our email now opens a page with a Confirm button. Only pressing the button subscribes. Security scanners open links, but they do not press buttons, so they can no longer subscribe people by accident. A subscription should mean a person said yes.

3. Send one confirmation per address per day. If the same address is entered again, nothing is sent. A victim gets one email from you at most, not ten.

4. Cap the whole site. We now send no more than 30 confirmation emails a day across the site. If something ever gets past the other checks, the damage stops at 30, and your booking emails and newsletter keep working.

5. Clean up the list. We removed 184 bot signups and unsubscribed the three addresses that scanners had confirmed. That left 15 real subscribers. A smaller list, but an honest one.

Keep your honeypot and your per-address limits. They are cheap. They are just not enough on their own.

Once the signup was safe, we audited every other form and connection point on the site. We found two more weak spots. Another form's human check could be skipped, and an old endpoint we no longer used had no login. Both are closed. If one form has a gap, assume others might too, and go and look.

Changing email providers, and why cheaper was not the reason

While investigating, I read Resend's acceptable-use policy properly. As of October 2026 it bans cold outreach outright. So does every transactional email provider we checked: Amazon SES, Cloudflare Email Service, Postmark, SMTP2GO, Mailgun and Brevo. I wrote up the full comparison, with prices and how to choose for your own site, in Choosing an email provider for a small business site.

That changed the question. It was never "which provider lets us send outreach", because none of them do. It was "which mail belongs where".

One-to-one outreach is a person writing to a person, so it now goes from my own Google Workspace mailbox. The site's own email, meaning booking confirmations, the weekly digest and signup emails, needed a proper home of its own.

We moved that to Amazon SES in the Sydney region. Yes, it is cheaper. At 5,000 emails a month it costs about US$0.50 on SES, against US$20 for Resend Pro. But the policy and the fit mattered more. We also looked at Cloudflare's email service and ruled it out, because it is in beta and only allows transactional email, which means no newsletters.

Setup took an afternoon:

• Verify the domain with DKIM. DKIM is a digital signature that proves an email really came from your domain.
• Set a custom MAIL FROM domain. This makes the behind-the-scenes return address your own domain rather than Amazon's, so the checks line up.
• Create a configuration set that suppresses bounces and complaints automatically. If an address bounces or someone marks you as spam, you stop mailing them without having to remember.
• Create a send-only user. The website's credentials can send email and do nothing else.
• Request production access. New SES accounts start in a test mode. Amazon granted ours within hours.

Two lessons we did not expect

Passing every check does not get you into the inbox. Our first emails from SES landed in Gmail spam, even though SPF, DKIM and DMARC all passed. Nothing was misconfigured. We were simply a new sender, and new senders have no reputation yet. The digest went out through SES anyway: our system retries a digest that failed completely, so it went out minutes after we switched. 15 sent, 1 bounce, which was suppressed automatically. We are now warming up with booking emails, because people expect them and open them, and that is what builds a good reputation. If you switch providers, plan for a warm-up period before you send anything in bulk.

A missing slash can hide a broken connection for days. A webhook is a message one service sends another when something happens, such as "this email bounced". Ours had failed silently for six days. The address we gave the email service was missing a trailing slash. Our site redirects those addresses to the version with a slash, and webhook senders do not follow redirects. So every message went nowhere. Every webhook needs the exact final address. Paste it into a browser and check the address does not change when the page loads.

What to check on your site this week

Ask yourself one question: how many forms on my site will send an email to whatever address someone types in?

Newsletter signup. Contact form. Quote request. Booking. Password reset. Each one is a possible delivery truck.

The smallest experiment is ten minutes long. Open your newsletter list, sort by signup date, and read the last 50 addresses. If they look like your customers, good. If they do not, you now know exactly what to fix, and none of it is expensive.

If you would like a second pair of eyes, book a free 1-hour consult. We will go through your site's forms and email setup together and leave you with a short list of fixes. Your forms should work for your readers, not for someone else's scam.