The Friday Deploy

The plain English newsletter for people who run the business, not the tech stack. No jargon. Every Friday.

How Bots Contaminate Your Mailing List Without Triggering Any Alarms

May 8, 2026

There’s a particular kind of mistake that’s easy to make when something goes wrong with your website. You see a problem, it looks urgent, and you start fixing it. The work is real, the solution is technically sound, you feel like you’re going to kick a goal today.

And then you realise you’ve been solving the wrong thing. You were patching the roof while the pipes were leaking.

What we saw

We had CSRF token verification failures appearing on a newsletter signup form. The first assumption was simple: real users were having trouble subscribing. We dug in, and that turned out to be wrong. The requests were automated. Bots, not people.

Once we knew it was bots, we looked at what else was hitting the site. There were real attacks happening in parallel: automated probes on the search field, SQL injection attempts. So we did what made sense: we grouped the bot activity together, specced out rate-limiting to throttle the requests, and started looking at banning the offending addresses.

Then someone looked at the mailing list.

The problem that wasn’t making any noise

In Mailchimp, there were garbage addresses. Fake emails, clearly bot-generated, already sitting in the subscriber list.

The aggressive bots we’d been focused on had never successfully subscribed. They were failing on the token check every single time. Loud, visible, completely harmless. The system was working exactly as it was designed.

The quiet bots were a different story. They were behaving politely. Valid tokens, clean requests, no alarms. They completed the form, passed all the checks, and landed straight in the list. We hadn’t noticed them because they weren’t generating any noise.

The mailing list contamination was collateral damage in their operation. But that doesn’t make it harmless. Fake addresses sitting in your list drag down every metric you use to measure whether your email marketing is working: your deliverability, your open rate, your click-through rate. The list looks bigger than it is, and your numbers look worse than they are. You end up making decisions based on data that doesn’t reflect your actual audience. If you find your list is full of bots, cull those addresses. Your list size will drop, but your KPIs will go up.

Rate-limiting would have done nothing to fix this. The real problem wasn’t too many requests. It was that well-behaved bots looked identical to real subscribers.

The actual fix was a honeypot field. This is a form field that’s invisible to human users but that bots fill in automatically. Any submission that includes a value in that field gets silently dropped. Simple, effective, and completely unrelated to everything we’d been investigating.

What this looks like from the outside

If you’re watching this kind of investigation from a distance, it can be confusing. Your developer spends time going deep on a problem, then changes direction entirely. Was that work wasted?

Not necessarily. The analysis was sound. Rate-limiting would have been the right fix for what we were looking at. But the course correction happened because we stopped and asked a different question: what is the actual business problem here?

The answer wasn’t “too many bad requests to the endpoint.” It was “good requests are filling our mailing list with fake addresses.” Those are different problems with different solutions.

The moment we looked at the mailing list instead of the logs, the diagnosis changed completely.

What to take from this

The question that broke this open was simple: is anything actually getting past this point?

Bots hammering your endpoint with invalid tokens, SQL injection probes bouncing off your search field. That’s rain. Annoying to see in the logs, but it’s not doing anything. Most of it never gets through. The internet is full of automated noise and always will be.

What you’re looking for isn’t rain. It’s leaks. The places where something is actually getting in and causing damage. In our case that was the mailing list. It was quietly filling up with fake addresses, dragging down deliverability, distorting every metric used to measure whether the email marketing was working.

Nobody had looked there because nothing was making any noise. The assumption was that anything which made it through the form was legitimate. That assumption was wrong, and it went unquestioned until someone asked: is anything actually getting past this point?

Next time something noisy shows up in your logs, make sure you’re solving for the leaks, not the rain.

Read more Technical Translation

Debugging, Ecommerce, Software Development, Technical Delivery

Previous Next

The Friday Deploy

The plain English newsletter for people who run the business, not the tech stack. No jargon. Every Friday.