Category: Newsletters

Newsletter referral programs look simple: existing subscriber shares your newsletter, someone new signs up through their link, original subscriber gets credit. But the mechanics under the hood reveal a design choice that changes how you should think about rewards, milestones, and fraud prevention.

Most platforms—including Beehiiv, Sparkloop, and UpViral—credit the referrer at the moment of the share action or initial click, not when the new subscriber confirms their email or becomes active. That’s not an oversight. It’s a deliberate trade-off between attribution accuracy and user experience.

Why platforms credit the share, not the conversion

If a platform waits to credit the referrer until the new subscriber confirms their email, you introduce a 24-to-48-hour delay before the referrer sees any progress toward their reward. That delay kills momentum. People share once, see no movement on their dashboard, and assume the system isn’t working.

Crediting the share immediately gives the referrer instant feedback. They see their count tick up within seconds. That dopamine hit encourages them to share again.

The downside: you’re counting referrals that never convert. If someone shares your newsletter and ten people click but only three confirm their email addresses, the referrer gets credit for ten. Your dashboard shows ten referred subscribers, but your email list only grows by three.

Beehiiv‘s referral system, for example, increments the referrer’s count when someone lands on the signup page via their unique link and submits an email address—before double opt-in confirmation. If that person never clicks the confirmation email, Beehiiv doesn’t automatically deduct the referral credit. You’re left with inflated referral counts and a smaller list than your referral leaderboard suggests.

What this means for milestone design

If you’re running a referral program with tiered rewards—get five referrals, unlock a PDF; get 25, get a one-on-one call—you need to account for the gap between credited referrals and confirmed subscribers.

A conservative multiplier: assume 60-70% of credited referrals will actually confirm and stay active. If you want someone to genuinely deliver 25 new subscribers to your list, set the milestone at 35-40 credited referrals. That’s not padding—it’s compensating for the way the system counts.

Some operators do the opposite. They set lower thresholds and accept that referral credits overstate real growth. The logic: referral programs are about engagement and word-of-mouth momentum, not precise list-building math. If someone shares your work enough to rack up 40 credited referrals, they’ve done the work even if only 25 people actually joined.

Both approaches work. The mistake is setting a milestone at, say, ten referrals, expecting ten confirmed subscribers, and then feeling cheated when your list only grows by six.

Fraud and gaming the system

Because platforms credit the share action, referral programs are vulnerable to bulk fake signups. Someone creates a dozen disposable email addresses, uses their own referral link, submits all twelve emails, and immediately gets credit for twelve referrals—even though none of those addresses will ever open an email.

Most platforms have basic fraud detection: they flag referrals from the same IP address, block known disposable email domains, and penalize accounts that rack up referrals with zero engagement. But enforcement is reactive, not preventive. If someone wants to game your referral leaderboard, they can do it for at least a few days before the system catches up.

The operator-side fix: build engagement thresholds into your rewards. Don’t just offer a reward at ten referrals—require that at least seven of those ten people open an email in the first 30 days. Sparkloop and some custom-built systems let you set that kind of conditional unlock. Beehiiv doesn’t natively support engagement-based milestones, so you’d need to manually audit your leaderboard before delivering high-value rewards like coaching calls or physical products.

When conversion-based crediting makes sense

A few platforms—mostly custom-built referral systems using tools like Rewardful or ReferralCandy—let you choose when to credit the referrer. You can configure the system to wait until the new subscriber confirms their email, opens their first email, or even makes a purchase (if you’re running a paid newsletter).

That approach eliminates inflated counts, but it introduces the delay problem. If your audience is sophisticated enough to understand that referral credit takes 24-48 hours to appear, it works. If your audience skews toward casual readers who expect instant feedback, the delay will depress sharing behavior.

One middle path: credit the share immediately, but display two numbers on the referrer’s dashboard—”total shares” and “confirmed subscribers.” Transparency costs you nothing, and it sets expectations. If someone sees they’ve sent 15 people to your signup page but only 9 confirmed, they understand the gap without feeling penalized.

