Newsletter and email deliverability glossary

The most common mistake is judging the test on too few people. If each version goes to a few hundred subscribers and one gets a couple more clicks, that's probably noise, not a winner. Your ESP may show a "winner" anyway, so be skeptical of small gaps on small samples.

The second issue is what you measure. Subject line tests used to be judged on opens, but Apple Mail Privacy Protection makes opens unreliable. Judge on clicks, or on whatever you actually care about, even if it means waiting longer for results.

Test one thing at a time, so you know what made the difference. And keep a record of what you've learned. A dozen small tests on the same list, written down, are worth far more than any single result.

At your ESP, the abuse desk is who looks into it when complaints about your sending come in, through feedback loops, blocklist alerts or direct reports. If something trips their alarms, they may pause your account while they investigate.

The best thing to do is respond quickly and honestly. Explain where the addresses came from and what you're doing to fix it. Abuse desks see a lot of senders blaming everyone else, so a straight answer goes a long way.

It's also good practice to have working abuse@ and postmaster@ addresses on your own sending domain, and to actually read them. These role addresses are a long-standing convention, and providers sometimes use them to contact senders, including during feedback loop signups.

Most of it is basic good practice that helps every reader:

• real text rather than text inside images
• alt text on images that carry meaning
• enough contrast between text and background
• a sensible reading order and real headings, so screen reader users can jump between sections
• descriptive link text, not "click here"
• a decent font size, and layouts that work when zoomed

For contrast, the W3C's guidelines ask for at least 4.5:1 for normal-size text. Light grey text on white usually fails that.

Mark up layout tables with role="presentation" so screen readers don't announce every cell, and set the email's language. Then test it: turn images off, zoom in, and try a screen reader on one issue. You'll spot most problems in five minutes.

One platform might count anyone who opened in the last 90 days. Another uses clicks in the last 30. Some just mean "not unsubscribed". So before comparing your active numbers with anyone else's, or even across two tools, check what's being counted.

Opens are the weak spot. Apple Mail Privacy Protection makes many Apple Mail users look active whether they read or not, so open-based definitions now overcount.

If you're setting your own definition, base it on clicks, replies and anything else you can trust, over a window that suits how often you send. A daily can judge activity over a shorter window than a monthly.

It's a useful number for sponsors and for planning, because it's closer to your real audience than total list size. Just be ready to explain how you counted it.

Gmail's mobile apps started showing automatic Gemini summary cards in 2025, and Google rolled out AI summaries to all Gmail users from January 2026. In Apple Mail, with Apple Intelligence switched on, a summary can replace the usual preview line under unread emails.

For newsletters, that means some readers decide whether to open based on a summary you didn't write. Your preheader may not show at all.

You can't control it, but you can help. Put your main point near the top in plain words. Use clear headings so each section makes sense on its own. Avoid opening with a long intro or housekeeping. A summary of "Hi everyone, hope you had a good week" helps nobody.

These summaries can also get things wrong, so it's worth reading your issue the way a summarizer would and checking the gist is clear. Expect all this to keep changing.

Here's the classic way it goes wrong. Your ESP sends from its own servers, so SPF passes for something like bounces.esp-mail.com, and DKIM is signed with the ESP's domain too. Both checks pass, but neither is for yournewsletter.com, so DMARC fails.

The fix is to set up a custom return-path (for SPF) and your own DKIM key with the ESP, so the domains line up with yours. Most ESPs walk you through it with a couple of DNS records.

There are two modes. Relaxed alignment, the default, is happy as long as the main domain matches, so mail.yournewsletter.com counts for yournewsletter.com. Strict needs an exact match. You set them with the aspf and adkim tags in your DMARC record. Relaxed is fine for nearly everyone.

Allowlisting happens at two levels. Individual readers can add you to their contacts or safe senders, which tells their mailbox provider they want your email. Companies can allowlist senders across their whole email system, which matters if a lot of your readers are on work addresses.

Asking new subscribers to add you to their contacts is common advice, and it does help for that person. Put it in your welcome email with simple instructions, but don't expect it to fix wider deliverability problems.

For business readers, sometimes the only fix is the reader's IT team allowlisting you. If a particular company keeps blocking you, giving readers the details their IT team needs, like your sending domain, is the practical route.

There are also paid "certification" programs that act like allowlists with some providers. They're a business decision, not a substitute for a clean list.

Write it for images that mean something: a chart, a photo that's part of the story, a button made from an image. Describe what matters about the image in context, not every detail. "Chart showing open rates falling after 2021" is more useful than "chart".

For purely decorative images, like spacers or dividers, use an empty alt (alt=""), so screen readers skip them.

In email it does double duty. Some apps and work setups block images by default, so your alt text is what people see in place of the picture. You can style it with color and font size so it still looks deliberate.

Never put important information only in an image, especially your call to action. If the image doesn't load, the alt text is all that's left.

An AMP email includes a special AMP version alongside the normal HTML. Inboxes that support it show the interactive version, and everyone else gets the HTML.

To have it shown to readers, you need to register with Google, and the AMP code has to meet strict rules. One mistake and inboxes fall back to the HTML version without telling you. Outlook doesn't support it.

Honestly, for most newsletters it isn't worth the effort. You build and maintain two versions of every email for a feature only some of your readers will see. It makes more sense for specific uses where interaction inside the email really helps, like a quick poll or a form, and where your audience is mostly on Gmail.

For most newsletters, a simple link to a web page does the same job.

Apple launched MPP in 2021 with iOS 15. When it's on, Mail grabs images and other remote content as soon as an email arrives, not when someone opens it. That fires your tracking pixel for emails nobody looked at. The open time is wrong too, and the IP address belongs to Apple's relay, so location data from opens is pretty much useless.

For a newsletter, that messes with anything built on opens: open rate, click-to-open rate, subject line tests judged on opens, resends to non-openers, and any segment that defines "active" as "opened recently".

Clicks are fine, because MPP doesn't touch links. So lean on clicks, replies and what people do on your site. If you need opens for something like a sunset policy, treat Apple opens as unknown rather than engaged. Some ESPs flag likely MPP opens separately, so check whether yours does and what it's counting.

Forwarding is hard on authentication. When a mailing list adds a footer or changes the subject, DKIM breaks. When a server forwards mail on, SPF fails, because the forwarding server isn't in your record. So a perfectly legitimate email can fail DMARC by the time it arrives.

ARC fixes that by having each server along the way add signed headers saying "this is what the authentication looked like when it reached me". The final receiver can choose to trust that record if it trusts the servers that wrote it.

For most newsletter senders, it's not something you set up. It's done by forwarding services and mailing list software, and it's part of why moving to a strict DMARC policy usually doesn't break forwarded mail as much as people fear. It's defined in RFC 8617, which is still officially experimental.

The simplest version is "last click": if someone clicks a newsletter link and buys, the newsletter gets the credit. It's easy, but it undercounts email. Lots of readers see something in your newsletter, then come back later through search or by typing your address.

Tools that help: UTM parameters on every link, so analytics can see newsletter traffic, discount codes or landing pages unique to the newsletter, and simply asking people where they heard about you.

No method is perfect, and that's fine. What matters is using the same one consistently, so you can compare issues and campaigns against each other.

For sponsors, be clear about what you're reporting. Clicks are solid. Conversions they track on their side depend on their setup, not yours.

Each one does a different job. SPF lists which servers can send for your domain. DKIM adds a signature that proves the email wasn't changed on the way. DMARC ties the two to your From address and tells providers what to do when checks fail. BIMI is the logo bit, and it only works once the other three are in order.

This used to be "best practice". It isn't optional anymore. Gmail and Yahoo have required all three from bulk senders since February 2024, Google started actively rejecting non-compliant mail from November 2025, and Microsoft brought in the same rules for Outlook.com in May 2025.

If you're on a decent ESP, setting it up is mostly copying a few DNS records. The part people skip is checking it actually passes, so send yourself a test and look at the headers.

For newsletters, the usual ones are a welcome sequence for new subscribers, a re-engagement campaign for people who've gone quiet, emails triggered by clicking a particular link, and upgrade reminders for free readers.

Most ESPs have a visual builder: a trigger, then a series of emails and waits, with conditions along the way. It's easy to build something huge, but a few simple flows that work are better than one complicated one nobody understands.

Two things to keep an eye on. Automations keep running when nobody's watching, so check them every so often for broken links, old offers and outdated information. And watch how they stack up with your regular issues. A new subscriber getting five welcome emails plus the daily newsletter in their first week is getting a lot of email.

In newsletter tools, it's an older name for what's now usually called automation. A single autoresponder is usually the welcome email. A series is a sequence or drip campaign.

The other meaning comes up from the other side: when you send an issue, you'll get a wave of automatic replies back. Out-of-office messages, "I've changed jobs" notices and helpdesk ticket confirmations. These come to your reply-to address, not as bounces.

It's worth filtering them so they don't bury real replies. Some are also useful, like "this person has left the company" messages, which can tell you an address is about to go dead before it bounces.

It happens when a server accepts an email first and only later decides it can't deliver it, then sends a bounce to the address in the email. If that address was forged, the bounce goes to someone who had nothing to do with it.

For a newsletter sender, it shows up in two ways. You might suddenly get lots of bounces and auto-replies for emails you didn't send, which usually means someone's spoofing your domain. DMARC at enforcement makes this much rarer, because receivers reject the forged mail outright.

Or your own systems could create backscatter, by auto-replying to spam sent to your reply-to address. Good mail servers reject bad mail during the SMTP conversation rather than accepting it and bouncing it later, which avoids the problem.

You publish a BIMI record in DNS pointing at your logo, saved in a strict SVG format (SVG Tiny PS). Then it comes down to each provider's rules.

Gmail wants a Verified Mark Certificate (VMC) or a Common Mark Certificate (CMC). A VMC needs a trademarked logo and gets you Gmail's blue checkmark. A CMC doesn't need a trademark, but you don't get the checkmark. Gmail also needs your DMARC policy at quarantine or reject and applying to all your mail. p=none won't do.

According to the BIMI Group, Gmail, Apple, Yahoo, Fastmail and a handful of others support it, and Microsoft doesn't.

For a newsletter, it's a nice-to-have. A logo won't fix deliverability, but getting to DMARC enforcement, which BIMI forces you to do, is worth doing anyway.

There are hundreds of them, and most don't matter. The one that really counts is Spamhaus, because so many providers use it. A few others are worth watching, but a listing on some obscure list nobody uses won't move anything.

Some list IPs, some list domains. If you're on a shared IP, an IP listing might be another sender's mess, and your ESP deals with it. A domain listing is about you.

Getting off one usually means fixing the cause first, then requesting removal through the list's own lookup tool. Many listings also expire on their own once the problem stops. Be wary of anyone who charges to delist you.

Hitting spam traps is the usual way newsletters end up listed, so a sudden listing almost always points back at where your addresses came from.

Email security tools like Microsoft Defender's Safe Links scan the URLs in incoming email, and some do it before the email is even delivered. Every link they visit goes through your tracking redirect and shows up as a click.

You can often spot them. Look for clicks within seconds of delivery, every single link in the email clicked at once, or clicks with no opens. They're most common on business and education addresses.

Why it matters: they inflate your click-through rate, mess up A/B tests judged on clicks, and can keep people in your "engaged" segment who haven't read anything in months. Some ESPs filter likely bot clicks, so check what yours does.

Never let a simple link visit do anything important, like unsubscribing someone. That's why one-click unsubscribe uses a POST request instead.

Some are just junk. Others are part of list bombing, where bots sign a real person up to loads of newsletters at once to bury something in their inbox. Either way, you end up emailing people who didn't ask, and they complain.

Signs to look for: a sudden spike in signups at odd hours, lots of addresses that look random, signups from the same IP range, or new subscribers who never confirm or open anything.

The fixes stack up nicely. Double opt-in is the big one, because a bot can fill in a form but can't click a confirmation link in someone else's inbox. On top of that, a hidden honeypot field on the form, rate limits, and a CAPTCHA if things get bad. Most ESPs have some of this built in, so check it's switched on.

