Every email any of our publications sends goes out through one path we built, from the publication's own domain, with nothing in it that reports back to an advertiser. That sentence took longer to make true than any other in this series.
Why email is different
A website is one thing you build once. Email is a relationship with every inbox provider on earth, and each of them decides, message by message, whether you are a publisher or a spammer. Get the domain records wrong and a welcome email silently disappears. Send from an address that does not match a verified domain and the whole day's mail bounces. On WordPress this was handled by a plugin nobody understood, and when it broke nobody knew.
So we built one sending architecture and wrote it down before we touched anything, because our first attempt at it, on April 20, went wrong in a way worth describing. A welcome email failed with a "domain not verified" error. We guessed the signing records were in the wrong place and moved them on three domains, which undid a correct configuration and broke the other two. The actual fault was a sender address in the code that did not match the verified domain. The fix was to correct the address and put the records back. The written architecture exists because of that afternoon. It is the reason every domain since has been onboarded from a checklist rather than from memory.
What it does
One send path, for every publication, on the platform itself. When a reader subscribes to The Charlotte Mercury, the welcome email comes from The Charlotte Mercury's own domain, signed by it. When they subscribe to Strolling Firethorne, it comes from Strolling Firethorne. The publication record holds the from-address, the sender name and the reply-to, so a new publication gets its own email identity the day it gets its domain.
Every send is deduplicated, so a reader who subscribes twice gets one welcome. Every unsubscribe works with one click, the way modern inbox providers require. Every send is logged, so when someone says they never got the email, we can look.
On top of that path sit the things a newsroom actually sends. A daily brief that assembles itself from the day's coverage and goes out at seven in the morning. Welcome sequences per publication. Newsletters for our partner publications, sent from their own subdomain so their reputation is their own. Event confirmations with a code the venue can scan at the door.
The sending itself runs through Resend, a transactional email service. That is the one piece we rent, deliberately, because deliverability is a full-time relationship with the inbox providers and it is not the business I am in. Everything above it, the templates, the identities, the logging, the rules about when a send is allowed to happen, is ours.
What is not in it
No tracking pixel that reports to an ad network. No open-rate scoring sold to anyone. No third-party list. The same position I took on cookies a year ago applies to the inbox: we do not build surveillance into the thing we ask a reader to trust. We can see whether our own mail was delivered and whether the link in it was followed, on our own system, and that is the whole of it.
The rule that came out of it
A send is a publishing act. It goes through the same approval as an article and it does not go out because a clock said so. We learned that one the hard way, too, and the rule now is that timed sends are scheduled and approved inside our own system, never by the vendor's scheduler. A publication should never be surprised by its own email.
That is the standard we hold every send to: if it reaches a reader, we should be able to say why it went and who approved it.
This is No. 04 in We Built Our Own. Previous: The day we deleted the media server. Next: The newsroom tool we built for ourselves.