Most newsletter platforms don’t offer that dual display by default. You’d need to build it yourself or accept that your referral dashboard is a directional indicator, not a precise accounting tool.

What to do now

If you’re running a referral program, audit your current milestone structure. Check the gap between credited referrals and actual confirmed subscribers over the last 30 days. If the gap is more than 20%, adjust your milestones upward or add engagement requirements before delivering rewards.

If you’re designing a new referral program, decide whether you’re optimizing for momentum (credit the share) or accuracy (credit the conversion). Most solo operators should optimize for momentum. Referral programs live or die on early enthusiasm, and nothing kills enthusiasm faster than a dashboard that doesn’t move.

Got a referral program question? Reply to this email—I read every response.

Heads up — some links in this article are affiliate links. If you sign up through them, we may earn a small commission at no extra cost to you. We only recommend tools we use ourselves.

Most newsletter platforms let you upload a header logo or hero image that sits at the top of every send. It lives on a CDN somewhere, gets referenced in your email HTML, and appears when subscribers open the message—unless they’re using Outlook with default security settings.

Outlook blocks external images by default. That’s not new. But the way it treats image preloading—and the specific conditions under which it does load images automatically—matters more than most operators realize, especially if your branding or layout depends on that header rendering correctly.

How Outlook’s image blocking actually works

When someone opens an email in Outlook (desktop or web), the client checks whether the sender’s domain is in the recipient’s safe sender list. If it’s not, Outlook blocks all external image requests and shows a placeholder bar: “Right-click here to download pictures. To help protect your privacy, Outlook prevented automatic download of some pictures in this message.”

Your logo, your hero image, your inline graphics—all blocked until the recipient manually enables images for that message or adds your sending domain to their safe list.

This affects roughly 15–20% of B2B newsletter audiences, depending on industry. Enterprise inboxes default to Outlook, and most users never change the image settings.

When preloading doesn’t help

Some platforms offer “image preloading” or “image caching” as a feature. The idea: the platform fetches your images, hosts them on its own domain, and includes them inline or as cached assets so they load without external requests.

That works for tracking pixels and some layout images, but it doesn’t bypass Outlook’s block if your header is still hosted externally—or if the platform’s CDN domain isn’t recognized by the recipient’s safe sender configuration.

Beehiiv and MailerLite both cache images on their own delivery infrastructure, which improves load speed and reduces broken-image rates in most clients. But Outlook treats any external image request as suspect unless the sender domain (not the CDN domain) is whitelisted.

If your header logo is a separate asset hosted on cdn.yourplatform.com, it’s still an external resource. Outlook blocks it.

The workaround: inline data URIs

You can embed small images directly in the email HTML using Base64-encoded data URIs. This removes the external request entirely—the image data lives in the HTML itself.

Most platforms don’t do this automatically because it increases message size and can trigger spam filters if overused. But for a logo under 10 KB, it’s usually safe.

In MailerLite, you can manually insert a data URI in the HTML editor. In Beehiiv, you’re limited to the visual builder unless you export and host elsewhere.

Practical limit: keep data URIs under 15 KB per image, and use them only for critical branding elements. A 2,000-pixel-wide hero image won’t work here.

What to test before you commit

Send a test to an Outlook.com address and a corporate Outlook inbox if you have access. Open the message without enabling images. Check:

• Does your header logo appear, or is it a broken placeholder?
• Does your layout break without the hero image?
• Is your CTA button an image, or is it HTML/CSS? (Image-based CTAs are blocked too.)

If your layout depends on images loading, you need a text fallback or an HTML-based design that works without graphics. That’s not a compromise—it’s baseline deliverability design for any B2B audience.

When to care about this

If your newsletter audience skews consumer (Gmail, Apple Mail, Yahoo), Outlook image blocking is a minor edge case. Those clients load images by default.

If you’re sending to enterprise subscribers, SaaS operators, or corporate decision-makers, Outlook is the majority client in many inboxes. Image-blocking rates jump to 30–40% in some verticals.

