The Canary in My Inbox
It had been a long day at work. I had dinner, sat around with a drink, and started surfing for some piece of plumbing for my fountain. On the way to whatever search I was about to do, I clicked the MailTaste bookmark. No real reason. Just curiosity. Let me see what's up.
First impression: clean. The block counters from ninety days ago, gone. Failed authentication down to a trickle. Looking good.
Then I scrolled.
The volume was wrong
Volume up. Way up.
The dashboard you see when you first arrive at mailtaste.esoup.net is live data from my own domain. I drink my own champagne; the demo IS real data, and it was telling me something I had not been doing: my domain was sending a lot more mail than it should have been.

My first guess was family. One of my sisters runs a small mailing list. Mom occasionally fires up something quaint. Maybe somebody had picked up the pace.
MailTaste is more specific than that, though. I clicked through and asked which domain was driving the volume. It came back with one answer: box.esoup.net. My QR-code service. Somebody using my own little app.

For about three seconds, I was excited. Look at that. Someone found it useful.
Then I read the logs.
All the wrong recipients
Random six-letter .com domains. Disposable. The kind that get registered, used once, abandoned. I was not going to click any of them. I did not need a closer look at where my own infrastructure had been pointing people. I just needed to know what shape this was.
I pulled out my Claude Code session — the PAI infrastructure I run as my AI partner — and gave it the box.esoup.net source tree along with the MailTaste graph. Tell me what you think is happening here.
It came back with what I already suspected.
Sorry Ian. It's not popular. It's being abused by a bot.
A small tick from somewhere inside me — the sound glass makes when it cracks but hasn't shattered yet. Not catastrophic. A quiet damn bots. I had built box.esoup.net with one operational goal beyond the QR-code work itself: friction-free. No captcha, no signup gate, just type in your URL and get a rewritable code. The whole point was speed. The friction-free choice was now the thing on fire.
The trap I had set for myself
I had done the email thing right. DMARC published with a hard reject policy. SPF authorized. DKIM signing. All three records in DNS, all three saying block any mail claiming to be from this domain that does not pass authentication. That stack works. It really does.
And then I opened a door through one of my own applications, and the bot walked through using my own authenticated mail, sent by infrastructure I had legitimately authorized. Every message had perfect SPF, perfect DKIM, perfect DMARC alignment. The world's mailbox providers delivered every one of them straight to the inbox. Because the protocols said yes.
The protocols were doing exactly what I had asked them to do.
That is the line I would not have predicted before this happened: protocol correctness is not visibility. If the abuse rides on top of authenticated mail flowing through your own app, every DNS record you have published will agree the mail is fine. The only thing that disagrees is the volume.
What we did
Stop the bleeding first. I killed the abused endpoint immediately, the source patched within the hour. Then I pointed PAI at the bigger question: what is the smallest set of layers that turns this attack class into background noise?
Working together across that evening and the next morning, we rotated the database passwords, verified the operating system itself had not been compromised, walked the code path from request to outbound mail to find the actual exploit shape, and designed a small set of friction layers the bot economy cannot afford to clear. Proof-of-work on submission. An email round-trip before anything actually sends. A stealth response on the probing routes so the bot learns nothing about what worked.
The bot had been running for about ten days. Eight hundred and sixty rows ended up quarantined. The graph has flattened since the friction went in. They will probably come back. They will probably come back with friends. Now I know to check more often.

I am not going to pretend I did this alone. An LLM partner that can read the code, run the queries, draft the migrations, and argue with me about each layer compressed what would have been a week into one long evening. That is the actual story of how it got fixed quickly.
Because they can
If you're wondering why anyone would bother targeting a small QR-code service nobody has heard of — wrong question. The right question is what's stopping them? Nothing — because they can. The bot economy doesn't care that my site is small. It cares that my site is reachable.
Honest aside on impact: a small number of people received spam that, technically, came from me. If that was you, sorry. I am not doing a full apology. Shit happens, and I shipped the fix fast. But I do owe you the whoops.
The friction I added is not fun, and I will not pretend otherwise. I hate the modern security workflow as much as the next person — authenticator apps, six-digit codes, email loops, all the price of doing anything online. I had tried to stand in front of that with something cleaner. The workflow felt tight. Then a firehose hit it. Rolling your own security is, as a class, a bad idea. I keep relearning that.
The canary I almost missed
I built MailTaste because DMARC reports are unreadable XML and I wanted to actually look at my own mail flow. I built it for myself first. The front page is my real data because I'd rather drink my own champagne than gate a tool behind a signup wall.
When I built it, the signal I was looking for was failed authentication. Spoofing attempts. Third parties trying to impersonate me. The thing that caught the bot was none of that. It was a line going up.
Legitimate mail volume has to equal success. That assumption was wrong.
Nothing else could have told me. The logs on box.esoup.net would have shown the requests, but I wasn't staring at them at 8pm on a Wednesday. The mailbox providers wouldn't have complained, because the mail authenticated. My DMARC reports wouldn't have flagged anything, because nothing was failing. The only thing that disagreed was the shape of my own outbound volume.
MailTaste itself was never the problem. It exposed the issue, the same way a smoke alarm exposes a fire it had nothing to do with.
If you have a domain
One thing this story does not give you is a solution to the volume problem.
The detection mechanism was my eyeball on a dashboard at the right moment. That's not a strategy. The volume-spike-as-canary worked because I was looking; it doesn't extend to people who aren't. My personal answer is telemetry on everything, possibly more than I need, plumbed into alerts that fire when the shape changes. LLM-paired work and modern tooling (Postgres, TypeScript, Bun) have made running that kind of detail effectively free in 2026. That's a stance, not a recommendation. MailTaste doesn't emit traces to its users today, and I'm not promising it will.
What MailTaste does give you is a place to look at your own mail flow when you have not been looking. If you own a domain (your name, a side project, something you bought a decade ago because it seemed cool) and haven't set up DMARC, SPF, and DKIM correctly, somebody else's bot can claim to be you and a real fraction of those messages will land in inboxes.
This isn't an enterprise problem. Enterprises have entire teams chasing it. It's a mom-and-pop problem, and most mom-and-pops don't know they have one.
MailTaste is free. The front page demo is my real data, trust but verify, and the service is for anyone with a domain. Point your DMARC reports at it. Find out what's leaving your house.
The bot didn't target me because I'm important. It targeted me because I was reachable. So are you.
Related reading: - MailTaste: Finally Understanding Who's Sending Email as You - Own Your Email, Own Your Future