When the receiving server won't take an email, it replies with an SMTP code. A 5xx code is a hard bounce: the address doesn't exist, the domain's gone, or you've been blocked. A 4xx code is a soft bounce: full mailbox, server down, or the provider asking you to slow down and try later.

Your ESP reads these codes and decides what to do, usually suppressing hard bounces straight away and retrying soft ones. It's worth knowing how yours handles them, because the defaults aren't the same everywhere.

Watch your bounce rate after every send. A jump almost always means something specific happened, like an old segment got mailed or a provider started blocking you, and it's much easier to fix the day it happens.

Say you send to 50,000 people and 400 bounce. That's a 0.8% bounce rate. On a list you send to regularly, it should be steady from send to send, because hard bounces get suppressed the first time.

That's the useful way to think about it: watch for changes rather than chasing a benchmark. A sudden jump almost always has a specific cause. Maybe you mailed an old segment, imported a list, or a provider started rejecting you.

Split it by type and by provider. A spike in hard bounces usually means bad addresses. A spike in soft bounces at one provider usually means a reputation or rate problem. Some ESPs file blocks as hard bounces, so look at the actual codes before drawing conclusions.

ESPs often split sending into two types: broadcasts, also called campaigns, which you write and schedule, and automations, which run on their own.

For newsletters, broadcasts are the regular issues and any special announcements. The thing to watch is how they overlap with automations. A new subscriber might be in the middle of a welcome sequence when your weekly issue goes out, and suddenly they're getting two emails a day.

Most platforms let you exclude people who are in a sequence, or pause the sequence when a broadcast goes out. Worth setting up if you run both.

The older term "email blast" means the same thing, but it suggests sending everything to everyone. A bit of segmentation, even just leaving out inactive subscribers, usually makes broadcasts land better.

Google counts all mail from your primary domain, so your newsletter, receipts and team email add up together. Once you hit the threshold, you're a bulk sender permanently, even if your volume drops afterward.

Most newsletters of any real size are bulk senders, so it's safest to just assume you are one. That means SPF, DKIM and DMARC all set up and aligned, one-click unsubscribe, and a spam complaint rate under 0.3%.

Yahoo applies similar rules to bulk senders but doesn't publish an exact number. Microsoft uses the same 5,000-a-day line for Outlook.com and has required SPF, DKIM and DMARC above it since May 2025.

The alternative, using an image as a button, breaks when images are blocked and can't be read by screen readers. A plain HTML link styled as a button looks fine in most apps, but older versions of Outlook for Windows ignore some of the styling.

Bulletproof buttons solve that with a table-based layout and, for those Outlook versions, a bit of extra code they understand. The result is a clickable button with real text that looks right nearly everywhere.

You rarely need to build one by hand. Most ESP editors create them automatically, and there are free generators if you're coding your own template. Just make sure the whole button is clickable, including the space around the text, and that it's big enough to tap on a phone.

The basic rule is one main action per email, or per section in a longer newsletter. Too many competing buttons and readers do nothing.

Write the button text as the action: "Read the full story", "Get the guide", "Upgrade to paid". It should make sense on its own, because screen reader users often hear links out of context.

Build buttons with HTML and CSS rather than as images, so they still show when images are blocked. A bulletproof button does this reliably across email apps, including older versions of Outlook. Make them big enough to tap easily on a phone.

For newsletters, plain text links often work as well as buttons. Readers are there to read, and a well-placed link in the copy can get more clicks than a big button that looks like an ad.

The Federal Trade Commission enforces it, and its main requirements are:

• no false or misleading header information
• no deceptive subject lines
• identify the message as an ad, where it is one
• include a valid physical postal address
• tell people how to opt out, honor opt-outs within 10 business days, and keep the opt-out working for at least 30 days after sending
• you're still responsible if another company sends on your behalf

Penalties can be up to $53,088 for each email that breaks the rules, per the FTC's current guidance.

It's the lowest bar of the major laws. If you have readers in Canada or Europe, CASL and GDPR are stricter, and Gmail and Yahoo's rules are stricter still on unsubscribes. This isn't legal advice, so check with a lawyer for your situation.

Consent comes in two types. Express consent is someone clearly agreeing to receive your emails, and it doesn't expire unless they withdraw it. Implied consent comes from an existing relationship: up to two years after a purchase, or six months after an inquiry. After that, you need express consent.

Every message needs your business name, a mailing address and another way to contact you, plus an unsubscribe that stays working for at least 60 days and is acted on within 10 business days.

The penalties are serious: up to $1 million per violation for individuals and $10 million for businesses. The regulator, the CRTC, has fined companies that couldn't show when and how they got consent.

If you have Canadian readers, keep a record of how each person signed up. This isn't legal advice, so check your own situation with a lawyer.

Some companies use catch-alls so they never miss email sent to a mistyped address. For list owners, they're awkward, because the server says yes to everything.

That causes a couple of problems. Email verification tools can't confirm the mailbox exists, so they usually mark these as "unknown" or "risky". And mail to made-up addresses on a catch-all domain doesn't bounce, so a fake signup can sit on your list for ages without you noticing.

You don't need to block catch-all addresses, since lots are real people at real companies. But treat them with a bit more caution. Double opt-in settles it, because a confirmation click proves someone's reading. Without that, watch engagement and drop them quickly if nothing happens.

It applies to for-profit businesses that meet one of these: annual gross revenue above a threshold (raised to $26,625,000 from 2025), buying, selling or sharing the data of 100,000 or more California consumers or households, or making half their revenue from selling or sharing data.

For newsletters, the relevant rights are to know what data you hold, to delete it, to correct it, and to opt out of its "sale" or "sharing". Sharing includes passing data on for cross-context advertising. So uploading your list to an ad platform to target or build lookalike audiences can count.

Unlike GDPR, it doesn't require consent before emailing. That part is still covered by CAN-SPAM. But if it applies to you, you need a privacy policy that covers these rights and a way to honor them.

This isn't legal advice, so check with a lawyer about whether it applies to you.

For a free list, a simple version is people lost in a month ÷ subscribers at the start of the month × 100. Lose 500 from a list of 25,000 and your monthly churn is 2%.

Some people also count inactive subscribers you've removed. Whichever you choose, keep it consistent so the trend means something.

Every list loses people, so churn on its own isn't bad. What matters is how it compares to how fast you're adding people, and what's driving it. A jump after a frequency change or a specific promotion tells you something useful.

For a paid newsletter, churn is often the most important number of all. Getting monthly cancellations down even a little can matter more to revenue than a burst of new signups. See growth rate for the other side of the sum.

They're a nice extra revenue stream, especially for newsletters with a professional audience. Small businesses, job posts, events and tools can't always afford a main sponsorship but will happily pay for a couple of lines.

The format is simple: a short headline, one or two lines of text and a link, all in the same style so the section looks tidy. Readers often like them, because they're quick to scan and sometimes useful.

They're also easy to sell yourself with a simple booking form and fixed price, so you don't need an ad sales team.

The usual rules apply. Label the section clearly as paid, check what you're promoting, and keep the number of ads sensible so the section doesn't take over the newsletter.

That redirect is why links in your newsletter look different when you hover over them. It's also why click-through rate is possible at all.

A few things to know. By default, the redirect runs through your ESP's shared tracking domain, which can be affected by other senders' reputations. A custom tracking domain fixes that.

Security scanners follow these links too, which is where bot clicks come from. And some privacy tools strip tracking parameters or block redirects, so a small share of real clicks may never be counted.

You can usually switch tracking off for specific links, like a link to a sensitive page, or for an entire email. Some publishers do that for plain-text style issues to make links look cleaner, accepting that they'll lose the click data.

Say an issue is delivered to 40,000 people and 1,200 click something. Your CTR is 3%.

It's often confused with click-to-open rate. CTR measures clicks against everyone who received the email, so it reflects your whole funnel: the subject line got the open and the content got the click. CTOR only looks at people who opened, so it tells you about the content on its own.

Since Apple Mail Privacy Protection made opens unreliable, CTR has become the more trustworthy of the two. But it has its own noise: bot clicks from security scanners can push it up, especially on business-heavy lists.

Some platforms use sent instead of delivered as the bottom of the formula, so check before comparing numbers across tools.

Quick example: 2,000 people open, 300 of them click, so your CTOR is 15%. Because it only looks at people who opened, it tells you about the content rather than the subject line. Plain click-through rate mixes the two together.

The problem these days is Apple Mail Privacy Protection. Apple Mail loads images in the background for anyone who has it switched on, and that counts as an open whether they read the email or not. Those machine opens go in the bottom of the formula and drag CTOR down. So if your CTOR is sliding, it might just mean more of your list reads on Apple devices.

Compare CTOR against your own previous sends rather than industry benchmarks, and keep an eye on clicks against delivered too. There's a CTOR calculator on the site if you want to run the numbers.

It can bring in a lot of subscribers cheaply. Whether they're any good depends almost entirely on how it's done.

The good version: a clear, unticked checkbox, a plain description of your newsletter, and people actively choosing it. Those subscribers can be fine.

The bad version: pre-ticked boxes, vague descriptions, or bundling several newsletters into one tick. People end up on your list without realizing, so they don't recognize you, ignore you, and complain. Pre-ticked boxes also aren't valid consent under GDPR.

If you try it, send co-reg signups a welcome email that clearly reminds them where they signed up, use double opt-in if you can, and track them separately. If their engagement and complaint numbers are much worse than your other sources, it's costing you more than it's worth.

The difference matters for both deliverability and the law. A newsletter goes to people who opted in. Cold email doesn't, so it relies on being relevant and low volume, and it's covered by much stricter consent rules in places like Canada and Europe.

Don't mix the two. Never add cold contacts to your newsletter list, which turns it into purchased email list territory with all the same problems. And don't send cold outreach from your newsletter's sending domain, because complaints from cold email will hurt your newsletter's reputation.

Most mainstream newsletter platforms ban cold email in their terms anyway.

If you're doing outreach for sponsorships or partnerships, send it as normal one-to-one email from your own mailbox, not through your newsletter platform.

In the US, CAN-SPAM doesn't require consent before sending commercial email, only an easy way to opt out. In Canada, CASL requires express or implied consent. In the EU and UK, GDPR and the email marketing rules alongside it expect clear opt-in: freely given, specific, informed and unambiguous.

If you have readers in several places, the simplest approach is to meet the strictest standard everywhere. That means a clear signup, no pre-ticked boxes, saying what people will get, and a record of when and how they agreed.

Consent also matters beyond the law. Mailbox providers effectively judge whether people wanted your email, through complaints and engagement. A list built on clear consent is easier to deliver.

Keep consent records with each subscriber, including the date, the form and what it said. This isn't legal advice.

It depends what you're measuring. For an email, a common version is conversions ÷ emails delivered. Some people use clicks as the bottom of the formula instead, which tells you how well the landing page did rather than the email. For a signup form, it's signups ÷ visitors.

Say an issue with an upgrade offer is delivered to 30,000 free subscribers and 90 upgrade. That's a 0.3% conversion rate on delivered.

To measure it, you need tracking that links the click to the result. That usually means UTM parameters and your analytics or payment tool, since conversions happen after the reader leaves the email.

Keep it in context. A low conversion rate on a big list can still bring in more than a high one on a small segment, and one email rarely gets all the credit for a sale.

If you spend $3,000 on ads and get 1,500 new subscribers, your cost per subscriber is $2.

The number on its own doesn't tell you much. A cheap subscriber who never opens is worth less than an expensive one who reads every issue and buys things. So track what those subscribers do afterwards: how many confirm, how many are still reading after a couple of months, and what they're worth to you.

The simple test: if a subscriber earns you more over their time on your list than they cost to get, the channel works. If not, it doesn't, however cheap it looks.

Compare channels by cohort rather than overall. Paid social, referral programs and newsletter recommendations often bring in very different quality readers at similar prices.

The math is spend ÷ clicks. If a sponsor pays $600 and the placement gets 400 clicks, the CPC is $1.50.