Check your platform’s open-tracking data by client. If Outlook represents more than 15% of opens and your header image is external, you’re losing branding consistency for a meaningful slice of your list.

Want to compare how different platforms handle image hosting and Outlook compatibility? Reply to this email with your current setup—we’ll add it to a future tool comparison.

Heads up — some links in this article are affiliate links. If you sign up through them, we may earn a small commission at no extra cost to you. We only recommend tools we use ourselves.

Ghost offers a membership feature that sits directly inside the CMS. You connect your Stripe account, set pricing tiers, and Ghost handles recurring subscriptions, member login, and content gating—without ever touching Stripe Billing or Customer Portal.

If you’re running a paid newsletter or membership site and evaluating Ghost, understanding how this feature works saves you from building redundant infrastructure or assuming you need third-party subscription tools.

How Ghost’s membership system works

Ghost integrates with Stripe via the Payments API, not Billing. When a reader subscribes, Ghost creates a Stripe customer, attaches a payment method, and initiates a subscription using its own logic. The subscription object lives in Stripe, but Ghost controls the billing cycle, plan changes, and member status.

Members log in through Ghost’s member authentication system. Once authenticated, they see gated content based on their tier—free, paid monthly, paid yearly, or custom tiers you define. Ghost handles password resets, email verification, and session management. There’s no separate login portal to maintain.

You manage members in Ghost’s dashboard. Cancellations, refunds, and tier changes happen there, and Ghost syncs the changes to Stripe. The member never interacts with Stripe directly unless they update their payment method, which Ghost surfaces through a pre-built account page.

When to use Ghost’s native memberships instead of Stripe Billing

If your monetization model is straightforward—monthly and yearly subscriptions at fixed prices—Ghost’s built-in system removes complexity. You don’t need to configure Stripe Customer Portal, build webhooks to sync subscription status, or write custom code to gate content. Ghost does it.

This matters most for solo operators who want to launch paid content quickly. Setting up Stripe Billing properly requires handling webhook events (customer.subscription.updated, invoice.payment_failed, etc.), managing session states, and building account management UI. Ghost eliminates that entirely.

Ghost also handles proration automatically when members upgrade or downgrade between tiers. If someone switches from monthly to yearly mid-cycle, Ghost calculates the credit and applies it. Stripe processes the payment, but Ghost manages the logic.

Where Ghost’s system falls short: complex pricing models. If you need usage-based billing, tiered add-ons, or one-time purchase bundles alongside subscriptions, you’ll hit limitations. Ghost’s membership tiers are subscription-only. You can’t mix recurring and one-time payments in the same checkout flow.

One non-obvious limitation: member import constraints

Ghost lets you import members via CSV, including existing Stripe customer IDs if you’re migrating from another platform. But here’s what doesn’t transfer cleanly: partial billing cycles.

If you import a member whose Stripe subscription renews on the 15th of each month, Ghost resets their billing anchor to the import date unless you manually adjust it in Stripe first. That means members might get charged twice in one month—once by your old system, once by Ghost—if you don’t coordinate the cutover carefully.

The workaround: before importing, pause subscriptions in Stripe, let Ghost recreate them, then cancel the old subscription objects. Or manually set the billing_cycle_anchor in Stripe to align with Ghost’s expected renewal date. Ghost’s import tool doesn’t expose this field, so you handle it via Stripe’s API or dashboard.

Pricing and platform lock-in

Ghost’s membership feature is free on self-hosted installs. You pay Stripe’s standard transaction fees (2.9% + $0.30 in the U.S.), but Ghost itself doesn’t take a cut. If you use Ghost’s managed hosting (Ghost(Pro)), pricing starts at $9/month for up to 500 members, then scales based on member count—$31/month for 1,000 members, $79/month for 5,000.

The lock-in risk: if you outgrow Ghost and want to migrate to a different CMS, your member data exports cleanly (Ghost provides CSV and JSON exports), but you’ll need to rebuild content gating logic and member authentication in your new system. Stripe subscriptions persist, but the integration layer doesn’t.

