Key takeaway
An email newsletter is a recurring email sent on a stated schedule to people who subscribed to it, which is what separates it from a broadcast aimed at a segment. The thing you're running isn't the issue, it's the subscription: a standing permission with a cadence, a consent record, and a working unsubscribe. Templates are the easy part. I'd ignore "aim for 30% opens" on a list nobody has seen and watch the 0.30% complaint ceiling instead.
We have real newsletter emails in the library, with what each one is doing written next to it.
What an email newsletter actually is.
An email newsletter is a recurring email sent on a stated schedule to people who asked for it, carrying content they expect rather than an offer they didn't. That definition is correct, and it's the one every guide on this topic opens with. What it leaves out is that the newsletter isn't the issue you send. It's the subscription behind it. What you're running is a standing permission with a cadence attached, and this week's email is only the current instance of it. Search for how to make one and you get templates, examples, and a numbered sequence that starts at "choose a platform". Almost all of that advice describes how to produce an issue. Very little of it describes how to run the thing that produces issues, which is where a newsletter is won or lost.
The definition also says nothing about who's allowed to be on the list, what happens when the schedule slips, or what the mailbox providers now require of anybody sending in bulk. All three decide whether next week's issue arrives at all, and not one of them is a design question.
Newsletter, broadcast, and flow are three different sends.
"Newsletter", "email campaign", and "email marketing" get used interchangeably across most of the advice on this topic, and they describe three different sends with three different footings. What separates them isn't the content, the length, or the template. It's what starts the send, and what the person on the other end agreed to when they handed over an address. Sorting that out first is what makes every later decision, from cadence to suppression, straightforward.
- Newsletter: recurring, scheduled, and sent to everyone who subscribed to it, so what the reader consented to is the rhythm as much as the content.
- Broadcast: a one-off send to a segment, started by a person or a date, and judged on what it produced rather than on whether anybody wants the next one.
- Flow: started by something a contact did rather than by the calendar, so it arrives once per person and never lands as a schedule at all.
Nitrosend sends all three, and builds flows with triggers, steps, and branches. The distinction is operational. It sorts sends by trigger, not by obligation, and a newsletter that quietly fills up with offers is a broadcast wearing a newsletter's consent. That's the most common way a list somebody built honestly starts generating complaints.
What a subscription owes before issue one.
Bulk senders have entry requirements now, and they're written down. Since 1 February 2024, Google has required senders of more than 5,000 messages a day to Gmail accounts to authenticate with SPF and DKIM, publish DMARC on the sending domain, include a clearly visible unsubscribe link, and support one-click unsubscribe on marketing and subscribed mail. Yahoo asks for the same authentication and adds a clock: unsubscribes honoured within 2 days. A newsletter crosses that threshold sooner than its author expects, because the daily volume is the list multiplied by a cadence somebody picked months earlier.
Both providers put the spam-complaint ceiling at 0.30%, and Yahoo calculates its rate against mail delivered to the inbox rather than against everything sent. That isn't a best practice with a nice-to-have attached. It's a limit with enforcement behind it, and it's the one newsletter number where crossing the line changes what happens to the next issue. One-click unsubscribe is worth knowing precisely, because it's a protocol rather than a button: the message carries a List-Unsubscribe-Post header holding List-Unsubscribe=One-Click, the mailbox provider unsubscribes by sending an HTTPS POST, no confirmation page is allowed, and at least one valid DKIM signature has to cover both headers.
Consent sits underneath all of it, and it isn't a checkbox. The standing position of the sending industry is that confirmed opt-in is the highest standard, and that a sender should tell people at signup how often it plans to send, because an unexpected jump in frequency is what produces complaints. The requirement a first newsletter forgets most often is duller than either: an unsubscribe that works on the first click, on every send, including the one you wrote at midnight.
Setting one up, in seven steps.
Here's the sequence, in seven steps, and step one isn't "choose a platform" and isn't "pick a template". Both of those are real decisions and neither is the first one. I've watched more newsletters die of an unstated promise than of a bad template. What comes first is the promise, because everything downstream, from cadence to list hygiene to what you're allowed to send, is a consequence of what you told people they were signing up for.
- Decide what the subscription is for. One sentence, in language a subscriber would recognise. If you can't write it, the newsletter doesn't have a job yet.
- State the cadence at signup and put it on the form. Weekly, fortnightly, or monthly, in the words the reader will hold you to. That's the promise being made.
- Pick a sender you can drive the way you work. A builder, an API, an agent, or all three. It's one decision, not a research project.
- Set up email authentication before the first issue. SPF, DKIM, and DMARC on the sending domain, done in advance rather than in a hurry after the first delivery problem.
- Collect addresses with confirmed opt-in, and never buy a list. This is the step that decides every number you'll be looking at in month six.
- Build the issue against one job. One thing you want the reader to know or do, and a template that stays out of the way of it.
- Send, then read the complaint and unsubscribe rates first. Before the opens, before the clicks, before anything else.
Seven steps gets issue one out the door. Issue forty is the same seven steps run as a repeatable job, and by then the interesting question isn't how to do them. It's which of them still needs a person. The payoff for getting step one right shows up in numbers most newsletters never see: Hyggekrog, a solo operation with the founder writing every issue personally, runs a 90% open rate and 32.94% click rate.
Running a newsletter as a job, not an issue.
Strip the ritual out of a weekly newsletter and what's left is a query, a template, a schedule, and a send. The audience is a segment that recomputes. The issue is a versioned document. The cadence is a trigger, and the send is a request. None of that inherently needs a person clicking through a builder on a Tuesday morning, and yet that's how nearly every newsletter in the world goes out.
That's the thing Nitrosend is built around: run your whole email stack from one agent command. We're MCP-first, so every capability is an API endpoint and an MCP tool before it's a screen. An issue can be drafted, segmented, checked against the suppression list, and sent from the same place the rest of the work already happens, with no window to open and no button to hunt for. Contacts are unlimited on every plan, including Free, and BYO sending keys on Pro and above cover Amazon SES, Resend, Postmark, Mailgun, and SendGrid.
I've been building email platforms for over a decade, and the pattern is consistent. A product designed dashboard-first and then fitted with an assistant hands you a chat window bolted onto a builder, which is bolting a motor onto a bicycle. It shows up worst on the send you repeat fifty-two times a year.
The honest half is that an agent doesn't decide whether this week's issue is worth sending, and it doesn't make an unwanted list wanted. It takes away the clicking, which was never the part that made the newsletter good.
The numbers that survive.
A newsletter produces four kinds of number: delivery, engagement, list health, and complaint. They tend to get taught in that order of glamour, which is close to the reverse of the order that matters.
The open rate is the number this topic hands you first, and it's the one to trust least. Apple's Mail Privacy Protection pre-fetches remote content in the background rather than at the moment somebody reads a message, so an open can be recorded for an email nobody looked at. That doesn't make the number useless, but it does make it a trend line rather than a measurement.
What answers whether the issue worked is the click rate against the one job the issue had. What answers whether you get to send the next one is the unsubscribe rate, the email bounce rate, and the complaint rate, and one of those carries the published ceiling from earlier. Read those three first and everything else second.
One issue on its own tells you very little. A newsletter is judged against its own previous issues, and a benchmark taken off somebody else's list isn't a target. "Aim for 30%" is advice about a number you can't verify, on a list you've never seen.
Where newsletters go wrong.
The failures are boring and they repeat. Four of them account for most of the newsletters that quietly stop working, and not one is a design problem. Each breaks something the subscriber actually agreed to, which is why they cost more than a weak subject line ever does.
- Promising weekly and sending twice in March breaks the only thing the subscriber signed up for.
- Letting the newsletter drift into offers turns a list that consented to news into one that reports promotions.
- Never removing anybody fills the list with addresses that stopped existing.
- Hiding the unsubscribe link trades a free removal for a complaint that costs you the next send.
The first two cost you attention. The last two cost you delivery, and only one of the four shows up in the report you'll be looking at.
A newsletter is a standing permission with a cadence, a list, and a send policy behind it, and running one shouldn't mean a person clicking through a builder every week. Nitrosend hands you the whole email stack as an API endpoint, a CLI command, and an MCP tool, so the issue goes out from wherever the work already happens. The free tier is 8,000 emails to start and then 500 a month, contacts are unlimited, and there's no credit card.
Go deeper
Sources
- Google, Email sender guidelines. The bulk sender requirements for Gmail: the 5,000 messages a day threshold from 1 February 2024, SPF, DKIM, and DMARC, the visible unsubscribe link, one-click unsubscribe, and the 0.30% spam rate ceiling.
- Yahoo, Sender best practices. Authentication for bulk senders, unsubscribes honoured within 2 days, and a spam rate below 0.3% calculated on mail delivered to the inbox.
- IETF RFC 8058. What one-click unsubscribe is: the
List-Unsubscribe-Postheader, the HTTPS POST, no confirmation page, and the DKIM signature covering both headers. - M3AAWG Sender Best Common Practices. Confirmed opt-in as the highest standard, and telling recipients the potential frequency of communications because unexpected increases lead to more complaints.
Common questions
Two things, and the second one is the one that gets forgotten. They're agreeing to a topic, and they're agreeing to a rhythm. That's why sending three times in a month you promised one issue generates complaints even when the writing is good, and it's why a newsletter that drifts into offers stops being the thing they said yes to. The consent covers the cadence as much as the subject, which is why the cadence belongs on the signup form.
Start with the promise, not the platform. Write one sentence saying what the subscription is for, state the cadence on the signup form, authenticate the sending domain with SPF, DKIM, and DMARC, and collect addresses with confirmed opt-in. Then build the issue against one job and send it. The template is the last decision rather than the first.
It depends on which limit you'll hit first, because free tiers differ more on contact caps than on send volume. Work out how big the list will get, how often you'll send, and whether you need the sending domain authenticated on the free plan. Nitrosend's free tier is 8,000 emails to start and then 500 a month, with unlimited contacts and full MCP, API, and CLI access, and no credit card.
Rather than copying a list of famous ones, look at what makes one good: a single clear job per issue, a cadence that never surprises the subscriber, a voice that reads like a person, and an unsubscribe link that's easy to find. A good newsletter is one a reader would notice going missing, and that's a test you can apply to your own.
As often as you said you would at signup, and no more. The frequency itself matters less than whether it matches the promise, because an unexpected increase in frequency is a reliable way to generate spam complaints. Pick a cadence you can hold for a year, put it on the form, and treat a change to it as something you announce.
Long enough to do one job and no longer. If the issue has a single point, the length is whatever that point needs, which is usually a few hundred words with a link out to anything deeper. Length isn't the thing to optimise: the click rate against the one thing you wanted the reader to do is.
Yes, and the bar worth clearing is higher than the one that gets you delivered. Confirmed opt-in, where the subscriber clicks a link in a confirmation email, is the highest standard and the one that keeps complaint rates down. Tell people at signup how often you'll send, because an unexpected jump in frequency is what produces complaints. Buying a list fails all of it.
Yes, if the platform exposes its capabilities as an API and as MCP tools rather than only as screens. An agent can then draft the issue, pick the segment, check it against the suppression list, and send. Nitrosend is built that way: every capability is an API endpoint and an MCP tool before it's a screen. A person still decides whether the issue is worth sending.