For publishers, the upside is that it's harder to argue with. Clicks are clearer than opens, which Apple Mail Privacy Protection has made unreliable. The downside is risk: if the ad is weak or the offer's a poor fit, you earn very little, even though the placement still took space in your newsletter.

Watch out for bot clicks. Security scanners can click every link in an email, and if they're counted, sponsors get charged for clicks no person made. Good ad networks filter these, so ask how they do it.

Many publishers prefer a flat or CPM price with a minimum, or a mix: a base fee plus a bonus above a click target.

The math is price ÷ impressions × 1,000. Say a sponsor pays $1,500 for an issue that goes to 60,000 subscribers. That's a $25 CPM on sends. If 24,000 people opened it, the same deal is a $62.50 CPM on opens. Same money, very different number, which is why two rate cards can look miles apart when they're charging the same.

Pricing on opens has another problem now. Apple Mail Privacy Protection fires opens automatically, so some of the opens a sponsor pays for were never seen by a person. Pricing on sends is a bit blunter, but at least everyone knows what's being counted.

Whichever you go with, put it on the rate card, report on that same number after the send, and include clicks so the sponsor has something real to judge the placement on.

On the web, you write styles once in a stylesheet. In email, some apps have historically removed the <style> block, so the only styles guaranteed to survive are the ones written directly on each element.

Inliners do this automatically. Most ESPs inline your template when you send, and there are free tools if you're coding your own.

There's a downside: repeating the same styles on every element makes the email bigger, and bloated HTML is a common cause of Gmail clipping. Keep styles simple and avoid giant style rules that get copied everywhere.

Some things can't be inlined, like dark mode styles and responsive layouts that use media queries. Those stay in the style block, so a good setup uses both: inline the basics, and keep media queries in the head.

They're popular because readers get a filter on a noisy topic, and the person writing it doesn't have to produce everything from scratch.

The best ones add something to each link: why it matters, what the takeaway is, or a quick opinion. A bare list of headlines is easy to replace, and readers drift away. A line or two of context per item is what makes them come back.

A few practical things. Lots of outbound links means a lot of click tracking, so a custom tracking domain is worth setting up. Check the sites you link to aren't on any blocklists. And keep issues a sensible length, because long link lists can run into Gmail clipping.

Credit your sources properly. Curated newsletters depend on other people's work, and good attribution builds goodwill with the writers you feature.

When your ESP tracks clicks, it rewrites every link to go through its own server first. By default, that's a domain shared by all of its customers. So if another customer sends something nasty, that shared domain can end up on a blocklist, and your links get caught along with it.

With a custom tracking domain, like links.yournewsletter.com, links go through a subdomain you control. You set it up with a CNAME record pointing at your ESP, and make sure it supports HTTPS.

It also looks better. Readers who hover over a link see your domain rather than an unfamiliar one, and links that obviously match the sender are less likely to look like phishing.

Most decent ESPs support it, often in the same setup screen as your DKIM records. It's a small job worth doing.

That last group is the only one you fully control. Apps that support the prefers-color-scheme media query let you write your own dark mode colors. Can I email, which tracks this, shows that support is patchy, so you can't rely on it everywhere.

Other apps take over and change colors themselves, sometimes just backgrounds, sometimes everything. That's where things break: a dark logo on a transparent background disappears, a carefully chosen brand color turns muddy, or text ends up dark on dark.

A few habits avoid most problems. Use logos with a light outline or a solid background. Don't put important text in images. Avoid pure black and pure white, which tend to get inverted harshly. And test in dark mode in the apps your readers actually use, because it differs a lot from one to the next.

Honestly, most newsletters don't need one. A dedicated IP only builds a good reputation if you send enough, and often enough, for mailbox providers to judge it. If you send a weekly issue to a modest list, the IP sits idle most of the week, and that's worse than being on a well-run shared IP.

It starts to make sense when you're sending large volumes on a steady schedule, and you want to stop other senders' behavior affecting you. Your ESP will have its own minimum volume before it'll offer one.

If you do switch, you need to warm it up first. A brand new IP has no history, and pushing your full list through it on day one is a good way to get throttled or blocked.

Also, a dedicated IP doesn't fix bad list habits. Your domain reputation comes with you either way.

People mix it up with delivery rate all the time. Delivery rate only tells you the receiving server accepted the email. Deliverability is about where it landed after that, and an email can be "delivered" straight to spam.

You can't measure it exactly, because mailbox providers don't tell you where each email went. You piece it together from signals: inbox placement tests, Google Postmaster Tools, sudden drops in opens or clicks at one provider, and replies from readers saying they found you in spam.

What actually moves it is mostly boring. Get authentication right, only mail people who asked, remove people who've stopped reading, and keep complaints low. Most deliverability problems come back to the list rather than the content.

This is the number that confuses people most. Your ESP shows 99% delivered and you assume you're fine. But "delivered" just means the receiving server took the email. It might have gone straight to spam.

That's the difference between delivery rate and deliverability. Delivery rate is the easy, visible part. Where the email actually ended up is what matters, and you can only estimate it with things like inbox placement testing.

So treat a high delivery rate as the minimum, not proof that things are working. A low one does tell you something useful, though. If it drops, look at your bounce rate and the bounce codes for what's being rejected and why.

Publishers use them to keep readers up to date without flooding their inbox. A daily or weekly digest of new stories is one of the most common newsletters there is.

They're often automated with RSS-to-email, which makes them cheap to run. The risk is that they end up feeling automatic: a list of headlines and thumbnails that readers stop opening.

A few things make a big difference. Put the best story first, not just the newest. Add a short human intro or a pick of the week. Use real headlines and decent summaries rather than cut-off excerpts.

Keep an eye on length. Long digests with lots of images and links are a common cause of Gmail clipping, which hides the footer and unsubscribe link.

Your ESP signs each email with a private key. The receiving server looks up the matching public key in your DNS, at something like selector._domainkey.yourdomain.com, and checks the signature. If anything in the signed parts changed in transit, it fails.

The thing to get right is whose domain does the signing. Out of the box, a lot of ESPs sign with their own domain. That passes DKIM, but it doesn't help your DMARC, because it isn't aligned with your From address. Set up DKIM with your own domain in your ESP's settings.

Use 2048-bit keys if your DNS provider allows it. The current standard says signers should, and 1024-bit is the minimum. DKIM also survives forwarding better than SPF does, which is one reason it carries more weight in practice.

DMARC sits on top of SPF and DKIM. An email passes if at least one of them passes and lines up with the domain in the From address people see. That lining up is called alignment, and it's where setups usually trip up: your ESP signs with its own domain, SPF passes for the ESP, and DMARC still fails because neither check was for your domain.

The record lives at _dmarc.yourdomain.com, and the p= tag sets the policy: none (just report), quarantine (treat failures as suspicious) or reject. Start on none, read the reports until every legit sender is aligned, then tighten it up.

Gmail and Yahoo have required DMARC from bulk senders since February 2024, and p=none is enough to meet that. The standard was updated in May 2026 as RFC 9989, but your existing v=DMARC1 record still works.

It's the p= tag. p=none just gets you reports and protects nothing, but it's enough for Gmail and Yahoo's bulk sender rules. quarantine and reject are what people mean by "enforcement", and you need one of them for BIMI.

The usual path is to start at none, read the aggregate reports for a few weeks, fix any legitimate senders that aren't aligned (your ESP, your CRM, the billing system someone forgot about), then move up. There's also an sp= tag if you want a different policy for subdomains.

One recent change: the May 2026 update to the DMARC standard (RFC 9989) dropped the old pct= tag for rolling out a policy to a percentage of mail. There's now a t=y testing flag instead, though not every provider supports it yet.

You ask for them in your DMARC record with rua= and ruf= tags pointing at an email address. Aggregate reports usually arrive daily from each provider, as XML files listing every IP that sent mail as your domain and whether it passed SPF, DKIM and alignment.

They're how you find everything sending as you: your ESP, your CRM, your helpdesk, the old system nobody remembered. That's what makes it safe to move to a stricter DMARC policy.

Raw XML isn't much fun to read, so most people send reports to a DMARC reporting tool that turns them into charts. Plenty of them have a free tier.

Failure reports are less common. Fewer providers send them, because they can contain bits of actual messages. Aggregate reports are the ones that matter. The formats are now defined in RFC 9990 and RFC 9991.

The ones you'll meet when setting up a newsletter:

• TXT records hold text, and they're used for SPF, DMARC and domain verification
• CNAME records point one name at another, often used for DKIM, tracking domains and return-paths at your ESP
• MX records say which servers receive email for a domain
• PTR records do reverse DNS, mapping an IP back to a name

You add them wherever your domain's DNS is managed, which might be your domain registrar or a service like Cloudflare. Your ESP gives you the exact values to copy.

Changes can take a little while to show up everywhere. And be careful editing existing records, especially SPF. Having two SPF records breaks both, so merge them into one.

Every complaint, every ignored email, every open, reply and "not spam" click feeds into it. Providers keep their own scores and don't publish them. Google used to show a rough rating in Postmaster Tools, but the current version dropped it, so now you mostly infer it from where your mail lands.

The big difference from IP reputation is that you can't leave it behind. Change ESP or IP and your domain's history comes with you. That's a good thing if you've been careful, and a problem if you haven't.

It's also why plenty of publishers send newsletters from a subdomain, like news.yourbrand.com. It keeps newsletter reputation a bit separate from your main domain. See sending domain for how that works.

Same idea as IP warming, but for the domain. A brand new domain has no reputation, and these days domain reputation carries a lot of weight, so a cold domain can struggle even on a well-established IP.

It comes up when you move your newsletter to a new subdomain, rebrand, or launch a new publication. The approach is the same: start with your most engaged readers, increase volume over a few weeks, and watch for deferrals, bounces and spam placement at each provider.

Don't confuse it with the "warm-up services" that send fake emails between their own accounts to make a domain look active. Those are mainly aimed at cold sales email, and mailbox providers are wary of them. For a newsletter, real readers who want your email are the best warm-up there is.

You'll grow a bit slower than with single opt-in, because some people never click the confirmation. But everyone who does has shown they want you, typos never make it onto your list, and nobody can sign up someone else.

That last bit matters more than it used to. Bots sign real people up to loads of lists at once, often to bury a fraud alert in their inbox. A single opt-in form will happily send your welcome email to every one of those people, and since they have no idea who you are, they hit the spam button. Spamhaus recommends confirmed opt-in for exactly this reason, and because it keeps typo traps off your list.

Keep the confirmation email short with the button near the top. Then watch what share of signups confirm. If it suddenly drops, check the confirmation email is still arriving.

The classic newsletter version is an email course: sign up and get one lesson a day for a week. Others are onboarding sequences that introduce the newsletter, or a series of emails leading up to a paid offer.

They work well because people get them in order, at a steady pace, starting right when they're most interested.

Some practical tips. Space them sensibly. Daily is fine for a short course, but longer sequences usually work better with a few days between emails. Decide what happens when a sequence overlaps with your regular newsletter, since many ESPs let you pause one while the other runs. And make it easy to stop the sequence without unsubscribing from everything.

Like any automation, they run unattended, so review them every few months for out-of-date content.

Instead of building separate emails for each group, you build one with sections that show or hide based on what you know about the reader: their interests, location, plan, or what they've clicked before.

For newsletters, common uses are local news sections, different promos for free and paid readers, and leaving out a section someone has said they don't want.

It saves time compared with managing many separate versions, but it's easy to get wrong. A missing field can leave a blank space or show the wrong section. So set a sensible default for every block, and preview the email as a few different readers before sending.

There's also "live" content that changes when the email is opened, like countdown timers or the latest scores, which loads from a server as an image. That's different again, and it depends on images loading.

It's easy to confuse with the mailbox provider. The mailbox provider hosts the account and decides whether your email gets in. The client is the app it's read in. Someone can have a Gmail account and read it in Apple Mail, or a work Microsoft account read in the Gmail app.

For deliverability, the provider matters. For design and tracking, the client does.

Different clients render HTML in their own ways, which is why an email can look fine in Apple Mail and broken in Outlook for Windows. They also handle images, dark mode and size limits differently. Some client behavior affects your numbers too: Apple Mail with Mail Privacy Protection inflates opens, and Gmail clips long emails.