One mitigation: Ghost is open-source. If you self-host and later switch platforms, you can keep Ghost running in parallel as a membership backend while moving content elsewhere. It’s not elegant, but it works if you need time to rebuild.

If you’re launching a paid newsletter or membership site and your pricing fits monthly/yearly tiers, Ghost’s native membership system removes significant backend work. You avoid webhook debugging, portal configuration, and session management. Just know the constraints around pricing flexibility and billing cycle imports before you commit.

Have a question about Ghost memberships or another platform feature? Reply to this email—we cover reader questions every Sunday.

Every newsletter platform promises seamless imports. Upload a CSV, connect your old ESP, wait five minutes, and you’re done. Except you’re not.

Import tools handle the basics—email addresses, names, subscription dates—but they quietly drop or mangle data that matters. If you’re moving from one platform to another, you need to know what won’t survive the trip before you click “Start Import.”

Custom fields disappear or get renamed

Most platforms let you store custom data: subscriber location, referral source, purchase history, survey responses. When you import to a new platform, these fields rarely map automatically.

Beehiiv, for example, supports custom fields, but you need to create them before importing your CSV. If your old platform called a field “signup_source” and your new one expects “source,” the data lands in limbo or gets ignored entirely.

MailerLite handles this better than most—it auto-creates custom fields during import if it detects columns that don’t match standard fields—but it still won’t infer meaning. If you tagged subscribers as “paid” or “free” in your old system, you’ll need to manually map those to groups or segments after import.

Tags and segments don’t transfer consistently

Tags are metadata. Segments are dynamic queries. Most platforms treat them differently, and import tools don’t convert between the two.

If you’re moving from ConvertKit (which uses tags heavily) to a platform like Brevo (which leans on lists and attributes), your tags might import as plain text in a custom field—or not at all. You’ll need to rebuild segments manually using the new platform’s logic.

Even when platforms do support tags, they often cap how many can attach to a single subscriber during import. ConvertKit allows unlimited tags per contact, but some smaller platforms limit you to 10 or 20. If you’ve been tagging aggressively, the import will silently truncate.

Engagement history gets wiped

Open rates, click rates, and email engagement scores don’t port over. Your new platform starts everyone at zero.

This matters more than it sounds. Most ESPs use engagement history to throttle sending for new accounts. If you import 10,000 subscribers and immediately send to all of them, your new platform sees 10,000 cold contacts with no prior opens. That triggers spam filters and damages your sender reputation faster than a gradual ramp-up would.

Postmark and other transactional-focused platforms don’t track opens by default (they’re built for receipts and password resets, not marketing), so if you’re moving to a marketing ESP, you’re starting engagement tracking from scratch no matter what.

The fix: after importing, send only to your most engaged segment first—people who opened in the last 30 days—then gradually expand. This warms up your sender reputation on the new platform without triggering alarms.

Unsubscribes and suppression lists need manual handling

Unsubscribes should transfer, but they often don’t. Some platforms export unsubscribed emails in a separate CSV. Others include them in the main export with a status column. If you miss that column during import, you’ll re-subscribe people who opted out.

Suppression lists—emails that hard-bounced or marked you as spam—are even trickier. Most platforms won’t let you import suppressed addresses at all (by design), but they also won’t automatically suppress them on your new account unless you manually upload a suppression file.

If you skip this step, your first send on the new platform will attempt delivery to addresses that bounced months ago. That kills your sender score immediately.

What to do before you import

Export everything from your old platform: subscribers, unsubscribes, suppressions, custom fields, tags. Save separate CSVs for each.

Check your new platform’s import documentation—not the marketing page, the actual help docs—and map your fields manually. Create custom fields and tags before importing, so the data has somewhere to land.

Import in stages. Start with a small segment (100–500 subscribers) and verify everything looks right: names, fields, tags, suppression status. Only then import the full list.

And plan to rebuild segments. Even if tags import cleanly, your new platform’s segmentation logic probably works differently. Budget an hour to recreate your most important segments by hand.

Switching platforms isn’t one click. If you’re moving soon, factor in a half-day for data cleanup—not five minutes.

