How I set up an email list without becoming a spammer — or the product.

I put off email for a long time. Out of everything in this fleet, it’s the part that scared me most — deliverability, blacklists, DKIM, the feeling that one wrong move quietly poisons your reputation and you don’t find out for weeks. Standing up a website is forgiving; you can see it work. Email fails silently, in someone else’s spam folder, and that’s a different kind of fear.

So this is the story of getting over it in two steps — a small safe one and a bigger one I chose not to take — and it’s also the clearest example yet of what working with an agent on real infrastructure actually feels like: it made one genuinely dangerous mistake, and it talked me out of a worse one. Both were useful. You have to be able to receive both.

The dumb limit that forced my hand

I have a lot of domains. I did not have a professional way to receive mail at any of them, and the obvious fix — a Gmail account per project — hits a wall fast: Google caps you at around ten accounts, tied to phone verification. For a tinkerer with two dozen domains, ten is a joke. I wasn’t trying to run a mail empire; I just wanted hello@ at each project to go somewhere I’d actually see.

So I asked the agent the smallest, safest version of the question: can I at least self-host a contact address per domain, forwarding to the inbox I already use?

Yes — and this is the right thing to self-host

This part is genuinely fine to run yourself, because receiving and forwarding a trickle of mail is a solved, low-risk problem. Postfix to accept it, Dovecot to serve it, OpenDKIM to sign it, and a per-domain alias that forwards hello@thebrand.com to my normal inbox. The mental model is worth internalizing, because the next decision hinges on it:

CONTACT MAIL — a trickle, safe to self-host
  *@daemonmoney.com  ─►  my Linode (Postfix/Dovecot)  ─►  my everyday inbox

THE LIST — bulk sending, do NOT self-host  (see below)
  signup on the site  ─►  a paid service  ─►  subscribers
                                └─ notifies ─►  my everyday inbox

It worked on the first real try. But the how is where the agent earned its keep — by getting it wrong first.

The mistake: one username, two brands, crossed mail

Every brand on my server runs as its own user, and mail was being delivered by bare username — so hello@ at any of my domains resolved to whichever Unix account was named hello. The problem: a hello account already existed. It belonged to another brand on the same box. When the agent wired up hello@daemonmoney.com, it quietly pointed a second brand’s contact mail at the first brand’s mailbox. Two projects, one inbox, no error message.

This is the real texture of directing an agent on production: it will do the wrong thing confidently, in a way that looks completely right, because the command succeeds. Nothing throws. The safeguard isn’t a smarter agent — it’s you, holding the context the agent doesn’t, asking the one question that doesn’t fit. My whole contribution to that fix was remembering that another project already lived on that box.

The bigger question — and the most useful “no” I got

Contact addresses working, I asked the obvious follow-up: now can I collect and send a mailing list from my own server too?

The agent said no. Technically possible; genuinely a bad idea. And that “no” was the single most valuable thing it did in this whole arc.

Forwarding a trickle and broadcasting to a list are not the same activity wearing different hats — they’re different universes. Bulk sending is a reputation discipline: a fresh server IP has no sending history, so Gmail and Yahoo treat it with suspicion by default; the 2024 bulk-sender rules demand aligned SPF, DKIM, and DMARC, one-click unsubscribe, and a spam-complaint rate under a razor-thin threshold; you need bounce handling, list hygiene, and feedback loops. Get any of it wrong once and you don’t just lose a campaign — you blacklist the same IP that sends your personal and contact mail. A good collaborator tells you when the smart move is to not build the thing.

The cheap route makes you the product

So: use a service. And here’s where I almost made the classic mistake — I went hunting for the cheapest one, on reflex, and caught myself. For something as reputation-critical as the audience list this whole site exists to build, “cheapest” is the wrong axis, because at the free end you are the product. A service that costs you nothing monetizes you some other way — your data, your list, their branding stapled to your mail, your deliverability quietly deprioritized behind customers who pay.

I’d rather pay a company whose product is getting your mail delivered, because then our incentives point the same direction: they win when my email lands, not when my attention gets resold. I picked Buttondown. I’ll be honest about the tradeoff — its free tier caps at 100 subscribers, which is, on pure economics, the worst deal among the obvious options. I chose it anyway, for the ethos and the simplicity, and because I’d rather start by paying for alignment than save twelve dollars becoming inventory. (It sends as hello@daemonmoney.com using the domain I already own, with its own DKIM — receiving and sending both wearing my name.)

What “not a spammer” actually requires

The mechanics that keep you on the right side of the line, none of them optional:

• Double opt-in. The one setting that matters. Nobody joins the list without clicking a confirm link, so every address is a real person who asked. It protects your reputation and your conscience.
• A real physical mailing address in the footer. CAN-SPAM requires it on bulk mail — this is what the PO box is for. No, you don’t put your home address on the internet; yes, you need an address.
• One-click unsubscribe, honored instantly. Making it hard to leave is how you earn spam complaints, which is how you get throttled.
• Authenticate your sending domain — and mind the landmine: SPF must be a single TXT record. If you already have one, you merge the new service’s include: into it. Two separate SPF records and neither one validates.

The proof

Here’s the whole thing closing the loop — a test subscription from another address of mine, and the notification landing in the exact inbox I already live in, on my own server, next to everything else:

That’s the arc: the thing I was scared of for years turned out to be two decisions, not one — a small risk worth self-hosting, and a bigger one worth paying someone else to carry. The agent helped me take the first and, more importantly, helped me not take the second.

Next in the log: the mascot in the margins. I didn’t hand-draw Nohup and I didn’t hand-train him either — I directed an agent to, and watched a photoreal man in a suit slowly turn into a little green daemon.