Your ESP's reports usually show which clients your readers use. That's worth knowing before you design anything.

Most email apps let you see them. In Gmail, it's "Show original" in the message menu. In Outlook and Apple Mail, look for "View source" or "Show all headers".

The most useful line is usually Authentication-Results. It shows whether SPF, DKIM and DMARC passed, and which domain each was checked against. That's how you spot an alignment problem.

Other handy ones: From and Return-Path show your two sender addresses, the Received lines show each server the email passed through, List-Unsubscribe confirms your unsubscribe header is there, and DKIM-Signature shows which domain signed it.

The quickest way to check your setup is to send an issue to a Gmail address, open the original, and read those few lines. It takes a minute and catches most problems.

What makes it a newsletter rather than just marketing email is mostly the reader's expectation. They signed up to get something regular, and they expect it to be worth reading even when it isn't selling them anything.

They come in lots of forms: original writing, a curated roundup of links, a digest of a website's latest stories, or something more like a magazine. Some are free and paid for by sponsorship, some are paid newsletters, and plenty are a mix.

For publishers, newsletters do two jobs. They bring people back to the site regularly, and they're one of the few audiences you own outright. Nobody can change an algorithm and take your subscribers away.

That's also why deliverability matters so much. A newsletter only works if it reaches the inbox.

For newsletters, that's usually a platform built for publishers, or a general marketing tool. Either way, it's doing a lot behind the scenes: running the sending servers, managing IP reputation, processing bounces and feedback loops, and adding the unsubscribe headers Gmail and Yahoo want.

Things worth checking on any ESP, beyond the features list:

• whether you can set up DKIM and a custom return-path on your own domain, so you're properly aligned
• how it treats soft bounces, bot clicks and Apple opens in its reports
• whether you can export everything, including your suppression list, if you ever leave

That last one matters more than people think. Switching ESP is common, and losing your suppressions on the way is one of the most avoidable deliverability mistakes there is.

It's easier than people think, because basic email has no built-in check on the From address. That's the gap SPF, DKIM and DMARC were built to close.

With DMARC at quarantine or reject, mail claiming to be from your domain that fails authentication gets sent to spam or blocked. Without it, scammers can send fake "invoices" or "account alerts" that look like they came from you, and your domain's reputation can suffer for it.

It doesn't cover lookalikes. Someone can register yourbrand-news.com or a domain with a swapped letter, and DMARC on your domain does nothing about that. Keeping your from name and sending domain consistent at least helps readers notice when something's off.

Your DMARC reports will show you if someone's sending as your domain.

Verification tools check each address in a few steps: is it formatted properly, does the domain exist and accept mail, and will the mail server confirm the mailbox exists. Some also flag disposable addresses, role addresses like info@, and known risky ones.

It's most useful at two points. At signup, to catch typos like gmial.com before they get on your list. And before mailing any older list or import, to clear out addresses that would bounce.

It's not perfect. Some mail servers accept everything and only bounce later, so the tool can't tell. And it can't spot a spam trap reliably, because a trap is a working address by design.

So treat it as a cleanup tool, not permission. Verifying a list you didn't get consent for doesn't make it OK to mail.

That's the main thing to know. One ESP's "engaged" means opened in the last 90 days, another's means clicked in the last 30, and another blends a few things into a score. Two numbers called engagement rate often aren't measuring the same thing.

Opens are the weak spot. Since Apple Mail Privacy Protection, anything that counts opens will treat a lot of Apple Mail users as engaged whether they read or not. Bot clicks can do the same on the click side.

If you're defining it yourself, for segments or a sunset policy, use the signals you trust most: clicks, replies, and anything people do on your site. Then write the definition down so everyone means the same thing.

Mailbox providers measure engagement too, in their own way, and it feeds straight into where your email lands.

It works on two levels. Overall, if a big share of your recipients ignore or delete your emails, your reputation suffers and more of your mail goes to spam for everyone. And for each person, the provider learns how they treat you, so the same newsletter can land in one reader's inbox and another's spam folder.

That's why inactive subscribers aren't harmless. Every unread email counts against you a little, and they make it harder to reach the people who do want you. It's the main reason sunset policies and list hygiene help deliverability.

Providers don't publish exactly which signals they use or how they weigh them. Things readers do on purpose, like replying, moving you out of spam or adding you to contacts, are generally understood to count for a lot. Encourage them where it's natural.

Each provider runs its own, and they work differently.

• Yahoo's Complaint Feedback Loop sends a report for each complaint. You sign up per domain, and it only works for DKIM-signed mail.
• Microsoft has the Junk Email Reporting Program (JMRP) for Outlook.com.
• Gmail doesn't tell you who complained. It shows aggregated complaint data in Postmaster Tools, grouped by a Feedback-ID header you add to your emails.

If you're on a mainstream ESP, it's almost certainly signed up for the main ones already and handles it for you. What's worth checking is that complainers really do get suppressed. Sending again to someone who reported you as spam is about the fastest way to rack up more complaints.

The legal must-haves: a working unsubscribe link and a valid postal address. CAN-SPAM requires the address. CASL requires your business name, a mailing address and another way to contact you.

Good practice adds a few things: why the reader is getting the email ("You signed up at..."), a link to manage preferences, and a contact address that a person actually reads.

Two things to watch. Don't make the unsubscribe link hard to find with tiny grey text. That just pushes people to the spam button. And check that your footer survives Gmail clipping. If your email's too long, everything at the bottom, including the unsubscribe link, gets hidden.

The footer link is separate from the unsubscribe button Gmail and Yahoo show using your List-Unsubscribe header. You need both.

Most forwards happen with the email app's own forward button, which your ESP can't see. The forward rate an ESP reports usually only counts its own "forward to a friend" link, which few people use. So the real number is higher than whatever you're shown.

There are better ways to see sharing. A "Was this forwarded to you? Subscribe here" link near the top or bottom catches new readers who got a forward, and signups through it tell you sharing is happening. Referral programs make sharing visible and reward it.

One thing to watch: when someone forwards your email, the person receiving it gets the original sender's links, including the unsubscribe link. If they click it, they can unsubscribe your reader by mistake. Some ESPs ask for confirmation in that case for exactly this reason.

Most paid newsletters run this way, because hardly anyone pays before they've read you. The free tier is how people get to know you.

The hard part is the split. Give away too little and the free version doesn't grow. Give away too much and nobody has a reason to pay. Common approaches: free weekly with a paid extra issue, free summaries with paid full analysis, or free content with a paid archive or community.

Free subscribers can also be valuable on their own, through sponsorship, which many freemium newsletters run alongside subscriptions.

Watch the conversion rate from free to paid over time, and look at which free subscribers upgrade. They're usually your most engaged readers, so keeping the free product good is what keeps the paid side growing.

People decide to open based on who it's from as much as what it says. So the from name should be something your readers instantly recognize, and it should stay the same from issue to issue.

There are a few common choices: your brand, a person, or a mix like "Jane at Brand". A person's name can feel more personal. A brand is clearer when the newsletter has several writers. What matters most is picking one and sticking with it, because changing it confuses people and can cost you opens.

The from address, the actual email address, should be consistent too, and on your own sending domain so it lines up with your authentication.

Avoid noreply addresses. Replies are one of the best signals you can get, and a noreply address throws them away.

GDPR consent has to be freely given, specific, informed and unambiguous. Pre-ticked boxes and silence don't count. You also need to be able to show when and how each person agreed, so keep signup records.

Email marketing itself is mainly covered by separate EU rules, the ePrivacy Directive (PECR in the UK). They require prior consent for marketing email to individuals, with a narrow exception for existing customers being sent similar products, as long as they can opt out easily.

Other things that matter for newsletters: people can object to direct marketing at any time and you have to stop, they can ask to see or delete their data, and your ESP counts as a data processor, so you need a proper agreement with them.

Fines can reach €20 million or 4% of worldwide annual turnover, whichever is higher. This isn't legal advice, so check with a lawyer.

Google doesn't actually publish the limit. 102KB is the number everyone works to, and Al Iverson's 2022 tests at Spam Resource found the real cutoff is a little above that, so staying under 102KB keeps you safe.

Only the HTML counts. Images load from a server, so they don't add to the size, but heavy template code and long tracking URLs on every link add up fast. A long issue in a bloated template is usually the culprit.

The cost is more than a hidden footer. Everything below the cut stays hidden until someone taps through, and that usually includes your unsubscribe link and postal address. If your ESP puts the open-tracking pixel at the bottom, a clipped email might not register an open either.

Check the HTML size before every send. Most ESPs and testing tools will show it.

For everyone sending to Gmail: SPF or DKIM, valid reverse DNS on your sending IPs, TLS, and a spam rate under 0.3%.

On top of that, bulk senders need:

• SPF and DKIM both, plus DMARC at least p=none, aligned with your From domain
• one-click unsubscribe on marketing and subscribed mail, plus a visible link in the email
• unsubscribes processed within 48 hours (Google) or two days (Yahoo)
• a spam complaint rate under 0.3%, and ideally under 0.1%

The rules haven't changed since 2024, but enforcement has. From November 2025, Google started actively deferring and rejecting mail that doesn't comply. Microsoft brought in similar rules for Outlook.com in May 2025, so treat this as the baseline everywhere.

You verify your domain with a DNS record, and once you're sending enough to Gmail, data starts showing up.

The current version, which replaced the original in September 2025, is built around the Compliance status page, which checks you against each of Gmail's sender requirements and includes a deliverability analysis. The spam rate dashboard is still the most useful number in there.

One thing that's gone: the old domain and IP reputation ratings (High, Medium, Low, Bad). A lot of older guides still tell you to watch them, but they aren't in the current version.

It only covers Gmail, and only once your volume is high enough, so a quiet dashboard doesn't always mean everything's fine. Set it up anyway. It's the closest thing you get to Gmail telling you what it thinks.

A lot of newsletter email ends up as graymail eventually. Someone signed up for a reason that's passed, and now your issue sits unread next to a pile of others.

It matters because mailbox providers watch how people treat your mail. If a big share of your list ignores you, your mail can start going to spam or a low-priority tab for everyone, including the readers who still want it. That's engagement-based filtering at work.

Some providers also make it very easy for people to clear out graymail, with one-tap unsubscribe suggestions and bulk-cleanup features. Which is fine: better they leave than sit there dragging your numbers down.

The fixes are the usual ones. Keep the newsletter worth opening, let people change frequency, and run a sunset policy so the long-term ignorers stop getting mail.

The idea is that a lot of spam software doesn't bother retrying, while proper mail servers always do. So the receiving server sends back a temporary 4xx error the first time it sees a new combination of sender and recipient, then accepts the email when it comes back later.

For a newsletter sender, it mostly shows up as a short delay and some soft bounces in your logs, especially to smaller company and university mail servers. Your ESP retries automatically, so the email usually arrives.

The only time it's a problem is if your sending setup doesn't retry properly, which is rare with any proper ESP. It's described in RFC 6647 if you want the full detail. Big mailbox providers don't really rely on it, but plenty of smaller servers still do.

Say you start the month with 20,000 subscribers, add 1,400 and lose 400. Your net growth is 1,000, so your growth rate is 5% for the month.

Look at the parts as well as the result. A list growing 5% from lots of signups and lots of churn is in a very different position from one growing 5% with barely any churn. And a big list needs a lot more signups just to stand still.

It's worth splitting new subscribers by source too. Signups from your own site, referral programs, paid ads and newsletter recommendations often behave very differently a few months later.

One more thing: removing inactive subscribers lowers your growth number, but it's often the right call. A list that's slightly smaller and actually reading usually does better.

The receiving server sends back a 5xx code, which is the SMTP family for permanent failures, often with something like 5.1.1 (bad mailbox). A soft bounce gets a 4xx code instead, meaning try again later: a full inbox, a server that's down, or a provider slowing you down.

Your ESP should suppress hard bounces automatically. Check it does, and check what it does with repeated soft bounces, because platforms handle those differently.