If you’re running into platform-specific import issues—or you’ve found a tool that handles this better than most—reply and let me know. I’ll cover it here.

Heads up — some links in this article are affiliate links. If you sign up through them, we may earn a small commission at no extra cost to you. We only recommend tools we use ourselves.

Beehiiv‘s built-in referral program is one of the platform’s strongest features. It tracks who refers whom, awards milestones automatically, and gives you a dashboard that looks clean enough to screenshot for Twitter.

But under specific conditions, the system can credit a single subscriber twice—once as an organic signup, once as a referral—and you won’t notice until you’re reconciling milestone rewards or trying to understand why your referral conversion rate looks suspiciously high.

This isn’t a bug in the traditional sense. It’s a timing issue between how Beehiiv handles cookie persistence, URL parameters, and post-signup attribution. And it happens more often than you’d think.

How the double-count happens

Beehiiv’s referral tracking relies on a ref parameter in the signup URL. When someone clicks a referral link, the platform sets a cookie that persists for 30 days. If that person subscribes within the window, the referrer gets credit.

The problem surfaces when someone does both of these things:

• Clicks a referral link but doesn’t subscribe immediately
• Returns later via a different entry point (direct traffic, search, social) and subscribes
• Then clicks another referral link from the same or a different referrer after subscribing

If the second referral link is clicked within 30 days of the first, and if the subscriber’s email matches, Beehiiv can attribute the signup to both the original cookie and the post-subscription click. The dashboard shows two referral credits for one person.

This doesn’t happen every time. It requires overlapping attribution windows and a subscriber who’s clicking around your ecosystem post-signup. But in communities where readers forward issues to each other, or in niches where your audience is also your referral base, it’s common enough to skew your numbers by 5–12%.

Why it matters

If you’re running a milestone-based referral program—three referrals gets a PDF, ten gets a course—double-counting means you’re awarding rewards for phantom signups. That’s a direct cost.

If you’re using referral metrics to evaluate which subscribers are your best advocates, the data is noisy. Someone who looks like a top referrer might have half their credits inflated by attribution overlap.

And if you’re trying to model referral-driven growth or calculate the viral coefficient of your newsletter, double-counted subscribers artificially inflate both the numerator and denominator. Your k-factor looks better than it is, and your CAC math breaks.

How to audit your referral data

Beehiiv doesn’t surface this in the dashboard. You need to export your subscriber list and cross-reference referral credits manually.

Go to Audience → Export and download the full subscriber CSV. Open it in Google Sheets or Excel. Filter by the Referred By column. Look for duplicate email addresses with different referrer values.

If you see the same email credited to two different referrers, check the signup timestamps. If they’re within 30 days of each other and the second timestamp is after the subscription date, you’ve found a double-count.

For newsletters with 5,000+ subscribers and active referral programs, expect to find 50–150 duplicates. For smaller lists, it’s less common but still worth checking before you ship milestone rewards.

What Beehiiv should do

The fix is straightforward: deduplicate referral credits by email address and prioritize the first attributed referrer within the 30-day window. If someone subscribes, lock their referral attribution. Don’t let post-subscription clicks overwrite or append credit.

Other platforms—MailerLite, SparkLoop, Viral Loops—handle this by treating the subscription event as the attribution cutoff. Once you’re in, subsequent referral link clicks don’t retrigger credit.

Beehiiv hasn’t shipped this yet. It’s been reported in their community forum since mid-2025, acknowledged by support, but not prioritized in the public roadmap.

Workarounds until they fix it

If you’re awarding physical rewards or high-value digital products, audit your referral credits manually before each batch. Export, filter, deduplicate, then fulfill.

If you’re using referral milestones as a growth lever but don’t want to audit constantly, pad your reward thresholds by 10–15%. Assume some credits are phantom and price accordingly.

And if you’re building a referral program from scratch and need clean attribution out of the gate, consider running it outside Beehiiv. SparkLoop integrates with Beehiiv via API and handles attribution more conservatively. You’ll pay $50/month minimum, but the data is cleaner.

