LetterDuck
Newsletters

How to write a newsletter people actually read

Your reader gives you about nine seconds. This is how a working newsletter spends them.

Litmus timed how long people look at an email once they open it: 8.97 seconds on average in its 2021 engagement report, down from 13.4 seconds in 2018, and 30% of opened emails get under two seconds. That is your budget. Every craft decision below follows from it.

This guide covers the writing half of the job. The launch half, the domain, the list, and the sending setup, lives in our guide to starting a newsletter on your own domain.

Give every issue one job

Decide what a single issue is for before you write a word of it. One job, one sentence: "convince operators that forwarding breaks DMARC," or "get readers to try the new roast," or "make Tuesday's council vote legible." Write that sentence at the top of the draft. Everything that does not serve it gets cut or saved for next week.

This is a stance, and it has a cost. A single-job issue is easier to skip when that particular job does not interest a particular reader. We accept the cost, because the alternative is worse: an issue that tries to do four things reads like a company memo, and memos train people to archive you unread. Nine seconds of triage does not reward variety. It rewards clarity.

The one-job rule also solves the hardest practical problem in writing a newsletter, which is knowing when an issue is done. It is done when the job is done. Not when it hits a word count.

The subject line and preheader are one unit

Your reader sees the subject line and the preheader as one line of text in their inbox, so write them together, in one pass, after the issue is drafted. The subject makes the claim; the preheader extends it. Never let the preheader repeat the subject, and never leave it to chance, because an unset preheader gets filled with whatever text happens to come first in your email, which is usually "View this in your browser."

A working pair looks like this: subject "The blend we pulled after 12 days," preheader "Cupping notes, the defect we missed, and what replaces it Thursday." Claim, then extension. On most phones the subject gets roughly 40 characters before it truncates, so the operative word goes early. The full treatment, including truncation numbers by client and example sets, is in our piece on newsletter subject lines.

The opening line rule

Do not open with "welcome back," "happy Friday," or "it's been a busy week over here." Those lines fail twice. They spend triage seconds saying nothing, and in clients where the preheader falls through to body text, they become your preview line in the inbox.

Open with the job instead. If the issue exists to explain why forwarded mail vanishes, the first line is "Gmail was rejecting 73% of the mail we forwarded, silently." If it exists to sell the Thursday roast, the first line is about the roast. A reader who makes it past your first line has committed real attention; the greeting can live in your sign-off, where it costs nothing.

One exception is honest and earns its place: a one-line reminder of who you are, for lists that send monthly or less. "You signed up for this at the Annapolis harbor market" prevents spam complaints from people who forgot you. That line is doing a job. "Welcome back" is not.

The three-block issue

Structure survives skimming when a skimmer can reconstruct the issue from its bones. We use three blocks, in order.

The thing. The main piece, doing the issue's one job. It gets the first and largest block, a heading that states its point rather than teasing it, and paragraphs short enough to read on a phone held in one hand.

The proof. Whatever makes the thing credible: the data, the photo of the defect, the before-and-after, the quote from the council meeting. Skimmers frequently jump straight here, so the proof block has to stand on its own, with its own subhead.

The door. One link, one action, placed at the end. A question that invites a reply is often the best door you can build, because mailbox providers weight engagement roughly as replies over clicks over opens, and a genuine reply is the strongest positive signal your domain can earn. One door. An issue that ends with six links ends with none.

The length question

Length is the wrong variable to optimize; jobs per issue is the right one. Litmus's nine seconds is triage time, not reading time. Readers decide in seconds whether an issue deserves minutes, and a long issue with one clear job wins that decision far more often than a short issue with three vague ones. Matt Levine's Money Stuff runs thousands of words every weekday on one subject, and readers finish it.

Write for the phone regardless of length: one idea per paragraph, a subhead every few hundred words, no wall-of-text openers. If you find the issue running long, the fix is not compression. The fix is checking whether a second job snuck in, and cutting it.

Voice is a retention feature

People renew their attention for a voice, and they reply to a person. Keep the same From name and address on every send; a stable From identity is a deliverability practice as much as a branding one, since filters score senders on history. Keep the prose voice just as stable. Before drafting, reread your last two issues and match them. A newsletter that sounds like a different person each week reads like content, and content gets archived.

Practical guardrails: keep a short list of words you never use, write each issue in one sitting so the tone holds, and read it aloud once before the test send. If a sentence embarrasses you out loud, it will embarrass you in 800 inboxes.

The pre-send checklist we run

This is the literal checklist our own sends go through, in order. Steal it.

  1. Suppression check. Every send is filtered against one suppression list holding every unsubscribe, hard bounce, and spam complaint, applied before the send, not after. Hard bounces stay suppressed permanently. In our workspace this filter is enforced in the send path itself, so a campaign cannot skip it. If your tool makes suppression optional, treat that as a defect.
  2. Plain-text part. Every issue goes out as multipart/alternative with a real plain-text version, not an empty one. Filters read it, some humans prefer it, and text-only clients render it. The reasoning gets its own piece: plain text vs HTML email.
  3. Test send. Send the issue to yourself and open it on a phone. Check three things: where the subject truncates, what the preheader shows, and whether the unsubscribe link works. This takes ninety seconds and catches most of what readers would have caught for you.
  4. One-click unsubscribe header. Every campaign carries both headers required by RFC 8058:
List-Unsubscribe: <https://yourdomain.com/unsubscribe?t=RECIPIENT_TOKEN>, <mailto:unsubscribe@yourdomain.com>
List-Unsubscribe-Post: List-Unsubscribe=One-Click

Gmail and Yahoo have required this of bulk senders since February 2024. The rule allows two days to honor an unsubscribe; we honor it immediately, because someone who wants out is one tap away from a spam complaint, and a complaint costs your domain far more than a subscriber does. Details in the List-Unsubscribe header explained.

Write the job at the top of the draft. Cut what does not serve it. Run the checklist. Send on schedule. That is the whole craft, repeated until it compounds.