One thing to watch: not every 5xx means a dead address. Blocks for spam or failed authentication come back as permanent failures too, usually with 5.7.x codes. If your platform files those as hard bounces, you end up suppressing real subscribers over a reputation problem. Look at the actual codes before trusting the label.

A pile of hard bounces right after an import usually means an old or bought list.

It's one of the simplest ways to stop bot signups. Basic bots fill in every field they find, so they fall straight into it. Real people never see it, so it doesn't add any friction.

A few details matter. Hide it with CSS rather than making it a hidden input, since some bots skip those. Give it a believable name, like "website". Label it for screen readers too, telling them to leave it empty, and keep it out of keyboard tabbing so it doesn't trip anyone up.

It won't stop smarter bots, so it's a first layer rather than the whole answer. Combine it with rate limits, double opt-in, and a CAPTCHA only if things get bad, since CAPTCHAs put off real people too. A lot of ESP signup forms include a honeypot already.

The catch is that email HTML isn't web HTML. Email apps support far less, and each supports a different subset. Older versions of Outlook for Windows use Word to render emails, which is why layouts there often rely on tables and why some modern CSS just doesn't work.

That's why email templates look old-fashioned in code: table layouts, inline styles, and fallbacks for everything. Your ESP's builder handles most of it, which is a good reason to use it rather than hand-coding unless you know the quirks.

Always send a plain-text version alongside, which most ESPs do automatically. Keep the code lean, because bloated HTML is the main cause of Gmail clipping. And test in a rendering tool before you change your template.

It's less common in personal inboxes than it used to be, but plenty of work email setups still block images by default, and some readers switch images off for privacy or to save data.

Two things follow. First, design for it. Use real text for anything important, add alt text to meaningful images, and build buttons in HTML. An email that's mostly one big image becomes a blank rectangle.

Second, it affects tracking. Opens are recorded by a tiny image, so if images are blocked, no open is recorded, even if someone read every word. That's the opposite problem to Apple Mail Privacy Protection, which records opens that didn't happen. Between the two, open rates are a rough guide at best.

Test each issue with images off. It takes seconds.

The advice comes from a time when spammers sent emails that were one big image, so filters couldn't read the words. Some filters looked for that pattern, and the rule of thumb stuck.

What's actually true now: an email that's a single image with almost no text is still a bad idea. It can look suspicious, it disappears when images are blocked, screen readers can't read it, and AI summaries have nothing to work with.

But there's no magic percentage. A trusted sender with a well-designed, image-heavy newsletter will land in the inbox, and a poor sender with perfectly balanced text won't. Reputation and engagement decide it.

So the practical rule: put your words in real text, use images to support them, and don't count pixels.

Most lists carry a lot of these. They aren't doing you any favors: mailbox providers notice when a big share of your mail goes unread, and long-dormant addresses are how recycled spam traps end up on lists.

The tricky part is spotting them. Before Apple Mail Privacy Protection, "no opens in six months" was a decent rule. Now Apple Mail users can show opens they never made, so some inactive people look active.

Clicks are more reliable. A sensible approach: treat anyone with no clicks for a long stretch as inactive, unless they've done something else you can see, like replying or visiting your site. Treat Apple opens as unknown.

Then decide what to do. Usually that's a re-engagement campaign first, and a sunset policy for anyone who still doesn't respond.

The thing it gets confused with is delivery rate. Your ESP can show you 99% delivered while a good chunk went to spam, because "delivered" only means the receiving server accepted it.

Nobody can measure inbox placement exactly for your whole list, because mailbox providers don't report where each email went. The estimates come from two places: seed lists, where you send to test accounts and see where they land, and panel data from real users who've shared their inboxes with a vendor.

Both are useful for spotting a problem at one provider, and both have limits. In practice, a drop in opens and clicks concentrated at one provider is often the first clue you'll get, well before any report shows it.

It used to be the main thing filters looked at. These days domain reputation carries a lot of the weight, but a bad IP can still get your mail throttled or blocked before anyone looks at your domain.

On a shared IP, your ESP manages it, and their job is to keep bad senders off the pool. On a dedicated IP, it's all you, which is great when your sending is consistent and painful when it isn't.

New IPs have no reputation at all, and providers are wary of them. That's what IP warming is for. And an IP that goes quiet for a while can lose its standing, which is one reason sporadic senders are better off on a shared pool.

Start small and send to your most engaged readers first, the people who open and click every week. Their good reactions are what build the IP's reputation. Then increase volume over a few weeks, adding less engaged segments as you go.

Your ESP will usually give you a schedule, and it's worth following, though the exact numbers matter less than the principle: steady increases, good engagement, and backing off if bounces or deferrals spike.

Watch for 4xx deferrals and bounces at specific providers. If Gmail or Microsoft start pushing back, hold the volume where it is for a few days before going up again.

This only applies to a dedicated IP. On a shared IP, your ESP has already done it. If you're moving to a new domain rather than a new IP, the same idea applies there too.

It's a publishing word, borrowed from magazines, and it fits: each issue is a complete thing, sent on a schedule, building on the ones before.

A few habits help. Give each issue a consistent structure, so readers know where to find things. Keep an archive online, which helps new readers decide to subscribe and can bring in search traffic. And track performance by issue, since comparing one week with the last is often more useful than any average.

If you number issues, people notice when you skip one, so only do it if you'll keep going.

Pick a few that match what the newsletter is for, rather than tracking everything.

A sensible starting set:

• growth: growth rate and churn rate
• engagement: click-through rate and active subscribers
• deliverability: bounce rate and spam complaint rate
• money, if it's monetized: revenue per subscriber and paid conversion

Open rate can stay on the dashboard as a trend, but it's no longer reliable enough to be a main KPI since Apple's privacy changes.

Look at them over time rather than issue by issue, and compare against your own history rather than industry averages, which mix very different lists together.

It's where you send people from ads, social posts, podcast mentions and anywhere else you're asking for signups. A dedicated page usually converts much better than sending people to your homepage and hoping they find the form.

What makes a good one is pretty simple. A clear headline saying what they'll get. A sentence or two on who it's for. How often it arrives. A recent issue or a few sample headlines, so people can see what they're signing up for. And the form, near the top.

Keep the form short. Email address only is usually best. Every extra field loses people, so only ask for what you'll actually use.

Track signups by source, with UTM parameters on the links you share. The page that converts best isn't always the one that brings the best readers.

They work, sometimes very well. The catch is that people sign up for the freebie, not necessarily the newsletter. If the lead magnet is about something different from what you send every week, you get lots of signups who don't open much and leave fast.

So the best ones are a taste of what the newsletter is. If your newsletter is about email deliverability, a deliverability checklist brings in the right people. A generic "50 marketing templates" PDF probably doesn't.

Be upfront that signing up means getting the newsletter too, rather than burying it in small print. Deliver the thing straight away in the welcome email. And watch how lead magnet subscribers behave compared with people who signed up directly. If they drop off much faster, the magnet's attracting the wrong crowd.

The problem is the shared domain. Every link on a public shortener sits on the same domain, used by legitimate senders and spammers alike. If spammers have been using it, that domain can end up on a blocklist or get flagged by filters, and your links are caught along with it.

Hiding where a link goes also looks a bit like phishing, which filters watch for.

You don't really need one in a newsletter anyway. Your ESP already tracks clicks, and readers click link text, not the URL itself. If you want short, tidy links, use a custom tracking domain or a shortener on your own branded domain, so the reputation is yours.

The one place shortened links can make sense is plain-text emails, where the URL shows. Even then, a branded domain is the safer choice.

Your newsletter isn't the target. You're just one of the forms the bots happen to use. But your welcome email lands in the inbox of someone who's being attacked, and they're furious, so they mark everything as spam. That's complaints you did nothing to earn, apart from leaving your form open.

If you see a burst of signups in a few minutes, lots of them failing to confirm, or new addresses that complain straight away, you're probably being used.

The best defence is double opt-in, because the bots can't click the confirmation link. Beyond that: a hidden honeypot field, rate limits per IP, and a CAPTCHA if it keeps happening. Also make sure your confirmation email doesn't contain anything an attacker would find useful, like custom text they can inject. It should be plain and boring.

It's less a one-off cleanup and more a set of habits:

• suppress hard bounces and spam complainers automatically
• handle repeated soft bounces
• verify addresses at signup, or use double opt-in
• run a sunset policy so inactive subscribers don't sit there for years
• check imports against your suppression list before mailing them

Nobody enjoys making their list smaller. But a smaller list of people who read you will usually reach more inboxes than a bigger one padded with dead addresses. Mailbox providers judge you on how people react, and every unread email counts against you.

If you've never cleaned a list, don't go from zero to mailing everyone. Work out who's inactive first and treat them separately.

It's defined in RFC 2369 and holds a mailto address, a web address, or both. RFC 8058 added the one-click version: a second header, List-Unsubscribe-Post: List-Unsubscribe=One-Click, tells the mailbox provider it can unsubscribe the reader with a single request, no web page needed.

Since 2024, Gmail has required one-click unsubscribe on marketing and subscribed mail if you send more than 5,000 messages a day to Gmail addresses, plus a visible unsubscribe link in the email itself. Yahoo has the same rule for bulk senders. Google asks you to process unsubscribes within 48 hours, Yahoo within two days.

Most ESPs add both headers for you, but it's worth opening a raw message to check they're there. It's in your interest too: if someone can leave in one tap, they're less likely to hit the spam button instead.

You'll still see "ISP" used for the same thing. It's a hangover from when most people's email came with their internet connection. Mailbox provider is the more accurate term now.

It's also different from an email client. The mailbox provider stores the email and runs the spam filter. The client is just the app someone reads it in. Someone can have a Gmail account and read it in Apple Mail, and that combination is exactly where things like Apple Mail Privacy Protection come into play.

Each mailbox provider has its own filtering, its own rules and its own tools for senders. When something goes wrong, it's usually at one provider rather than all of them, so it's worth breaking your metrics down by provider.

Every ESP has its own syntax. You'll see things like {{first_name}}, *|FNAME|* or {$name}. They can pull in anything stored about a subscriber: name, city, signup date, plan, a referral link and so on.

The main thing that goes wrong is missing data. If someone never gave a first name, "Hi {{first_name}}" can turn into "Hi ," or even show the raw tag. Always set a fallback, like "Hi there", and preview the email as a subscriber with empty fields.

Merge tags also power practical things beyond names: a reader's own referral link, their account details in a paid newsletter, or the unsubscribe and preferences links your ESP adds automatically.

Test them before every send that uses them. A broken merge tag in a subject line goes out to everyone at once.

It's based on IP addresses rather than domains, which makes it most useful if you have a dedicated IP. On a shared IP, you usually can't register it, and the data would mix your mail with everyone else's anyway. Your ESP watches that side.

For each IP, it shows things like how much mail Outlook.com received, a color-coded status based on its spam filtering, complaint rates and spam trap hits. It's one of the few places a mailbox provider tells you directly about traps.

It sits alongside Microsoft's Junk Email Reporting Program, their feedback loop. If you're on a dedicated IP and sending to a lot of Outlook.com and Hotmail addresses, set up both. Together they're the Microsoft equivalent of Google Postmaster Tools.

When you hit send, your ESP's MTAs take each email, look up the recipient's mail server through its MX record, connect over SMTP and hand it over. On the other end, the mailbox provider's MTA accepts it, or rejects or defers it with a code.

They're also where a lot of deliverability work happens: retrying soft bounces, slowing down when a provider pushes back, signing mail with DKIM, and spreading sending across IPs.

For most newsletter senders, MTAs are invisible. You'll only think about them if you run your own sending infrastructure or work with an ESP that lets you configure how mail is sent. If you're reading bounce logs, the lines you see were written by MTAs talking to each other.

When your ESP sends an issue to someone at example.com, it looks up example.com's MX records to find the server to deliver to. If there's no MX record, or it points nowhere, the email bounces.

That's why domain checks in email verification look at MX records: an address at a domain with no working MX can't receive anything.

