One Two Three Send

Author: onetwothreeadmin

  • How to use Amazon SES to send newsletters at scale

    How to use Amazon SES to send newsletters at scale

    If you’re running more than one newsletter and you’ve started doing the math on Resend, Postmark, or Mailchimp at 100,000 emails a month, you’ve probably already arrived at the same conclusion most operators do eventually: Amazon SES is roughly 10x cheaper than the alternatives, and you stop being able to ignore it once your monthly send count crosses about 50,000. This post is the playbook we wished we’d had when we moved to SES. Implementation, the parts vendors don’t tell you, and what to do six months later when reputation problems show up.

    The case for SES, in one paragraph

    SES costs $0.10 per 1,000 emails sent. There is no subscription tier, no retainer, no “premium” version. You verify a domain, you send mail, you pay for what you use. For a single newsletter sending to 1,000 subscribers daily, that’s $3 a month. For 100 newsletters at the same volume, $300. The closest equivalent at retail Resend pricing is roughly $2,400. That gap is the entire reason this post exists. The tradeoff: SES gives you a sending engine, not a mailing platform. You bring everything else — list management, unsubscribe links, bounce handling, analytics. If your stack already provides those (or if you’re running One Two Three Send and they’re built-in), this is the right tradeoff. If you want a dashboard that shows you a graph of opens, SES is the wrong product.

    Cost math, with real numbers

    Assume a brand averaging 1,000 active subscribers, sending five newsletters a week. That’s about 22,000 emails a month per brand.
    Brands Emails/month SES cost Resend retail Postmark Mailgun Foundation
    1 22,000 $2.20 $20 $25 $35
    10 220,000 $22 $90 $200 $80
    100 2,200,000 $220 $1,000+ $1,500+ $400+
    The numbers aren’t perfectly comparable — Postmark‘s bounce dashboard alone is worth something — but the order of magnitude is real. Below ~50,000 emails a month, SES isn’t worth the implementation work. Above that, every other provider starts looking like a luxury tax.
    A row of metal mailboxes at dusk
    Photo: Mike Mozart, CC BY 2.0

    Setup, in the order you should actually do it

    Step 1: Request production access. Today. Before anything else.

    SES starts every account in sandbox mode: 200 emails a day, and you can only send to addresses you’ve verified. Nobody mentions this until you’re trying to debug why your test send works to your own inbox but fails to your subscribers’. Production access is a one-paragraph form in the SES console. Approval usually takes 24 hours, sometimes faster. Submit it on day one of your migration project so the clock is running while you do everything else. The form asks how you handle bounces and complaints, what your typical send volume is, and whether subscribers explicitly opted in. Be specific. Generic “we’ll handle it” answers get rejected.

    Step 2: Verify your sending domain (not your email address)

    You can verify a single email address ([email protected]) but don’t. Verify the domain (yourbrand.com). Domain verification gives you DKIM signing for everything sent from any address at that domain, which is the deliverability win. In the SES console, “Verified identities” → “Create identity” → “Domain” → enter the domain → enable DKIM. SES gives you three CNAME records to add to your DNS. They look like random123._domainkey.yourbrand.com pointing at random123.dkim.amazonses.com. Add them to your DNS. Wait 10 minutes. Refresh the SES console. Three green checkmarks. The pitfall here: many DNS managers strip the trailing period on CNAME values, or auto-append the parent domain. If your DKIM checkmarks stay yellow after an hour, the cause is almost always that your CNAME target now reads random123.dkim.amazonses.com.yourbrand.com instead of just random123.dkim.amazonses.com. Edit the record, remove the appended bit.

    Step 3: Create the credentials

    You have two paths here, and which one you pick determines how much code you’ll write. Path A — SMTP credentials. SES SMTP settings → “Create SMTP credentials”. AWS generates an IAM user behind the scenes and gives you an SMTP username and password. Plug those into any SMTP-capable mail tool (including the SMTP option in One Two Three Send). Zero new code. Endpoint is email-smtp.us-east-1.amazonaws.com:587. Path B — IAM access keys for the SES API. Create an IAM user with the AmazonSESFullAccess policy (or scoped down to ses:SendEmail on your verified domain ARN, which you should do for production). Grab its access key ID and secret access key. Use these to sign SES API v2 requests directly with AWS Signature v4. For under 100,000 emails a month, use Path A. SMTP is fast enough and saves you the SigV4 signing implementation. Above that, Path B becomes worth it because you can attach configuration sets, message tags, and skip the STARTTLS roundtrip.

    Step 4: Set up the From address and reply-to

    Your From: address must be at the verified domain. [email protected] works. [email protected] does not, even if yourbrand.zendesk.com resolves — Zendesk’s domain isn’t verified in your SES account. Set a real reply-to. Subscribers reply. If your reply-to is noreply@, you’re throwing away the most valuable feedback signal a newsletter has.

    Step 5: Send your first email

    The acid test: send to a Gmail address, an Outlook address, and a Yahoo address you control. Open Gmail’s “Show original” view on the received message. You should see:
    • SPF: PASS (with amazonses.com)
    • DKIM: PASS (signed by yourbrand.com)
    • DMARC: PASS (only if you have a DMARC record — see pitfalls)
    If any of those say NEUTRAL or FAIL, fix that before sending to a single real subscriber. Inbox providers are unforgiving with new senders, and your first 30 days set the reputation that follows you for months.

    Step 6: Set up bounce and complaint handling

    Skip this step and SES will suspend your account, eventually, with no warning except an email a week before it happens that you’ll miss in a busy inbox. Create an SNS topic (ses-feedback). In the SES configuration set, attach event publishing for Bounce and Complaint events to this topic. Wire the topic to an HTTP endpoint on your site that flips the matching subscriber’s status to bounced or complained and stops sending to them. This is the difference between “I send mail with SES” and “I run a newsletter on SES that won’t get suspended in month four.”

    SES vs the rest, honestly

    vs Resend — Resend has a beautiful API and a dashboard that’s a joy to use. You pay for that. They’re a great choice while you’re under 50k/month. Above that, the price gap becomes the only thing that matters. vs Postmark — Postmark has the best deliverability reputation in the industry and the best bounce dashboard. They specialize in transactional, not marketing/broadcast — their pricing model penalizes high-volume sends. Worth using for transactional emails (welcome flows, password resets) even if you use SES for newsletters. vs Mailgun — Roughly comparable to SES on price at scale, easier to set up, slightly worse deliverability in our testing. If you actively dislike AWS, Mailgun is the closest cost equivalent. vs Mailchimp / ConvertKit / Beehiiv — Different category. Those are mailing platforms (list, editor, analytics, automation). SES is a sending engine. You wouldn’t compare a hosting provider to Squarespace; same logic applies. vs SendGrid — SendGrid is what you use when your dev team wants to use SendGrid. It’s fine. Pricing tiers are odd above 100k.

    Pitfalls, in the order operators usually hit them

    1. The sandbox catches everyone. First send to a real subscriber bounces with “Email address is not verified” and you spend two hours debugging your code. The error message means SES, not your subscriber’s address. Submit the production access request before you do anything else. 2. DMARC alignment. If you have a _dmarc TXT record set to p=reject, your SES emails will fail DMARC unless your From: domain matches the DKIM signing domain. SES handles this automatically when you verify the full domain (Step 2 above), but if you verified only an email address, you’ll fail DMARC alignment and your mail goes to spam at every major provider. Verify domains, not addresses. 3. The 5% bounce / 0.1% complaint thresholds. SES tracks these silently. Hit 10% bounces and you get a warning email. Hit 5% sustained, or 0.1% complaints, and you get suspended. The math: in a list of 1,000, fewer than 50 hard bounces is fine; more than that and you’re already in trouble. Clean lists before you migrate to SES. Run a list-validation pass through a service like NeverBounce or Kickbox first; the $30 cost pays for itself a thousand times over. 4. The shared IP problem (and the dedicated IP solution). SES sends from shared IP pools by default. If another SES customer on your IP range sends spam, your reputation gets dinged through no fault of your own. For most sub-1M/month senders this is fine — Amazon’s pools are well-policed. Above 1M/month, request a dedicated IP ($24.95/month). For 100 brands, give each of the highest-volume few their own IP and pool the long tail. 5. IP warming. New dedicated IPs need a 30-day ramp where you slowly increase volume. If you spike from 0 to 100k on day one, every email goes to spam. SES’s “Easy DKIM with managed warm-up” handles this if you let it. Don’t override the schedule because you’re impatient. 6. The implicit unsubscribe link requirement. Gmail and Yahoo’s 2024 sender requirements mandate one-click unsubscribe headers (List-Unsubscribe-Post: List-Unsubscribe=One-Click) for any sender doing more than 5,000 emails a day to their domains. SES doesn’t add these automatically — your sending code must. If your platform doesn’t add this header, your delivery rate to Gmail will collapse without warning. 7. Sending across regions. SES sending quotas are per-region. If you start in us-east-1 and migrate to eu-west-1 later, your reputation doesn’t follow. Pick a region on day one and stay there.

    Long-term maintenance

    The first two months of SES are setup theater. The rest is reputation management. Daily: keep an eye on the SES “Reputation dashboard.” Bounce rate trending up means a list-quality problem; complaint rate trending up means you’re sending content people don’t want. Both are fixable, but only if you notice. Most operators set up a CloudWatch alarm at 3% bounces and 0.05% complaints — half the threshold AWS uses to suspend you. Weekly: review the bounce/complaint webhooks for patterns. A spike in bounces after a specific newsletter usually means a corporate domain blocked you. A spike in complaints usually means a specific email’s subject line came across as spammy or you imported a list segment that didn’t actually opt in. Monthly: prune subscribers who haven’t opened in 90 days. Inbox providers downgrade your reputation when you keep sending to inactive addresses, even if those addresses don’t bounce. This is counterintuitive — you’re paying for the email, why would sending to a quiet address hurt? — but it’s how Gmail’s reputation algorithm works in 2025. Quarterly: rotate your IAM credentials. Even if nothing has gone wrong, do this anyway. AWS makes it easy (create new credentials, deploy, deactivate the old set, delete after 30 days), and it gets you in the habit of treating sending credentials with the same care as customer data. Annually: review your SES sending quota against actual volume. If you’ve grown 10x and you’re still on the original 50,000/day limit, you may be silently losing mail at peak send times. Quota increases are a console click and usually approved automatically based on your sending history.

    When SES is the wrong choice

    If you’re sending fewer than 50,000 emails a month, the time you’ll spend on setup, monitoring, and bounce handling is worth more than the cost difference. Use Resend or Postmark. Come back when you scale. If your team has zero AWS experience and zero appetite to gain it, the implementation is the iceberg’s tip. Setting up SES correctly takes a day. Operating it correctly takes ongoing attention. If nobody on the team finds CloudWatch dashboards reasonable, pick a vendor whose abstraction matches your team’s skills. If you need a polished UI for non-technical staff to manage lists, write campaigns, and view stats, SES will frustrate everyone involved. It’s a sending engine, not a product. For everyone else: SES is the most boring infrastructure decision you can make for a newsletter business, and that’s the highest compliment infrastructure can earn.

    Some links in this post are affiliate links — we earn a small commission if you sign up through them, at no cost to you. We only recommend tools we actually use.

  • The opening line nobody reads (and why you keep writing it)

    The opening line nobody reads (and why you keep writing it)

    You’ve earned the open. The subject line worked, the preview text intrigued, the from name carried trust. The reader is in.

    And then your first sentence asks them to leave.

    Not explicitly. You’re not trying to lose them. But that opening line—”Happy Tuesday!” or “I hope this finds you well” or “Welcome to issue #247″—is doing exactly the wrong job. It’s burning attention on pleasantries while the reader’s commitment is at its most fragile.

    The first sentence of your newsletter isn’t a greeting. It’s a threshold. And most operators treat it like a doormat instead of a door.

    What the first sentence actually needs to do

    Every newsletter open contains a tiny crisis of doubt. Should I have opened this? Is this worth the next two minutes? Did the subject line oversell?

    Your first sentence exists to resolve that doubt. Not with reassurance, but with immediate proof of value.

    That means your opening line needs to do one of three things:

    • Deliver a surprising insight that validates the open
    • Name a specific problem the reader is experiencing right now
    • Create forward momentum that makes stopping feel costly

    Notice what’s missing: preamble, context-setting, apologies for length or frequency, meta-commentary about the newsletter itself. None of that resolves doubt. It amplifies it.

    The reader didn’t open your email to read about your newsletter. They opened it for what the newsletter contains. Your first sentence should be that thing, not the announcement of that thing.

    The anatomy of a threshold sentence

    Look at the opens you don’t regret—essays, articles, newsletters that justified the click in the first breath. They almost always start in one of three postures:

    Direct address of a buried truth: “Your analytics dashboard is lying to you about which content works.” No warm-up. Immediate tension. The reader either agrees and wants proof, or disagrees and wants to argue. Either way, they’re in.

    A concrete observation that implies expertise: “I’ve reviewed 2,000 welcome sequences in the past year, and only eleven of them asked for a reply.” Specificity signals authority. The reader trusts you know something they don’t.

    Narrative momentum that bypasses scepticism: “The unsubscribe came at 3am, and the reason field just said ‘too real’.” Story moves faster than analysis. By the time the reader evaluates whether they care, they’re already three sentences deep.

    All three approaches share a common trait: they assume the reader’s attention rather than courting it. There’s no “I wanted to share some thoughts on…” or “Today we’re going to explore…” Those constructions treat the open as provisional. Your first sentence should treat it as fact.

    What to cut (and where to put it instead)

    Most first-sentence bloat comes from misplaced editorial anxiety. You’re worried about tone, about presumption, about starting too abruptly. So you buffer the opening with social niceties or structural signposting.

    Cut all of it. Not because warmth doesn’t matter—it does—but because the first sentence isn’t where warmth lives.

    If you need to acknowledge your send frequency or thank readers for opening, do it at the end. If you want to include a personal note or a scheduling update, make it a postscript. The reader who makes it to your closing has already decided you’re worth their time. The reader at sentence one hasn’t.

    The same logic applies to structural framing. “In this issue” boxes, table-of-contents lists, meta-explanations of your format—they all belong below the fold, if anywhere. Let the reader discover your structure by moving through it, not by reading a blueprint first.

    Test this tomorrow

    Open your last three sent issues. Read only the first sentence of each. If you removed everything else, would that sentence alone justify the open?

    If the answer is no—if it’s a greeting, a meta-comment, or a context-setting preamble—rewrite it. Not the whole email. Just that first line. Make it do the actual work: prove the open was worth it.

    Then compare your next send’s engagement to your trailing average. The threshold matters more than you think.

    If this hit home, you should subscribe to One Two Three Send. Every issue is written for people who send newsletters and want them to actually get read. No fluff, no filler—just operator-to-operator truth about what works.

  • How click tracking signals to Gmail that you’re a marketer

    How click tracking signals to Gmail that you’re a marketer

    When you paste a link into your newsletter, most platforms don’t send that link. They send a redirect through their own domain, wrapped in tracking parameters that identify the recipient, the campaign, and the specific link position. You get click data. Gmail gets a signal.

    That signal says: this isn’t personal correspondence. This is bulk mail with commercial tracking infrastructure. And Gmail’s filters treat it accordingly.

    What link tracking actually does to your URLs

    A clean link — say, example.com/article — becomes something like track.platformname.com/CL0/https://example.com/article/1/010001.... The redirect domain, the encoded destination, the recipient identifier. It’s functionally identical to what marketing automation platforms, transactional email services, and promotional senders use.

    Inbox providers don’t guess whether you’re sending marketing email. They classify based on infrastructure patterns. Link tracking is one of the clearest patterns. It tells automated filters that your message is part of a measured campaign, not a one-to-one exchange.

    This doesn’t guarantee spam folder placement, but it does shift how your mail is evaluated. You’re no longer in the same classifier bucket as personal mail. You’re being judged against other tracked, bulk sends.

    The trade-off nobody explains clearly

    Click tracking gives you data: who engaged, which topics landed, what CTAs converted. It’s useful for optimization, especially if you’re testing approaches or running a commercial operation. But it’s not free. The cost is deliverability friction and reader trust.

    Some readers hover before clicking and see the tracking domain. Others notice the redirect lag. Many don’t consciously register it, but inbox providers do — at scale, across every send, building a profile of your sender behavior.

    If your newsletter is primarily relationship-driven — commentary, analysis, curation for a niche audience — the data you gain from tracking may not justify the classification risk. If you’re running a publication with ad inventory, affiliate partnerships, or conversion funnels, the calculation changes.

    What happens when you turn tracking off

    Most platforms let you disable link tracking per campaign or globally. When it’s off, your links go out as written. No intermediary domain, no recipient tokens, no redirect layer. The message looks more like mail sent from a personal client.

    You lose click metrics. You can still track at the destination using UTM parameters — they don’t require a redirect, just append to the URL — but you won’t know who clicked unless they convert or identify themselves. You’ll have aggregate traffic data, not individual engagement history.

    For some newsletters, that’s enough. For others, it’s not. The point isn’t that tracking is bad. It’s that it’s not neutral, and most operators don’t realize they’ve made a choice.

    How to decide what’s right for your send

    If you depend on behavioural segmentation — re-engaging clickers, suppressing non-clickers, tailoring content by interest — tracking is probably worth keeping. If you’re optimizing commercial performance and need to know what works, the data justifies the trade-off.

    If your newsletter is built on voice, trust, and a stable reader relationship — if people subscribe because of you, not a content function — consider what you actually do with click data. If the answer is “glance at it occasionally,” you might be paying a deliverability cost for information you don’t operationalise.

    Run a test. Turn off tracking for a segment or a single send. Watch your open rate, your spam complaints, your reply rate. See if the lack of click data actually changes your editorial decisions. Most operators discover it doesn’t.

    If this kind of operational detail matters to you, you’re exactly who we write for. Subscribe to One Two Three Send and get insights like this in your inbox before they show up anywhere else.

    Link tracking isn’t a feature you passively inherit. It’s an infrastructure choice with second-order effects. Make it deliberately.

  • The timestamp in your footer that’s costing you readers

    The timestamp in your footer that’s costing you readers

    You’ve optimized your send time. You’ve tested your subject lines. You’ve got your preview text dialled in. But there’s a timestamp sitting in the footer of every send that’s telling a different story—and it might be working against you.

    The time zone you display matters more than most operators realize. Not for deliverability in the technical sense, but for something harder to measure: calendar friction and perceived relevance.

    The problem lives in two places

    First, there’s the time zone in your email footer. The one next to your physical mailing address or the bit of legal copy most readers ignore. If you’re sending from San Francisco but half your list is in London, that Pacific timestamp creates a tiny moment of cognitive distance. It’s subtle, but it registers: this wasn’t written for me.

    Second—and this is the bit that actually affects behavior—there’s the send metadata. The timestamp your email client displays in the inbox. If your newsletter arrives at 6pm but shows a send time of 10am, readers start to wonder why it took eight hours to reach them. They don’t blame their client or their ISP. They assume your infrastructure is slow, or that the email sat in a queue somewhere. Either way, it degrades the perception of timeliness.

    Why it matters for topical content

    If you’re sending evergreen content, this doesn’t bite as hard. But the moment you reference “this morning,” “yesterday,” or “over the weekend,” time zones expose the seams. A newsletter that says “this morning’s news” but shows a timestamp from 11 hours ago feels stale on arrival—even if it isn’t.

    Worse, if you’re sending event-based newsletters (product launches, live commentary, breaking industry news), the mismatch between your language and the reader’s clock creates doubt. They start reading around your timestamps instead of trusting them. That’s friction you can’t afford.

    What most platforms let you control (and what they don’t)

    Most ESPs let you pick a send time, but fewer let you control the time zone that gets stamped into the email header. Some platforms default to UTC. Others use the account owner’s local time. A handful let you set it manually, but bury the setting three layers deep in your sender profile.

    The footer timestamp is easier—it’s just a merge tag or a manual string. But most operators never think to localise it, or swap it out depending on segment geography. If you’re sending to a global list from a single template, you’re showing everyone the same time zone. That’s fine if you’re explicit about it (“All times Pacific”), but most footers don’t clarify. They just print a time and assume everyone knows what it means.

    What to do about it

    If your content is time-sensitive, state your time zone clearly and consistently. Don’t make readers guess. If you reference “10am,” write “10am GMT” or “10am ET.” If your footer shows a timestamp, append the zone. It’s two extra characters, and it prevents confusion.

    If you’re segmenting by geography, consider segmenting your footer copy too. Swap the time zone string to match the recipient’s region. Most ESPs support conditional merge tags—it’s not complicated, just underused.

    And if your platform lets you set a canonical time zone for send metadata, align it with your primary audience. If 60% of your list is in Europe, don’t default to Pacific. The header timestamp should reflect where your readers live, not where you do.

    The trust signal you didn’t know you were sending

    None of this will tank your open rate overnight. But small mismatches accumulate. A newsletter that feels like it was written for a different audience, in a different time zone, at a different moment in the day, is a newsletter that slowly becomes irrelevant.

    Readers won’t articulate it. They’ll just drift. They’ll open less. They’ll skim more. And eventually, they’ll unsubscribe—not because your content got worse, but because it stopped feeling like it was meant for them.

    If this hit home, reply and tell us what time zone you send from—and whether you’ve ever thought about changing it. We read every reply, and the good ones end up in future issues.

  • Where half your signups quietly disappear

    Where half your signups quietly disappear

    You’ve done the hard work. Someone filled in your signup form. They want to hear from you. Then you send them a confirmation email and roughly 40–60% of them never click through.

    This isn’t a deliverability problem. It’s a design problem. Most confirmation emails are written like legal documents sent by robots. They arrive in a moment of uncertainty—right after someone’s handed over their email address—and instead of reinforcing the decision, they create friction.

    Let’s fix that.

    The three seconds that matter most

    Your confirmation email arrives when the reader’s intent is at its peak, but their confidence is fragile. They’ve just committed to letting you into their inbox. They don’t yet know if they’ve made a good decision.

    Most confirmation emails open with something like: “Please confirm your subscription to our mailing list by clicking the link below.” This language is transactional, cold, and devoid of value. It asks without giving. It reminds the reader they’re entering a database, not starting a relationship.

    The best confirmation emails do the opposite. They remind the person why they signed up. They restate the value. They make clicking feel like progress, not compliance.

    What to say (and what to cut)

    Start with voice, not instructions. If your newsletter has personality, this is where you prove it. A confirmation email from a weekly design newsletter might open with: “You’re one click away from better typography every Thursday.” A B2B SaaS newsletter might say: “Let’s make sure these insights actually reach you.”

    Then make the button copy active and specific. “Confirm subscription” is generic. “Yes, send me the toolkit” or “Start my weekly send” is directional. It tells the reader what happens next, not just what they need to do right now.

    Cut the apology. Don’t say “Sorry for the extra step.” Double opt-in is a feature, not a bug. It protects your list and proves intent. Frame it as mutual benefit: “This confirms you want to hear from us (and keeps your inbox from filling with things you didn’t ask for).”

    And don’t bury the button. Some confirmation emails include three paragraphs of legal text before the call to action. Put the button high. Make it obvious. Everything else can come after.

    The sender name problem

    Here’s a quiet failure point: your confirmation email arrives from a different sender name than the one people will see when your newsletter lands.

    They signed up for “The Middleware Report” and the confirmation comes from “[email protected]” or “Middleware Inc.” The cognitive gap is small, but it’s enough to trigger hesitation. In that moment of uncertainty, people don’t click—they delete, or worse, they mark it as spam.

    Your confirmation email should come from the same sender name and address your newsletter uses. If your weekly send comes from “Alex at The Middleware Report,” your confirmation should too. Consistency removes doubt.

    Timing and the death zone

    Most platforms send confirmation emails instantly. That’s correct. But many operators don’t think about what happens in the fifteen minutes after signup.

    If someone signs up on mobile and then closes their email app, that confirmation sits in an inbox they won’t check for hours. By the time they see it, the context is gone. They don’t remember signing up. They don’t click.

    You can’t control when people check their email, but you can control what the email says when they finally see it. Include a light reminder of where they signed up. “You requested this from the homepage” or “You signed up after reading the post on API design.” Context is a conversion tool.

    What happens after the click

    The confirmation journey doesn’t end when someone clicks the button. Most platforms dump people onto a generic “You’re confirmed!” page with no next step. That’s a missed opportunity.

    Send people to a page that continues the relationship. Thank them. Tell them when the next issue arrives. Link to your archive or your most popular post. Give them something to do while they wait. The goal is to turn a compliance click into the beginning of engagement.

    If you want to go further, this is also the moment to set expectations. “You’ll hear from us every Tuesday. If you don’t see it, check your promotions folder.” Small instructions now prevent confusion later.

    If you’re rethinking your signup flow and need reliable infrastructure that won’t drop confirmation emails into the void, BigScoots handles email delivery without the complexity of managing your own server.

    Measure what you’re losing

    Most newsletter platforms show you how many people confirmed, but they don’t surface the inverse: how many people signed up and then vanished. That’s the number that matters.

    Track your confirmation rate as a standalone metric. If it’s below 50%, your confirmation email is the problem. A well-written, well-timed confirmation email should convert 60–75% of signups. Anything less means you’re losing people who wanted to subscribe.

    This isn’t about growth hacking. It’s about not wasting the attention you’ve already earned. Every signup represents effort—yours and theirs. The confirmation email is where you prove that effort was worth it.

    What’s your confirmation rate right now? If you don’t know, that’s the first thing to check. Reply and tell us what you find—we read every response.

    Some links in this post are affiliate links — we earn a small commission if you sign up through them, at no cost to you. We only recommend tools we actually use.

  • Bounce rates are a hiring decision, not a problem to fix

    Bounce rates are a hiring decision, not a problem to fix

    Most newsletter operators treat bounce reports like error logs: something vaguely unpleasant to ignore until a platform forces you to look. But your bounce rate isn’t background noise. It’s the clearest signal you’ll get about list quality, and if you’re not acting on it immediately, you’re gambling with your sender reputation.

    Here’s what actually matters: every hard bounce is a landmine you’ve just stepped on. Every soft bounce is a warning light. And the way you respond to both determines whether ESPs see you as a professional operator or a spammer who doesn’t care where mail goes.

    Hard bounces are non-negotiable

    A hard bounce means the address doesn’t exist, never existed, or has been permanently disabled. Sending to it again won’t work. Sending to it repeatedly will get you blocklisted.

    The correct behavior is automatic and immediate: remove the address. No grace period. No second chances. No “maybe it was a temporary DNS issue” wishful thinking.

    Why? Because continuing to mail hard bounces tells receiving servers one of two things about you: either you’re harvesting addresses without permission, or you don’t care enough to maintain basic list hygiene. Both look identical to a spam operation.

    Most platforms auto-suppress hard bounces. If yours doesn’t, you need a better platform or a manual process you run weekly at minimum. This isn’t optional maintenance. It’s the baseline cost of staying in the inbox.

    Soft bounces need a policy, not a reflex

    Soft bounces are trickier. The mailbox exists, but something prevented delivery: inbox full, server temporarily down, message too large, content flagged by a filter.

    The temptation is to retry forever. Don’t.

    After three to five consecutive soft bounces, the address should be suppressed. The exact number depends on your send frequency, but the principle holds: if someone’s mailbox has been full for a month, or their server has rejected you five times in a row, they’re either gone or their setup is incompatible with your mail.

    Continuing to send harms you more than it helps them. Mailbox providers track your bounce rates over time. A slow accumulation of soft bounces signals poor list management just as clearly as hard bounces do, it just takes longer to trigger consequences.

    What your bounce rate actually tells you

    A healthy list bounces at well under 2%. If you’re consistently above that, you’ve got a sourcing problem, not a delivery problem.

    Common causes: imported lists from old systems where addresses weren’t validated, signup forms without confirmation, third-party lead magnets that didn’t scrub entries, or viral growth that pulled in throwaway addresses.

    If your bounce rate spikes suddenly, it’s usually one of three things: a bad import, a compromised form, or a technical issue with how your sending domain is configured. All three require immediate action. A sustained spike will destroy your sender reputation faster than almost anything else you can do.

    The fix starts with understanding where bad addresses enter your system. If you’re seeing hard bounces on brand-new signups, your form validation is broken or missing. If bounces cluster around imports, you need a stricter cleaning process before upload. If they’re random and creeping upward, you’ve likely got organic decay, which means your content isn’t reaching people anymore and they’ve moved on.

    Build the workflow now

    This doesn’t require expensive tools. It requires a weekly routine: pull your bounce report, segment hard from soft, remove hards immediately, flag softs that have hit your threshold, and investigate any anomalies.

    Most importantly, track your bounce rate as a core metric alongside opens and clicks. If it trends upward over months, your list is rotting and your acquisition pipeline needs an audit.

    Your bounce rate is diagnostic. It won’t tell you what to write or when to send, but it will tell you whether your list is real, whether your sources are clean, and whether you’re maintaining the infrastructure reputation that keeps you in the inbox.

    If you’re serious about keeping your newsletter out of the spam folder, subscribe to One Two Three Send for the operational details other newsletters won’t cover.

    Ignore your bounces long enough and you won’t need to worry about subject lines or preview text. You’ll be sending to no one.

  • The five subject-line formulas that train readers to ignore you

    The five subject-line formulas that train readers to ignore you

    You’ve got a subject line formula. Maybe it’s [Topic] + [Number]. Or “This week in [Category].” Or the classic emoji + question format. It works—your open rates are steady, maybe even good—so you keep using it.

    Here’s the problem: your readers have learned the pattern. And patterns don’t create curiosity. They create autopilot behavior.

    When your subject lines follow the same structure week after week, you’re not building brand recognition. You’re training your audience to make snap judgements about whether this edition is worth their time based purely on the formula, not the substance. And increasingly, the answer is no.

    The comfort trap of templated subject lines

    Subject line templates are seductive. They’re efficient. They remove decision fatigue. Your Monday edition always starts with “Monday Briefing:” and your readers know what to expect.

    Except “knowing what to expect” is precisely the problem. The inbox isn’t a reliable delivery mechanism anymore—it’s a battleground for attention. And attention doesn’t go to the predictable; it goes to the unexpected.

    When your subject line follows a formula, your reader’s brain doesn’t need to engage. It can categorize and dismiss in milliseconds. “Oh, it’s the Friday roundup. I’ll catch it later.” Later never comes. The pattern has done its job: it’s helped your reader feel informed without actually opening.

    This isn’t about your open rate dropping off a cliff. It’s about the slow, invisible erosion of engagement. Your most loyal readers still open out of habit. But new subscribers? They’re learning the pattern before they’ve learned the value. And they’re gone before you notice.

    Why variability beats brand consistency here

    There’s a persistent myth that subject line consistency builds trust. That readers need to recognize your email in the inbox before they’ll open it.

    That’s confusing two different jobs. Your from name builds recognition. Your subject line’s job is to create a reason to open this particular edition. Not your newsletter in general. This one.

    The operators seeing the strongest sustained open rates aren’t the ones with the tightest templates. They’re the ones whose subject lines feel hand-written for each edition. They vary sentence structure. They shift tone. They surprise.

    One week it’s a statement. The next, a fragment. Then a question that doesn’t follow the usual format. The through-line isn’t structural—it’s voice. And voice can flex without breaking.

    Your readers don’t need a formula to recognize you. They need a reason to stop scrolling. And repetition, no matter how on-brand, isn’t a reason.

    What to do instead

    This doesn’t mean every subject line needs to reinvent the wheel. It means breaking the autopilot cycle—for you and your readers.

    Start by auditing your last twenty subject lines. If you can predict the structure of number twenty-one before you’ve written it, your readers can too. And if they can predict it, they can dismiss it.

    Try writing three subject lines per edition instead of one. Not A/B test variations—three genuinely different approaches. Different lengths, different tones, different structures. Then pick the one that feels most true to this edition’s content, not your brand template.

    Give yourself permission to break your own rules. If you always ask questions, make a statement. If you always go short, stretch long. If you never use a colon, use one. The point isn’t chaos—it’s that each subject line should feel like it was written for the thing inside, not pulled from a drop-down menu.

    And pay attention to your replies. Not your open rate—your replies. Because the readers who hit reply are the ones who were genuinely surprised, delighted, or provoked by what they found. That’s the signal. If your subject line formula is working, you’ll see it there first.

    The real cost of efficiency

    Templates save time. But they cost attention. And in the inbox, attention is the only currency that matters.

    Your subject line isn’t a label. It’s a promise that this edition is worth interrupting whatever else your reader was doing. And promises that sound identical every time stop feeling like promises. They start feeling like noise.

    If you want your newsletter to feel essential rather than routine, your subject lines need to feel written, not generated. That takes more time. It takes more thought. But it also means your readers can’t predict—and therefore can’t ignore—what you’re about to say.

    If this resonated, reply and tell me what subject line formula you’re trying to break. I read every response, and the best operator insights end up shaping future editions of One Two Three Send.

  • Send frequency is a retention decision, not a content one

    Send frequency is a retention decision, not a content one

    You’ve been thinking about send frequency backwards. Most newsletter operators treat cadence as a content problem: “Do I have enough to say twice a week?” or “Will people get annoyed if I send daily?”

    But frequency isn’t a content question. It’s a retention engineering decision that shapes how subscribers relate to your newsletter, how they process your subject lines, and whether they remember you exist between sends.

    The operators who crack this understand something counterintuitive: the gap between sends does more to determine your open rate than what’s inside them.

    Expectation decay starts the moment you send

    Every time you send, you’re making a promise about when you’ll appear again. Send on Tuesday three weeks running, then go quiet for nine days, and you’ve just taught your subscribers that your schedule is unreliable background noise.

    This isn’t about perfectionism. It’s about recognition patterns. Your subscribers aren’t keeping a spreadsheet of your send dates—they’re building a subconscious model of when you show up. Break that model, and your next subject line gets processed differently. It doesn’t trigger the same “oh, it’s them” recognition. It gets treated like a cold email from a half-remembered sender.

    The retention damage happens silently. People don’t unsubscribe when you go from weekly to whenever-you-feel-like-it. They just stop opening. Your newsletter drifts from habit to clutter, and you never see the metrics that tell you why.

    Frequency determines who self-selects in

    Here’s what most operators miss: your send frequency is a filter that determines your audience composition before anyone reads a word.

    Daily senders attract a different subscriber psychographic than monthly senders. Not better or worse—different. Daily trains people to skim, to expect brevity, to treat your newsletter like a morning ritual. Monthly trains people to expect depth, to set aside time, to feel like they’re missing something if they skip.

    When you’re inconsistent, you don’t get a blend of both. You get people who don’t know what to expect, which means they don’t build the behavior patterns that drive retention. Your opens become dependent entirely on subject line performance, because there’s no habit layer underneath.

    The smartest move isn’t finding the “optimal” frequency. It’s picking one that matches the subscriber behavior you want to encourage, then defending it ruthlessly. If you say weekly, send weekly. If you go daily, don’t skip Tuesday because you had a slow news cycle. The consistency is the content strategy.

    The real cost of “whenever it’s ready”

    Publishing when you’ve got something worth saying sounds principled. In practice, it’s a slow-motion retention disaster.

    Irregular cadence destroys your ability to build anticipation. Anticipation is what keeps engaged subscribers engaged—it’s the gap between “I know this is coming” and “it’s here.” Without predictable timing, there’s no gap. There’s just surprise, and surprise doesn’t compound into habit.

    Worse, irregular sending makes every edition a re-introduction. You’re not picking up a conversation; you’re restarting one. That’s why sporadic newsletters lean so hard on recap sections and “it’s been a while” throat-clearing. You’re spending words rebuilding context that consistent senders get for free.

    The operators who send “whenever it’s ready” eventually notice their open rates trending down and blame content quality. But the content isn’t the variable that changed. The expectation environment around it did.

    How to pick (and hold) your frequency

    Start by asking what behavior you’re trying to build, not what you can sustain content-wise. Do you want to be a daily habit, a weekend read, a monthly deep-dive? Let that answer set your frequency, then reverse-engineer the content format to fit it.

    If daily feels unmanageable, the solution isn’t “weekly-ish.” It’s daily with a format so constrained that you can’t fail to ship: three links, one paragraph, done. If monthly feels right but you worry about being forgotten, add a mid-month brief check-in that doesn’t break the expectation of your main edition.

    Once you pick, commit for at least twelve weeks. Frequency changes are retention resets. Every time you shift cadence, you’re asking subscribers to relearn when you exist. Do it too often and they stop trying.

    And if you’re currently inconsistent, don’t grandfather yourself into “flexible.” Pick the frequency you can actually hold, announce it in your next send, and start the clock. Your open rates will tell you within a month whether you’re building a habit or just adding to the pile.

    If this shifted how you’re thinking about your send strategy, reply and tell me what frequency you’re committing to. I read every response, and the answers always surprise me.

  • The plain-text version that secretly halves your delivery

    The plain-text version that secretly halves your delivery

    Every HTML newsletter you send includes a hidden twin: the plain text version. You’ve probably never looked at it. Your ESP auto-generates it, strips out the formatting, and sends it along for the ride. Job done.

    Except it’s not done. That plain text version isn’t just a technical formality for ancient email clients. It’s read by spam filters before your message hits the inbox. It’s served to subscribers using assistive technology. And roughly 10–15% of your list has their client set to display plain text by default, either for bandwidth, security, or simple preference.

    When your plain text version is broken, illegible, or littered with rendering artefacts, you’re not just offering a poor experience to a minority of readers. You’re sending mixed signals to the infrastructure that decides whether your newsletter gets delivered at all.

    What auto-generated plain text actually looks like

    Most platforms generate plain text by stripping HTML tags and guessing at structure. The results are predictably bad. Link URLs appear in full, often mid-sentence. Navigation elements, social icons, and footer legalese appear in random order. Image alt text may vanish entirely, leaving contextless gaps. If you’ve used buttons, they often render as naked URLs with no explanatory text.

    Even worse: if your HTML uses tables for layout (still common in email templates), the plain text version can scramble reading order completely. A two-column layout might interleave sentences from both columns, making the whole message unintelligible.

    Spam filters notice. A newsletter where the plain text version is drastically shorter, structurally garbled, or filled with broken formatting signals a sender who isn’t paying attention to technical hygiene. It’s a small red flag, but reputation is built from small flags.

    Why accessibility isn’t optional

    Screen readers don’t parse your beautifully art-directed HTML. They consume the plain text version, or read the HTML semantically if no plain text exists. If your auto-generated version is a mess, you’ve just made your newsletter inaccessible to blind and low-vision subscribers.

    This isn’t a niche concern. Assistive technology users are overrepresented among newsletter audiences, particularly in professional and educational niches. They’re also among your most loyal readers—if you don’t chase them away with illegible formatting in the first three sends.

    Even subscribers without disabilities sometimes switch to plain text mode when traveling, on poor connections, or using privacy-focused clients that block remote images by default. If your plain text version assumes they’ll see the HTML, you’ve lost them.

    How to fix it without doubling your workload

    Start by actually looking at the plain text version your platform generates. Most ESPs show it in the send preview. If yours doesn’t, send yourself a test and check your client’s view options. What you’re looking for: legibility, logical reading order, and whether calls-to-action still make sense.

    If it’s a disaster, you have two options. First: clean up your HTML structure. Use semantic headings, keep layouts simple, avoid complex tables, and write descriptive link text instead of “click here.” Many rendering problems fix themselves when the source HTML is cleaner.

    Second: write a custom plain text version. Most platforms let you override the auto-generated one. This sounds like extra work, but it’s faster than you think. You’re not redesigning the newsletter—you’re just ensuring the message makes sense in a linear, unformatted reading. Strip theNav. Shorten footer legalese. Make link context explicit. A tight 400-word plain text version often works better than a bloated 800-word HTML piece.

    One operator trick: use your plain text version as an editing tool. If the message doesn’t hold up without formatting, images, and design crutches, the HTML probably isn’t as clear as you think.

    Test it like you test subject lines

    You’d never send a newsletter without checking the subject line. The plain text version deserves the same scrutiny. Build it into your pre-send checklist: preview the plain text, read it top to bottom, verify links make sense in context.

    If you’re running a team, assign plain text QA to someone who isn’t the designer or writer. Fresh eyes catch the assumptions and context gaps that slip through when you’ve been staring at the HTML for an hour.

    And if you’re using dynamic content blocks, personalisation, or conditional sections, test the plain text version with different audience segments. Auto-generation handles conditionals poorly, and you may discover entire sections rendering out of order.

    Take five minutes this week: pull up your last three sends and look at the plain text versions. If you wince, your subscribers already did. Fix it before your next send, and keep fixing it. The readers who notice won’t say anything—they’ll just stay subscribed.

  • What your image-heavy emails cost you in deliverability

    What your image-heavy emails cost you in deliverability

    You spent twenty minutes finding the perfect header image. You exported it at high resolution because you want it to look crisp. You embedded three more throughout the body to break up the text. And now your open rates are down 14% and you’ve no idea why.

    Images aren’t neutral. Every kilobyte, every file format choice, every decision about hosting affects whether your newsletter reaches the inbox—and whether anyone bothers reading it once it arrives.

    The weight problem nobody talks about

    Email clients don’t wait for heavy emails. Gmail truncates messages over 102KB, clipping everything below that threshold behind a “view entire message” link. Apple Mail on iOS often fails to load images over cellular connections when the total payload exceeds certain thresholds. Outlook still renders images inconsistently depending on file size and format.

    But the real damage happens before any of that. Spam filters look at email size as a signal. A 600KB email with multiple high-resolution images patterns-matches with the kind of promotional blasts that recipients ignore. It doesn’t matter that your content is thoughtful and your list is engaged. The structure of your email is whispering “bulk sender” to every filter between you and the inbox.

    Most newsletter operators export images at whatever size their design tool suggests. That’s usually 2x or 3x resolution for retina displays—which means a 600-pixel-wide image ships at 1800 pixels and gets scaled down by the email client. You’re sending triple the data for zero perceivable quality gain in an email context.

    Alt text isn’t just for accessibility anymore

    Roughly 43% of Gmail users have images blocked by default. Apple Mail Privacy Protection loads images through a proxy that strips tracking pixels but doesn’t guarantee the image itself renders on the user’s screen if they’re skimming with images off.

    If your newsletter relies on images to communicate key information—your call-to-action is a button graphic, your main point is in an infographic, your brand identity lives in a masthead—then nearly half your readers see broken boxes and alt text. Except most newsletter operators write alt text like this: “Image” or “Header” or nothing at all.

    Alt text is now doing double duty. It’s an accessibility requirement and a reading experience for a massive segment who’ll never enable images. Write it like you’d write a caption: descriptive, useful, complete. If the image disappeared tomorrow, would your reader still understand the email? If not, the image is doing structural work that belongs in HTML text.

    Hosting images inline vs. external links

    You have two choices: encode images directly into the email (Base64 embedding) or host them externally and link to them. Both have costs.

    Base64 increases email size by roughly 37%. A 100KB image becomes 137KB of encoded text embedded in your HTML. That pushes you toward clipping thresholds faster and makes your email source code a bloated mess that some spam filters flag as suspicious.

    External hosting keeps the email lightweight, but introduces dependencies. If your image host is slow, the email feels slow. If your CDN goes down, your images disappear. And every externally hosted image is another DNS lookup, another HTTP request, another opportunity for something to break on a flaky mobile connection.

    The correct answer isn’t one-size-fits-all. Small logos and essential brand elements can be embedded if they’re optimized under 20KB. Everything else should be externally hosted on a fast, reliable CDN with aggressive caching. If you’re just getting started and need dependable infrastructure that won’t collapse under traffic, BigScoots is worth considering for hosting your asset library.

    What actually works

    Start with this assumption: your newsletter should be fully readable with images off. Everything else is enhancement.

    Optimize every image before it goes in. Use tools like ImageOptim or Squoosh to compress without visible quality loss. Export at 1x resolution, not 2x—email clients aren’t photo galleries. For photographs, use JPEG at 60–80% quality. For graphics and logos, use PNG-8 when possible, not PNG-24. SVG works in some clients, but support is inconsistent enough that you’re better off sticking with raster formats.

    Keep total email size under 80KB including all images and HTML. If you’re regularly exceeding that, you’re either embedding too much or not compressing aggressively enough.

    Test your newsletter with images disabled in Gmail, Apple Mail, and Outlook. If it’s unreadable or confusing, restructure. Move key content into text. Use images to support, not replace, your message.

    And for the love of deliverability, stop using a giant hero image at the top of every send. It’s a pattern spammers love, it increases size, and it trains readers to scroll past the first screen before they see anything substantive. If you must use one, make it small, make it fast, and make sure your first paragraph of real text loads above it.

    If this changed how you think about images in your sends, reply and let me know what you’re adjusting. I read every response, and your questions shape what we cover next.

    Some links in this post are affiliate links — we earn a small commission if you sign up through them, at no cost to you. We only recommend tools we actually use.

Powered by
►
Necessary cookies enable essential site features like secure log-ins and consent preference adjustments. They do not store personal data.
None
►
Functional cookies support features like content sharing on social media, collecting feedback, and enabling third-party tools.
None
►
Analytical cookies track visitor interactions, providing insights on metrics like visitor count, bounce rate, and traffic sources.
None
►
Advertisement cookies deliver personalized ads based on your previous visits and analyze the effectiveness of ad campaigns.
None
Powered by