If you’ve spotted referral double-counting in your own newsletter—Beehiiv or otherwise—reply and let us know how you’re handling it. We’re tracking workarounds and will update this piece if the platform patches it.

Heads up — some links in this article are affiliate links. If you sign up through them, we may earn a small commission at no extra cost to you. We only recommend tools we use ourselves.

The median online operator treats their subscriber list like a sales funnel with a timer attached. Every email becomes an opportunity to pitch, upsell, or extract. The logic sounds reasonable: you built the list to make money, so every touchpoint should drive toward a transaction.

That approach works exactly once. Then it stops working, and you’re left wondering why open rates collapsed and unsubscribes spiked.

The problem isn’t monetization. It’s the assumption that every subscriber, at every moment, exists in a buying state. They don’t. Most of your list is there for information, entertainment, or occasional utility—not to be sold to three times a week.

The trust account model

Think of subscriber attention as a bank account. Every useful email deposits credibility. Every pitch withdraws it. Send five valuable emails, you can afford one ask. Send three pitches in a row, and you’re overdrawn.

Most operators never build a surplus. They treat launch day as withdrawal day, pitch affiliate offers before they’ve proven they understand the reader’s actual problems, or drop sponsorships into every issue because the CPM math says they should.

The math doesn’t account for cumulative reader fatigue. A $400 sponsor slot this week might cost you six subscribers who would’ve bought your $200 course next quarter. You can’t measure what doesn’t happen, so you optimize for the wrong metric.

What changes when you stop pitching

I tracked two operators in the productivity-tool space last year—same niche, similar list size around 8,000 subscribers. One sent three emails per week with sponsor slots in every issue. The other sent two emails per week, sponsor-free, and pitched their own product once per month.

Six months in, the sponsor-heavy operator had earned $11,200 in sponsorship revenue but saw list growth stall at 8,400 and open rates drop from 42% to 29%. The selective operator earned $9,800 from their own product, grew to 11,600 subscribers, and maintained 48% opens.

The difference compounded. By month nine, the selective operator’s product revenue overtook the other’s total sponsorship income, because they had more engaged readers and higher conversion rates on the same offer.

This isn’t anti-monetization. It’s pro-selectivity. Every pitch has a cost. If you’re not accounting for it, you’re flying blind.

When to actually ask

Three conditions make a pitch worth the trust withdrawal:

You’ve recently solved a problem for them. If your last three emails helped someone fix a workflow issue, speed up their site, or understand a confusing tool feature, they’re primed to hear about a related product. The ask feels like a natural extension, not an interruption.

The offer is narrowly relevant. Broad pitches (“check out this course on online business”) perform worse than specific ones (“if last week’s email on SEO title tags was useful, this guide covers the 14 other on-page factors that move rankings”). Relevance isn’t about your niche—it’s about the exact problem you just addressed.

You’re willing to skip the next two pitches. If you can’t afford to go silent on monetization for two weeks after an ask, you’re over-extracting. The readers who didn’t buy need time to forget the sales pressure before you ask again.

The operators who get this right

The best-performing lists I’ve seen run 5:1 or 6:1 ratios—five or six pure-value emails for every monetization attempt. They treat pitches like they’d treat asking a favor from a friend: sparingly, with context, and only when the relationship can handle it.

That doesn’t mean waiting months to monetize. It means being deliberate. If you publish daily, you can pitch weekly and still maintain a healthy ratio. If you publish weekly, maybe you pitch monthly, or you build a small sponsorship into your standard format but keep it consistent and predictable rather than varied and aggressive.

The goal isn’t to avoid revenue. It’s to avoid the revenue plateau that comes from burning through trust faster than you rebuild it.

Want more operator-to-operator breakdowns like this? Subscribe to One Two Three Send for weekly tactics on running a content business without the generic advice.

Preview text—the snippet that appears below your subject line in most email clients—gets truncated at wildly different lengths depending on where your subscriber opens it. Gmail on desktop shows roughly 100 characters. Outlook on Windows cuts off around 40. Apple Mail on iPhone displays up to 140 in portrait mode, less in landscape.