For your own setup, MX records matter in two places. Your sending domain should be able to receive replies, and bounces if your return-path uses it, so make sure it has working MX records. And if you send from a subdomain like news.yourbrand.com, check that replies to it actually go somewhere someone reads.

You rarely need to change MX records yourself unless you're moving email hosting. When you do, change them carefully, since mistakes stop all incoming email.

They come in a couple of forms. Marketplaces connect you with sponsors who then book directly, and you usually still approve each ad. Programmatic networks fill an ad slot automatically for each send, sometimes choosing a different ad per reader.

The appeal is obvious: revenue without having to find and manage sponsors yourself, which helps a lot for smaller newsletters.

The trade-offs: you earn less per placement than selling directly, you have less control over what appears, and some programmatic ads can look out of place, which readers notice. Many networks pay on clicks or impressions, so ask how they handle bot clicks and Apple's inflated opens.

A common approach is selling your best spots directly and using a network to fill the gaps.

Each model suits different newsletters. Sponsorship and ad networks work best when you have a focused audience advertisers want to reach. Paid newsletters work when readers value the content enough to pay directly. Selling your own products, like courses, events, reports or services, often earns the most per reader once you have trust.

Affiliate links, paid job boards, classified ads and paid community access come up a lot too.

Two numbers help you compare. Revenue per subscriber tells you what an average reader is worth now, and subscriber lifetime value tells you what they're worth over their time with you, which sets how much you can spend to get each one.

Whatever you choose, don't let it make the newsletter worse. Readers are the asset, and over-monetizing is a quick way to lose them.

The free version is a swap. You recommend newsletters you like, and they recommend you. It works best between newsletters with overlapping audiences.

Paid recommendations are a marketplace. You set a price per new subscriber, and other publishers recommend you in exchange for that fee. On beehiiv, for example, you're only charged once a referred subscriber passes a verification check. Other platforms have their own versions and rules, and they change often.

They can be a good growth channel, but quality varies. People who tick a few boxes on a recommendation screen are often less committed than people who came looking for you.

So track these subscribers separately. Check how many confirm, open and click after a few weeks, and compare the real cost per subscriber against what they're worth to you. Cut the sources that bring in people who never read.

It's one of the cheapest ways to grow, and it works because the recommendation comes from someone your new readers already trust.

The swaps that work best are between newsletters with similar audiences and similar sizes. If your list is a lot bigger, you're giving more than you get, though some people are happy to do that to help a newsletter they like.

Write the mention properly, in your own voice. A genuine "I read this every week and you might like it" works far better than pasting in the other newsletter's blurb.

Use a tracked link or a dedicated signup page for each swap, so you can see how many people it brought in and how they behave afterwards. Platforms with built-in newsletter recommendations are basically this, automated.

It works through the List-Unsubscribe header plus a second header, List-Unsubscribe-Post: List-Unsubscribe=One-Click, defined in RFC 8058. When someone clicks the provider's unsubscribe button, the provider sends a POST request to your unsubscribe URL and that's it, they're off.

The POST part is deliberate. Link scanners and security tools visit URLs with GET requests, so if a simple link visit unsubscribed people, scanners would be unsubscribing your readers for you. Make sure your unsubscribe endpoint only acts on the POST.

Gmail has required it since 2024 for anyone sending over 5,000 messages a day to Gmail users, and asks you to process unsubscribes within 48 hours. Yahoo says two days. Don't ask people to log in, confirm, or "update preferences" first.

Opens are tracked with a tiny invisible image. When it loads, your ESP records an open. That was always a bit rough, because people who block images were never counted.

Then Apple Mail Privacy Protection arrived in 2021. Apple Mail now loads images in the background for users who have it switched on, so those emails show as opened whether anyone read them or not. If a big chunk of your list uses Apple Mail, your open rate is inflated, sometimes a lot.

So use open rate for trends on the same list rather than as a real count of readers, and don't compare it to benchmarks from before 2021. For anything important, like judging subject line tests or deciding who's inactive, lean on clicks and replies instead.

It comes in two main flavors. Single opt-in adds people as soon as they submit the form. Double opt-in makes them confirm by clicking a link first.

What counts as a proper opt-in matters, both for deliverability and legally. Under rules like GDPR and CASL, the person has to clearly agree. A pre-ticked box, or signing someone up because they bought something, often doesn't count, depending on where they are.

The practical rule is simple: people should know they're signing up for a newsletter, roughly what they'll get, and how often. Opt-ins hidden in a checkout or a giveaway form tend to produce complaints later.

Keep a record of how and when each person signed up. If you're ever asked to prove consent, or you're debugging a complaint spike, it's very useful to have.

Every major law requires you to honor opt-outs, with deadlines. CAN-SPAM and CASL both give you up to 10 business days. Gmail asks bulk senders to process unsubscribes within 48 hours, and Yahoo within two days, which is effectively the deadline that matters if you want to reach those inboxes.

In practice, make it instant. Your ESP should remove people the moment they click, and add them to your suppression list so they're never re-imported by mistake.

The second meaning, opt-out systems, is where people are added unless they say no, like a pre-ticked box. In the US that's legal for commercial email. Under GDPR it doesn't count as consent. For newsletters it's a bad idea anywhere, because people who didn't choose to subscribe are the ones who complain.

The rules line up closely with Gmail and Yahoo's. You need SPF and DKIM passing for your domain, and DMARC at least at p=none, aligned with SPF or DKIM. Microsoft says preferably both, and recommends p=reject eventually.

If you don't comply, your mail goes to junk first, and if it isn't fixed, it may be rejected with this error: 550; 5.7.515 Access denied, sending domain does not meet the required authentication level. If you see that in your bounce logs, it's this rule.

This only covers Microsoft's consumer email. Business Microsoft 365 mailboxes are filtered differently, often with extra security tools on top.

If you've already done the work for Gmail and Yahoo, you're probably covered. Microsoft also offers SNDS for IP-level data.

The model is simple: write something people value enough to pay for, and keep delivering it. The free tier is usually the growth engine. People read for free, get to know you, and some upgrade.

A few numbers matter most. How many free readers convert to paid, how many paid subscribers cancel each month, and how much each paid subscriber is worth over time. Small changes in cancellations make a big difference to revenue.

What people pay for varies. Some paid newsletters offer more issues, some offer exclusive analysis, some offer community or access. It works best when the paid version is clearly different from the free one. "The same, but more often" is a hard sell.

Deliverability matters even more here. A paying subscriber who stops getting your emails is more likely to cancel than to tell you. That's a good reason to watch paid subscribers' engagement separately.

Where you put it is the big decision in a freemium newsletter. Some common setups: some issues free and some paid, every issue free but cut off partway through for free readers, or all new issues free with the archive paid.

A cut-off partway through an issue is popular, because readers get a real taste before the ask. The risk is annoying people who just wanted the whole thing. Make it obvious before they start reading whether a piece is paid.

For SEO, paid web posts are a balance. Search engines can't rank what they can't see, so many publishers show a free preview of paid posts on the web.

Whatever you choose, keep the paywall in the same place consistently. Readers get frustrated when they can't predict what's free.

The basic version is inserting a first name with a merge tag. It's fine, but readers know it's automatic, so on its own it doesn't do much. And when the data's wrong, you get "Hi FNAME" or "Hi Unknown", which looks worse than no name at all. Always set a fallback.

The more useful kind is about content: different stories, sections or recommendations based on interests, location or reading history. That's where personalization starts to matter, because each reader gets more of what they want.

The trade-off is complexity. More versions mean more testing and more ways for something to go wrong. Start with one or two things that clearly matter to readers, like topics they picked or local content, before building anything elaborate.

It works best with good data, so it pairs naturally with segmentation and a preference center.

Filters look for the patterns phishing uses: urgent warnings, login or payment requests, link text that doesn't match where the link goes, lookalike domains, and brand names used by senders who aren't those brands.

Real newsletters trip these filters more often than you'd think. Some common causes: a link whose text shows one URL but goes to another through tracking, emails about "your account" or "action required", links to newly registered domains, or a from name that doesn't match the sending domain.

The fixes are mostly about being consistent and plain. Send from your own authenticated domain, use a custom tracking domain, make link text describe the destination rather than show a different URL, and avoid alarmist wording when there's nothing alarming.

And protect your readers: DMARC at enforcement stops others phishing them using your exact domain.

Most email is sent as "multipart": one HTML version and one plain-text version in the same message. The reader's app picks whichever it can show. Your ESP usually generates the text version automatically, but it's worth checking, because auto-generated versions can be a mess of long URLs.

Some newsletters send entirely plain-text, or very simple HTML that looks like plain text. It feels personal, loads instantly, and has no rendering problems. The downsides: no images or layout, and with no HTML there's no tracking pixel, so you lose open data.

You'll hear that plain-text emails get better deliverability. There's some truth to it, because simple emails look more like personal mail, but it's mainly reputation and engagement that decide where you land. Pick the format that suits your content, not to dodge filters.

There's a reason so many sites use them: popups tend to bring in a lot more signups than a form sitting in a sidebar. The trick is not making readers hate you for it.

Some common-sense rules. Don't show it the moment someone arrives. Let them read first, and trigger it after a scroll or when they're leaving. Don't show it to people who've already subscribed or closed it recently. Make the close button easy to find.

Be careful on mobile. Google warns that pop-ups covering the content can hurt how your pages perform in search, and suggests small banners rather than full-page overlays.

Slide-ins and banners are gentler options. They take up less space and still get noticed.

As with any form, track the people it brings in. Popup subscribers sometimes engage less than people who sought out your form.

For publishers with more than one newsletter, they're really useful. Someone who's tired of your daily might happily keep your weekly, and a preference center gives them that choice.

Two rules though. First, it must never stand in the way of leaving. Your unsubscribe link should unsubscribe. You can offer preferences on the page afterwards, or as a separate link, but don't make people choose options before they can go. Gmail and Yahoo require one-click unsubscribe for bulk senders anyway.

Second, only offer choices you'll actually honor. If someone picks "weekly only" and still gets the daily, that's a complaint waiting to happen.

Keep it short. Most people want a couple of checkboxes, not a long survey.

If you don't set it, the inbox grabs whatever text comes first in your email. That's often "View in browser" or "Having trouble reading this email?", which wastes the space.

So set it every time. It's basically a second subject line, so use it to add something the subject doesn't say. A subject that sets up the main story and a preheader that adds a second reason to open is a solid pattern.

How much shows depends on the inbox, the device and how long your subject line is, so put the important bit first. Most ESPs have a preheader field. If yours doesn't, add hidden text at the very top of the email.

One gotcha: if your preheader is shorter than the space available, some inboxes fill the rest with whatever comes next in the email. A bit of invisible padding after it stops that.

People panic about it, and mostly they don't need to. An email in Promotions has been delivered to the inbox. It's not the spam folder, and readers who want you will find you there. Plenty of people check it regularly.

What it does affect is visibility. You're competing with sales emails rather than messages from friends, so opens can be lower than if you'd landed in Primary.

Be careful with tricks to "beat" the tab, like stripping out images or making the email look personal. Gmail sorts based on lots of signals, and making your newsletter worse to dodge a tab is a bad trade.

The one thing that does work is asking readers. If someone drags your email to Primary and confirms, Gmail remembers that for them. A line in your welcome email asking new subscribers to do that is worth having.

It goes wrong in a few predictable ways. Bought lists are full of old and invalid addresses, so you get a wave of hard bounces. They often contain spam traps, especially the pristine kind that only end up on scraped or traded lists. And the real people on them never asked to hear from you, so they complain.

Most ESPs ban them in their terms, and will suspend accounts that send to them. Laws like GDPR and CASL require consent you can't get second-hand, and Canada's regulator has fined a company that couldn't show consent for a list it bought.

Renting a list where the provider "sends on your behalf" has many of the same problems. If you want to reach another audience, sponsor a newsletter they actually signed up for, or do a newsletter swap.

The point isn't really to win everyone back. Most won't come back, and that's fine. The point is to find out who still cares before you remove the rest.

