Someone Used My Email Platform to Run Phishing Campaigns

For months, the hardest problem with Posthawk was getting anyone to use it at all. It is self-hostable email infrastructure built on top of AWS SES, the kind of product that only gets noticed when it breaks, and for a long time the dashboard sat at a flat zero.

Then one week the numbers moved. New signups every day. Domains getting verified. Real sending volume showing up where there had never been any. I let myself believe it. This was the turn. People finally wanted the thing I made.

Then I looked closer at one of the busy accounts.

It was sending phishing emails to employees at a large company. Not spam in the annoying-newsletter sense, but targeted, credential-harvesting mail dressed up to look like internal correspondence. My platform, my sending reputation, my AWS account, all pointed at real people who had done nothing to deserve it.

I suspended the account. The next day a new one appeared with a fresh domain, doing exactly the same thing. I suspended that one too. Another came back. Every time I killed one, another showed up wearing a slightly different costume. The traction I had been so happy about was, in large part, one determined person cycling through domains faster than I could review them.

Why this is not a minor problem

If you have never run a sending platform, it is easy to file this under nuisance. It is not. It is closer to someone lighting fires in a building you share with all of your customers.

Email deliverability runs on sender reputation, and on a shared platform that reputation is pooled. When one account blasts phishing mail from your infrastructure, mailbox providers and SES do not carefully separate the bad actor from everyone else. They see the platform. Spam complaints, spam-trap hits, and blocklistings land on the shared sending identity, and they can drag down inbox placement for every legitimate customer at once. Left unchecked, it can get a whole platform throttled or cut off from SES entirely.

For an established provider, that is a bad week. For a bootstrapped one-person company, it can be the end. The phisher was not really stealing my time. He was holding a match next to the one asset the whole business depends on.

The half of the product I did not want to build

I had a roadmap that week, full of features I wanted to ship. Instead I spent it building the half of an email platform that never makes it into a launch thread: abuse defense.

I am going to stay deliberately vague about the exact rules, because publishing your detection logic just tells the next attacker how to route around it. But the general shape is worth sharing for anyone building in this space.

• •Screen domains at verification, not after they send. A brand-new domain with no history, registered hours before it starts blasting mail, looks measurably different from an established business domain. That difference can be scored before a single email goes out.
• •Close the easy doors at signup. Abusers gravitate toward disposable and throwaway inbox providers because they are free and effectively unlimited. Real users almost always arrive with a work address or a mainstream personal one. A signup policy that reflects that removes a large share of low-effort abuse up front.
• •Make a ban outlive the account. When you remove a bad actor, keep the fingerprints of how they operated, so the same person returning under a new name and a new domain gets caught earlier. The goal is not to win every round. It is to make each new attempt cost them more than it costs you.

None of this is glamorous. You cannot screenshot a blocklist for a launch post. But it is the difference between a platform that survives contact with the open internet and one that quietly gets poisoned by its first serious abuser.

What I actually learned

I used to think of trust and safety as something you bolt on later, once you are big enough to have a team for it. That is backwards. On a platform that sends on behalf of other people, abuse defense is not an add-on to the product. It is load-bearing infrastructure, in the same category as the queue and the database.

My first real taste of usage at volume was an attacker, and if I had not been able to respond, he would have taken the platform down without ever meaning to. The traction spike turned out to be mostly fake. The lesson did not, and honestly it made the product better.

If you are building anything that puts email in the world for other people, build the defensive half early. You will meet your phisher a lot sooner than you expect.