Most newsletter operators write preview text once and assume it renders consistently. It doesn’t. And because preview text directly influences open rates (some studies peg the lift at 8–12% when optimized), understanding how truncation works matters more than you’d expect.

Where the cuts happen

Desktop clients are the most forgiving. Gmail shows approximately 100 characters on a typical monitor width. Apple Mail on macOS displays around 90. Outlook 2019 and 2021 on Windows cut hard at 40–50 characters, depending on subject line length—they share a fixed pixel width, so a long subject line eats into preview space.

Mobile is tighter. Gmail’s mobile app shows 80–90 characters in portrait, less in landscape. Apple Mail on iPhone displays up to 140 characters in portrait but drops to 70–80 in landscape. Outlook mobile sits around 65 characters regardless of orientation.

The problem: if your key message or call-to-action lives past character 50, roughly 30–40% of your list won’t see it. Outlook desktop users and anyone reading in landscape mode get cut off mid-sentence.

Frontloading vs. padding

The common advice is to frontload value—put your hook, offer, or call-to-action in the first 40 characters. That works when you have a single, clear message. “Early access ends Friday” or “Three new case studies inside” fit cleanly.

But frontloading creates a new problem: preview text that repeats your subject line. If your subject is “Case studies: how three operators doubled revenue” and your preview is “Three new case studies inside,” you’ve wasted 30 characters saying the same thing twice. Subscribers who do see the full preview get redundancy instead of context.

A better approach: use preview text to extend or qualify the subject line, but assume only the first 40–50 characters will render universally. Structure it so the opening phrase stands alone, and anything past character 50 adds detail for clients that display more.

Example: Subject line is “Affiliate link cloaking breaks in three places.” Preview text could be “DNS propagation, cache headers, redirect chains—here’s how to test each one.” The first phrase (“DNS propagation, cache headers, redirect chains”) gives context even when truncated. The second half (“here’s how to test each one”) adds value for subscribers on longer-display clients, but the preview still works without it.

Testing across clients

Most ESPs show a preview-text field in the send interface, but they don’t simulate truncation accurately. Beehiiv, MailerLite, and ConvertKit all display your full preview text in the editor—you won’t see how it renders on Outlook mobile until you send a test.

The best workflow: send test emails to multiple addresses on different clients before publishing. At minimum, check Gmail desktop, Apple Mail on iPhone, and Outlook on Windows. If you’re running a paid newsletter or sending to a B2B audience, add Outlook mobile to the rotation—corporate subscribers skew heavily toward Microsoft clients.

For operators sending daily or multiple times per week, set up a permanent test list with addresses tied to each major client. Send every issue to that list five minutes before the main send. Open each one, screenshot the inbox view, and compare truncation points. It takes three minutes and catches preview-text issues before they hit your full list.

When preview text doesn’t matter

Preview text has diminishing returns in three scenarios. First: if your open rates are already above 50%, you’re likely serving a highly engaged list that opens based on sender name and subject line alone. Optimizing preview text might add a percentage point or two, but it’s not your leverage point.

Second: transactional emails. Password resets, order confirmations, and receipt emails get opened regardless of preview text. If you’re using Postmark or a dedicated transactional service, default preview text (often the first line of body copy) works fine.

Third: emails where the subject line is self-contained and actionable. “Your invoice is ready” or “You’re confirmed for Friday’s workshop” don’t need preview-text reinforcement. Adding “Click here to download” or “See you at 2pm ET” is redundant.

Preview text matters most when your subject line raises a question or teases value without fully delivering it. If the subject is “Three underused features in your analytics dashboard,” preview text like “Session replay, funnel drop-off alerts, and cohort comparison—most operators miss all three” gives just enough detail to justify the open.

Want breakdowns like this in your inbox? Subscribe to One Two Three Send for operator-focused deep dives on the tools and tactics that actually move your online business forward.

Heads up — some links in this article are affiliate links. If you sign up through them, we may earn a small commission at no extra cost to you. We only recommend tools we use ourselves.