Keep it simple: two or three emails over a few weeks. Say plainly that you'll stop emailing them unless they click to stay, and make that click easy. A short reminder of what they've been missing can help, but skip guilt trips and fake urgency.

Use clicks as the signal, not opens. Apple Mail Privacy Protection means an "open" can happen without the person ever seeing the email.

Then follow through. People who click stay; everyone else gets suppressed under your sunset policy. Sending to a big inactive segment can cause a spike in bounces and complaints, so it's worth sending to it in smaller batches.

It's measured with tracking images too, by checking how long the email stays open. That's clever, but it has the same weaknesses as opens. Apple Mail Privacy Protection loads images automatically, which muddies the timings, and blocked images mean nothing gets measured at all.

Treat it as a rough signal for comparing your own issues, not a precise measure. If one format consistently gets longer read times than another on the same list, that's interesting. The absolute numbers aren't worth much.

For a different kind of read-time number, many newsletters show an estimated reading time at the top of each issue, based on word count. That's not a metric, just a courtesy to readers.

Done well, it brings in good readers, because a recommendation from a friend is about the best signup source there is. People referred by someone they trust tend to read more than people who came from an ad.

It can also go badly. If the rewards are too good, people game it: fake signups, throwaway addresses, or friends signing up just to help out. Then you're paying rewards for people who'll never open an email.

A few things help. Count a referral only once the new subscriber confirms, so use double opt-in or at least check for a first open or click. Keep the first rewards small, and save the bigger ones for people who refer a lot. And watch referred subscribers over time.

Most newsletter platforms have referral tools built in, so you rarely need to build one.

The usual troublemakers are older Outlook for Windows, which renders with Word and ignores lots of modern CSS, Gmail, which strips some styles, and dark mode handling, which varies everywhere.

Rendering tests show you screenshots of your email across dozens of apps and devices before you send. They're worth running whenever you change your template, add a new type of section, or see readers reporting problems. You don't need them for every regular issue sent from a tested template.

Your ESP's preview is a good start but not the full picture, since it usually shows only how a browser displays the email.

Check your ESP's reports to see which apps your readers actually use, and focus testing there. Making an email perfect in an app nobody on your list uses is wasted effort.

Most ESPs don't track it automatically, since replies go to your inbox rather than through the platform. You can count them roughly yourself, or use a reply-to address that forwards into something you can measure.

It's worth the effort, because replies are a strong positive signal. Someone who replies is clearly a real reader, and mailbox providers are generally understood to treat a two-way conversation as a sign the mail is wanted.

So it's worth encouraging. Ask a simple question at the end of an issue, invite replies in the welcome email, and actually read them. Replies are also the best source of ideas you'll get.

One practical point: don't send from a noreply address. It throws away all of this, and readers who try to reply get a bounce.

It used to be a reliable trick to get a few more opens out of an important email. The problem now is Apple Mail Privacy Protection. Many Apple Mail users show as "opened" whether they read the email or not, so they're left out of the resend even if they never saw it. Meanwhile, people who block images get resent an email they already read.

There's also a cost. Sending people the same email twice can increase unsubscribes and complaints, and repeated unopened mail doesn't help your reputation.

If you do it, keep it for genuinely important emails, not every issue. Use "didn't click" as the filter rather than "didn't open". Change the subject line properly, and leave a day or two in between.

Most newsletter templates are responsive out of the box now, but it's still worth checking, especially for anything custom.

There are two main approaches. "Mobile-first" or fluid layouts are built narrow and simple so they work everywhere, even in apps that ignore media queries. Media-query layouts change at certain screen widths, which gives more control but depends on the email app supporting them.

For newsletters, simpler usually wins: a single column, generous text size, buttons big enough to tap, and images that scale down. Multi-column layouts look nice on desktop and often cause the problems on mobile.

Always test on a real phone or in a rendering tool. Gmail's apps, Outlook and Apple Mail all handle layout differently, and what looks fine in your ESP's preview can break on a small screen.

Every email has two sender addresses. The From address is what readers see. The Return-Path, set during the SMTP conversation as MAIL FROM, is what servers use to send bounces back. They're often different.

By default, your ESP uses its own domain for the Return-Path, so it can process your bounces. That's why SPF passes for your ESP rather than you, and why SPF on its own often doesn't help your DMARC.

The fix is a custom Return-Path: a subdomain of yours, like bounces.yournewsletter.com, pointed at your ESP with a DNS record. Then SPF passes for your domain and counts towards alignment. Most ESPs set this up alongside DKIM.

You can see it in any email's headers. The Return-Path line shows which domain bounces go to.

Say your newsletter makes $12,000 in a month and has 40,000 subscribers. That's $0.30 per subscriber per month, or $300 per thousand (RPM).

It's useful because it puts very different newsletters on the same footing. It also tells you what growth is worth: if each subscriber earns $0.30 a month, you know roughly what a new one adds.

Be clear what you're dividing by. Using total subscribers looks lower than using active subscribers, so state which one you mean when comparing or sharing numbers.

It's a snapshot. For deciding how much to spend on growth, look at subscriber lifetime value, which adds up what a subscriber earns over their whole time on your list.

Normal DNS goes from a name to an IP. Reverse DNS goes the other way. Mail servers use it as a basic sanity check: a legitimate sending IP should have a PTR record pointing to a hostname, and that hostname should point back to the same IP.

Google's sender guidelines require valid forward and reverse DNS for sending IPs from everyone sending to Gmail. Mail from IPs without it is more likely to be rejected or filtered.

If you're on an ESP, especially on a shared IP, they handle this for you. It only becomes your job if you have a dedicated IP that your ESP has asked you to configure, or you run your own mail servers. The PTR record is set by whoever controls the IP, usually the hosting provider, not in your normal domain DNS.

They're risky on a newsletter list for a few reasons. Several people may receive your email, and only one of them signed up, so the others are more likely to mark it as spam. Some are monitored by IT or abuse teams who report anything they don't recognize. And some aren't read at all.

That doesn't mean you have to block them. Lots of small businesses run everything through info@ and genuinely want your newsletter there.

A middle ground works well: allow them, but use double opt-in so you know someone at that address really asked, and watch their engagement and complaints. Many ESPs and email verification tools flag role addresses, so you can decide how to treat them.

For publishers, it's a simple way to send a daily or weekly digest of new articles without building each issue by hand. The ESP checks your feed on a schedule, pulls in anything new, drops it into a template and sends it.

It's great for keeping regular readers updated cheaply. The downside is that it reads like what it is: an automatic list of links. Engagement tends to be lower than a newsletter someone actually wrote, and it can turn into graymail over time.

A common middle ground is to use the automated feed for the list of stories, and add a short written intro or a "best of the week" pick by hand. It doesn't take long and makes the email feel a lot more alive.

Check how your feed looks in the template first. Missing images and cut-off excerpts are common.

Inbox placement tools give you a list of seed addresses at Gmail, Outlook.com, Yahoo and others. You include them in your send, and the tool reports where each one landed.

It's handy for spotting a problem at a specific provider, testing a new template or domain, or checking things after a big change like moving ESP.

It has real limits, though. Seed accounts don't open, click or reply, and they don't have years of history with you, so they don't get the personalized filtering your real readers get. Gmail in particular filters a lot based on each user's own behavior. So a seed test can show spam when your engaged readers are fine, or inbox when your inactive ones aren't.

Treat seed results as a warning light, not a score. Check them against what your real numbers are doing.

For a newsletter, the most useful segment is usually engagement. Sending your best content and any risky sends to your most active readers first, and holding back on people who haven't clicked in months, does more for deliverability than anything clever.

After that, it depends what you publish. Topic preferences, location for time zones or local content, paid vs free, and where people signed up all come up a lot.

Don't overdo it. Lots of tiny segments mean more versions to write and test, and more chances to send the wrong thing to the wrong group. A handful of segments you'll actually use beats twenty you set up once.

One warning: segments based on opens are shaky since Apple Mail Privacy Protection. Build engagement segments on clicks, replies and site activity where you can.

There isn't a magic number. Plenty of daily newsletters do brilliantly, and plenty of monthly ones do too. What matters is that the frequency matches what people signed up for, and that every issue is worth opening.

Problems usually come from changes. Suddenly sending more often than people expected tends to cause unsubscribes and complaints, especially from people who signed up a while ago and have half-forgotten you. If you're increasing frequency, tell readers first, and consider letting people pick through a preference center.

Going quiet is also a risk. If you disappear for months and then come back, many readers won't recognize you, and mailbox providers have little recent history to judge you on. Start again gently, with your most engaged readers.

Consistency helps everything: habits, open patterns and your sender reputation.

Instead of picking one send time, the platform spreads delivery over a day, sending to each person at the hour they've usually opened or clicked before.

It can help, but the gains are often modest, and a few things limit it. It needs good engagement history to work, so new subscribers get a default time. And if it's based on opens, Apple Mail Privacy Protection muddies it, since Apple opens happen when the email arrives, not when someone reads it.

For many newsletters, a consistent send time matters more. Readers build a habit around a daily that arrives at 6am. Spreading it out can break that, and it's a problem for anything time-sensitive.

If you want to try it, run it as an A/B test against your usual time and judge it on clicks.

It's really several reputations rolled together. Your domain reputation and IP reputation are the main ones, and each provider keeps its own version. Gmail's view of you might be quite different from Microsoft's.

What builds it is pretty simple, even if it takes time: people who asked for your email, read it, and don't complain. What damages it: spam complaints, spam traps, lots of bounces, and mailing people who stopped engaging ages ago.

It's slow to build and quick to lose. One bad send to an old list can undo months of good behavior, and recovering usually means sending less, to your best readers only, for a while.

There are third-party scores out there, but they're each vendor's estimate. The score that matters is the one inside each provider, and you never see it directly.

You can look up any IP at senderscore.org. Higher is better, and a falling score is a decent early warning that something's wrong with mail from that IP.

Keep it in perspective, though. It's Validity's own estimate, built from the providers in its data network. Gmail, Microsoft and Yahoo each keep their own reputation for you, and none of them use Sender Score to decide where your email lands.

It also only covers IPs. If you're on a shared IP, the score reflects everyone on it, so it tells you more about your ESP than about you. These days domain reputation does a lot of the work anyway.

So check it now and then, especially if you're on a dedicated IP, but use Google Postmaster Tools and SNDS for the providers that matter most.

Whatever domain you send from builds its own domain reputation, and it needs its own SPF, DKIM and DMARC setup.

Using a subdomain for newsletters has a couple of advantages. If a newsletter ever gets into reputation trouble, your main domain, the one your staff email and password resets come from, is a bit more protected. It also lets you set a different DMARC policy for the subdomain while you're getting things in order, using the sp= tag.

It's not a magic wall, though. Providers can still connect subdomains to the main domain, so a subdomain won't save you from bad habits.

The bigger rule: pick one and stick with it. Switching sending domains regularly looks like someone trying to outrun a bad reputation, and new domains need warming up just like new IPs.

This is where most newsletters live, and for good reason. Decent ESPs keep their shared pools clean, warm and busy, so you get a reputation you'd struggle to build alone, without having to manage it.

The downside is that you're sharing with other senders. If someone on your pool sends to a bad list, it can affect your delivery, and you can't do much about it except tell your ESP. Good ESPs watch for this and move problem senders off quickly.

These days your domain reputation does a lot of the work anyway, so the shared vs dedicated question matters less than it used to. If you're sending a weekly newsletter to a list that isn't huge, a shared IP is almost always the right call. See dedicated IP for when it isn't.

The basics matter more than any trick. Say clearly what they're signing up for and how often it arrives. Ask for as little as possible, since every extra field costs you signups. Make the button say what it does, like "Subscribe", rather than something vague.

Put it where people are already reading. The end of an article, a landing page, and a footer form all work. A popup form usually brings in the most, if it's done politely.

Behind the scenes, protect it from bots. A honeypot field, rate limits and ideally double opt-in keep your list clean and stop list bombing.

If you have any readers in places with strict consent rules, be clear that they're signing up for a newsletter, don't pre-tick anything, and keep a record of when each person subscribed.

It's simpler and you'll grow faster, because nobody gets lost between submitting the form and clicking a confirmation email.

