A newsletter should be harder to send than to write

This is the first issue of a newsletter that exists because we needed a place to say things longer than an email and shorter than a deck. Before sending it we did the boring research, and two findings are worth writing down, because they changed the build.

One: unsubscribe is a header now, not a link in the footer

RFC 8058 defines one-click unsubscribe: a List-Unsubscribe header carrying an HTTPS URI, plus List-Unsubscribe-Post: List-Unsubscribe=One-Click. A mail client can then remove somebody without them visiting a page, hunting for a link, and filling in a form.

The RFC is specific in ways that matter to the implementation:

• the URI should contain an opaque, hard-to-forge component — so we mint a signed token per

mailbox rather than trusting a plain email in a query string;

• the POST must not redirect, so the endpoint answers it directly;
• the message must carry a valid DKIM signature, or a client should not offer the one-click at

all.

This is not politeness. A recipient with no easy unsubscribe does not stay subscribed — they report spam, and a complaint damages a sending domain in a way an unsubscribe never does. Making it easy to leave is the cheapest reputation insurance there is.

Two: our authentication was already fine, so that was not the risk

We read our own DMARC aggregate reports instead of guessing. Across six recent daily reports for ngari.ai, there were 45 message records with SPF passing 45/45 and DKIM passing 45/45. No failures, no unknown senders.

That is genuinely good news, and it reframed the problem. If the records were broken we would fix records. They are not. So the risk is entirely volume, cadence, list quality and complaints — which is a design problem, not a DNS problem. Hence:

• One mail per person per week, at most. A blog can publish twice a week; a human can only be

written to once.

• A daily cap that ramps. 25, then 50, then 100. A domain that suddenly sends nine hundred mails

looks like a spam run to every filter that watches rate of change, even when the list is legitimate.

• A send window. A 3 a.m. mail is a mail that gets marked junk by a phone notification.
• Suppression before selection. Hard bounces, unsubscribes and complaints are excluded before a

plan is made, not after a failure.

What we learned from the two models worth copying

Substack's real advantage is not the editor. It is that every post is also a send, every send has a canonical web copy, and the archive is a discovery surface. So a post is a page and a mail at the same URL, and the RSS feed is the same content again. One piece of writing, three ways to meet it — and no separate newsletter product to maintain.

Google Groups' advantage is that it never pretends to be a person. The list has a name, an address, an archive, and a reply goes to the list or to the sender depending on how it was set up. The failure mode — a list that looks like a personal email and behaves like a broadcast — is exactly the shape that teaches people to distrust bulk mail. So every issue here carries List-Id, Precedence: bulk, and a List-Unsubscribe that works, and says plainly why you are receiving it.

What we will not claim

We will not tell you this lands in your primary inbox. We cannot control that, and anyone who says they can is selling something. What we can do is remove every mechanical reason to treat this as bulk, keep the list clean, send at a human pace, and publish what we measured. The limits page has the same rule for the product: say what it does, and say what it does not.