The trade-off is quality. Typos go straight onto your list and bounce. Anyone can enter someone else's address. And your form is wide open to bot signups and list bombing, which means sending welcome emails to people who never asked and collecting their complaints.

Plenty of newsletters run single opt-in successfully, so it's not wrong. But if you do, put the protections in place: a honeypot field, rate limits, verifying addresses at signup, and watching new subscribers closely. If someone hasn't opened or clicked anything after the first few emails, stop sending to them sooner rather than later.

If you're seeing bot problems or complaints from new subscribers, switching to double opt-in is the quickest fix.

Every email you send goes from your ESP's server to the recipient's server over SMTP. The receiving server replies with a numbered code at each step. 2xx means fine, 4xx means try again later, and 5xx means no.

Those codes are where soft bounces and hard bounces come from. When you're working out why mail isn't getting through, the exact code and the text after it are usually the most useful thing you'll find. Something like 550 5.7.1 with a message about policy tells a very different story from 550 5.1.1 about an unknown user.

For most newsletter people, SMTP is something your ESP handles. You'll only touch it directly if you're sending from your own systems, connecting an app to your ESP's SMTP relay, or reading bounce logs.

Soft bounces come back with a 4xx SMTP code, which basically means "not now, try later". The sending server retries for a while, and a lot of them do go through in the end.

Two things to watch. First, repeated soft bounces to the same address often mean the mailbox is abandoned. Most ESPs eventually treat these as hard bounces, but the rules differ, so check yours.

Second, deferrals are often a reputation signal. When a provider's unhappy with you, it doesn't always reject your mail outright. It slows you down with 4xx codes first. Google said in November 2025 that non-compliant senders would see more of exactly this. So a sudden wave of soft bounces at one provider is worth looking into, not just waiting out.

It's the number mailbox providers care about most, because it's readers telling them directly that they didn't want your email.

The catch is how it's calculated. Google and Yahoo both count complaints against mail that reached the inbox, not everything you sent. So 0.3% is tighter than it sounds, and it only takes a few hundred complaints on a big send to go over. You can see Gmail's version in Postmaster Tools.

Your ESP's own complaint rate won't match exactly, because Gmail doesn't report individual complaints back.

The usual causes are people who forgot they signed up, emails that arrive more often than people expected, and an unsubscribe link that's hard to find. Making it easy to leave is the fastest fix. Someone who can unsubscribe in one click has no reason to hit spam instead.

Modern filters look at a lot of things at once: who sent it, whether it's authenticated, what the sending domain and IP's history looks like, the links and domains inside it, and how people have reacted to similar emails.

At Gmail especially, a lot of it is personal. The same newsletter can land in one reader's inbox and another reader's spam folder, depending on how each of them has treated your emails before.

That's why the old advice about spam trigger words mostly misses the point. Content can still hurt you, like links to a blocklisted domain or something that looks like phishing, but for a legitimate newsletter the filter is mainly asking whether people want your email.

If you're landing in spam, start with complaints, bounces and old inactive subscribers, not the copy.

There are three main kinds, and each one points at a different problem.

• Pristine traps never belonged to a real person. They only get mail if someone scraped, bought or guessed the address, so a hit says something about where your addresses come from.
• Recycled traps used to be real mailboxes. The provider shut them down and later turned them into traps, so mail to them means you're still emailing people who left ages ago.
• Typo traps sit on misspelled domains like homail.com. Spamhaus says these get a lot of real mail and are weighted with that in mind.

You can't spot traps by looking at your list, and Spamhaus says don't try. Fix the source instead. Double opt-in keeps typos and bot signups out, and a sunset policy stops old addresses turning into recycled traps.

This advice comes from early spam filters that really did score individual words. Modern filters at Gmail, Microsoft and Yahoo rely mainly on reputation, authentication and engagement. A trusted sender can write "free" in the subject line and land in the inbox.

That doesn't mean content never matters. Things that do still cause problems:

• links to domains that are on a blocklist
• link text that doesn't match where the link goes
• emails that look like phishing, like fake invoices or urgent account warnings
• big images with almost no text

So write normally. The long "never use these 400 words" lists out there aren't worth following, and twisting your copy to avoid them usually just makes it worse. If you're going to spam, the cause is almost always your list or your reputation.

It runs several lists. The main ones are the SBL for known spam sources, the XBL for hijacked and infected machines, the PBL for IP ranges that shouldn't be sending email directly, and the DBL for domains, including domains that appear in links.

That last one matters for newsletters. If a domain you link to is on the DBL, your email can be filtered even if your own setup is perfect.

Spamhaus mostly lists senders because of spam traps and patterns of unwanted mail, not individual complaints. You can check whether you're listed, and request removal, through its free lookup tool. Removal usually needs you to fix the cause first.

Its sender guidelines are worth reading too. They're straightforward: confirmed opt-in, honest signup, easy unsubscribe, and stop mailing people who don't engage.

It's a TXT record that looks something like v=spf1 include:_spf.youresp.com -all. Each include adds another service that sends for you.

The catch most people don't expect: SPF checks the hidden return-path domain, not the From address your readers see. Your ESP usually uses its own return-path, so SPF passes for them, not you. That's why you set up a custom return-path if you want SPF to count towards DMARC alignment.

The other trap is the 10 DNS lookup limit. Every include costs at least one lookup, and once you've added your ESP, Google Workspace, your CRM and a couple of tools, you can go over without noticing. Then SPF fails for everything. Also, SPF breaks when an email is forwarded, which is why DKIM matters more.

The usual formats are a primary spot near the top, a secondary spot lower down, a classified-style text ad, or a dedicated email entirely about the sponsor. Pricing is often per issue, often based on CPM, and sometimes per click.

The ads that work best read like part of the newsletter. Many publishers write them in their own voice, or edit the sponsor's copy so it fits. Readers can tell, and they respond better to something that sounds like you.

Be clear it's sponsored. Label it as an ad or sponsored content. In the US, the FTC expects you to make advertising clear, and readers trust you more for it.

Advertisers will want numbers. Report clicks along with whatever you priced on, and be honest about opens: Apple Mail Privacy Protection inflates them, and good sponsors know it.

How much of it shows depends on the app, the device and the screen, and phones show a lot less than desktops. So put the important words first. If the start of the subject makes sense on its own, it doesn't matter where it gets cut off.

For newsletters, clear usually beats clever. Say what's inside, or lead with the most interesting thing in the issue. Readers who know what they're getting open more consistently over time, even if a curiosity-bait subject wins the odd test.

Avoid anything misleading. It's against CAN-SPAM, and it damages trust, which shows up as complaints later.

Testing subject lines is worthwhile, but judge tests on clicks rather than opens, because Apple's privacy changes make opens unreliable. See A/B testing. And with AI summaries appearing in more inboxes, the subject may not be the only thing readers see.

You'll see it in your numbers before anyone tells you. Clicks per issue fall, unsubscribes creep up, and complaints rise, often after you've added extra sends or promotions.

It's more common than people think when a newsletter starts adding things on top of the regular issue: sponsor emails, product launches, a new daily alongside the weekly. Each one seems fine on its own, but together they're a lot of email.

A few things help. Let readers choose what they get through a preference center. Send extra emails only to the segments most likely to want them. And give everyone a break from time to time.

It's also worth looking at the newsletter itself. If every issue feels the same, a format change can win people back better than sending less.

A simple version: average monthly revenue per subscriber × average number of months a subscriber stays. If each subscriber brings in $0.30 a month and stays about 20 months, your LTV is about $6.

How long people stay comes from your churn rate. If you lose 5% of subscribers a month, the average subscriber stays roughly 20 months (1 ÷ 0.05).

The main use is comparing it with cost per subscriber. If it costs $2 to get a subscriber worth $6, that channel's worth scaling. If it costs $8, it isn't.

Work it out by source if you can. Subscribers from different channels often stay for very different lengths of time, so one overall average can hide a channel that's losing you money. And treat it as an estimate, since both revenue and churn change over time.

Honestly, the bigger risk is not having one at all. Addresses that sit there unread for years are how lists end up full of recycled spam traps, and sending to people who never open or click doesn't do your reputation any favors.

You need to decide how long counts as inactive, what you'll send before giving up, and what happens to the address afterward. Suppress it rather than deleting it, so it can't get re-imported by accident. There's no single right window. A daily newsletter can judge someone much sooner than a monthly one, so base it on how often you send.

The tricky bit since Apple Mail Privacy Protection is working out who's actually inactive. Apple opens fire automatically, so someone who hasn't looked at you in a year can still look engaged. Use clicks where you can, and treat machine opens as no signal either way.

Every ESP keeps one, and it's one of the most important things in your account, even though you rarely look at it.

The big one to remember: when you switch ESP, bring your suppression list with you. If you only export your active subscribers, everyone who unsubscribed, bounced or complained gets mailed again from the new platform the moment someone imports an old file. That's a quick way to rack up complaints and hit spam traps, and in a lot of countries mailing people who unsubscribed is also against the law.

Same goes for any list you import from elsewhere, like an event signup sheet. Check it against your suppressions before sending.

Keep suppressed addresses rather than deleting them. A deleted address can come back in. A suppressed one can't.

Open rate is normally based on unique opens, since what you want to know is how many people opened. Total opens can be interesting, like spotting an issue people kept going back to, but it's easily skewed by one person opening over and over.

Both have the same underlying problem now. Opens are recorded when a tiny tracking image loads, and Apple Mail Privacy Protection loads it automatically. So a unique open from an Apple Mail user might not be a person at all. Image blocking works the other way, hiding real opens.

Use unique opens for rough trends on the same list rather than as a precise count of readers. For anything that drives decisions, unique clicks are more reliable.

Nobody likes seeing it go up, but unsubscribes are healthy. They're people leaving without a fuss, which is far better than the alternative: staying on your list and ignoring you, or hitting the spam button. A spam complaint hurts your reputation. An unsubscribe doesn't.

So don't make leaving hard. Hidden links, tiny grey text and "are you sure?" pages just push people towards the spam button. Gmail and Yahoo now require one-click unsubscribe from bulk senders anyway.

Watch for spikes after particular sends. A jump usually tells you something specific: a send that went out more often than people expected, an off-topic promotion, or an old segment that got mailed. If one type of email keeps causing them, that's worth more attention than the overall number.

The main three are utm_source (where the link was, like your newsletter's name), utm_medium (the type of channel, usually email) and utm_campaign (which issue or campaign). There's also utm_content for telling apart different links in the same email, and utm_term.

Most ESPs can add them automatically. The thing that goes wrong is inconsistency. If one issue uses Newsletter, the next newsletter and the next email-weekly, your reports split into a mess. Pick a naming scheme, write it down, and stick to it.

For newsletters, utm_content is underrated. Tag each link with its position or story, and you'll learn which parts of the email actually get clicked.

Keep UTMs off links to other people's sites unless you have a reason. They're for your own analytics.

It's usually the most-read email you'll ever send, because people have just signed up and are expecting it. So it's worth getting right.

Send it straight away. Say what they'll get and how often, deliver anything you promised, like a lead magnet, and point them at a few of your best pieces. Asking them to reply, even just to say what they want to read about, is a good idea, because replies are a strong positive signal to mailbox providers.

It's also the place to ask Gmail users to move you to their primary inbox if you're landing in the Promotions tab.

A sequence of three to five emails over the first week or two works well for a lot of newsletters. Keep each one short and useful, and stop if they unsubscribe or start getting regular issues.

It's different from what you work out by watching behavior, like clicks or site visits. Zero-party data is people telling you, so it's usually more accurate and you don't have to guess.

For a newsletter, the useful bits are topics people care about, how often they want to hear from you, and anything that helps you tailor content or sponsors, like their role or industry.

The easiest places to collect it are the signup form, the welcome email and a preference center. A one-question survey in an issue works too, especially as a link people can click.

Only ask for what you'll actually use, and use it visibly. If someone tells you they only care about one topic and keeps getting everything, they'll stop telling you things. And remember it's still personal data, so laws like GDPR apply.