ConvertKit and Beehiiv both call themselves newsletter platforms, but they’re built for fundamentally different operators. One is a creator-focused email marketing tool that happens to support newsletters. The other is a media company in a box.
If you’re trying to choose between them, the feature lists won’t help much. What matters is how you plan to grow, what you’re selling, and how much control you need over your reader experience.
What each platform is actually optimised for
ConvertKit was built for course creators, coaches, and small product businesses who use email as part of a broader funnel. It excels at segmentation, tagging, and automation sequences. You can build complex subscriber journeys based on behaviour, purchases, and custom fields. The landing page builder is serviceable. The forms are flexible. The visual automation builder is genuinely good.
Beehiiv is a publishing platform first. It’s optimised for ad-supported or subscription-based newsletters that feel like media properties. The editor is purpose-built for newsletter writing, with built-in polls, referral programmes, and recommendation networks. Monetisation tools—ad network, premium subscriptions, boosts—are baked into the core product, not bolted on.
If your business model is “grow an audience, sell them a thing,” ConvertKit makes more sense. If it’s “publish regularly, monetise attention,” Beehiiv is the better fit.
Pricing and what you actually get
ConvertKit starts at $25/month for up to 1,000 subscribers on the Creator plan, which includes landing pages, forms, and basic automation. The Creator Pro plan is $50/month and adds the visual automation builder, subscriber scoring, and advanced reporting. Pricing scales with list size—10,000 subscribers costs $119/month on Creator Pro.
Beehiiv’s free tier is surprisingly generous: up to 2,500 subscribers, unlimited sends, and access to the referral programme and basic analytics. The Scale plan is $42/month for up to 10,000 subscribers and unlocks the ad network, custom domains, and audience segmentation. The Max plan at $84/month adds premium subscriptions, priority support, and no Beehiiv branding.
Beehiiv is cheaper if you’re just publishing and growing. ConvertKit costs more, but you’re paying for automation depth and integration flexibility.
Monetisation: built-in vs. bring-your-own
Beehiiv’s monetisation stack is its clearest differentiator. The ad network connects you with sponsors once you hit 2,500 subscribers. Premium subscriptions (paywalled content, member-only issues) are native. The boost feature lets you pay to get recommended to other Beehiiv newsletters. It’s all designed to work without leaving the platform.
ConvertKit has a tipping feature (one-off payments via Stripe) and supports paid newsletters through Commerce, but it’s not the core experience. Most ConvertKit users monetise by selling courses, memberships, or services outside the platform and using email to drive conversions. Integrations with Gumroad, Teachable, Circle, and Stripe are solid.
If you’re building a subscription newsletter or want sponsorship revenue, Beehiiv’s infrastructure saves you months of setup. If you’re selling products or services, ConvertKit gives you more control over the funnel.
Migration, design control, and lock-in
ConvertKit exports are clean. You own your subscriber data, and you can leave with a CSV and your sending domain intact. The template system is flexible but not beautiful—you’ll need custom HTML if you care about design.
Beehiiv’s editor is opinionated. You get a polished, mobile-friendly design out of the box, but customisation is limited. Exporting is straightforward (subscriber list, post archive), but if you’ve built revenue through Beehiiv’s ad network or boost ecosystem, that doesn’t port anywhere.
Neither platform holds your list hostage, but Beehiiv’s monetisation tools create stickiness that ConvertKit’s automation doesn’t.
Who should pick which
Choose ConvertKit if you’re selling digital products, running a service business, or need complex automation. It’s the better tool for operators who think in funnels, lifecycle stages, and multi-step sequences. You’ll outgrow the design limitations, but the automation won’t let you down.
Choose Beehiiv if you’re publishing content on a schedule, building a media brand, or monetising through ads and subscriptions. It’s faster to set up, cheaper at scale, and the built-in growth tools (referral programme, recommendations, boosts) are legitimately useful if you’re trying to grow without paid ads.
Both platforms are competent. The wrong choice isn’t about features—it’s about picking a tool that doesn’t match how you actually plan to make money.
Want more comparisons like this?One Two Three Send breaks down tools, tactics, and trade-offs for online operators every week. Subscribe to get the next one.
Most WordPress sites hit the database dozens of times per page load. Every menu, every widget, every post query — they all fire separate requests. For a low-traffic blog, that’s fine. For a content business serving thousands of readers a day, it becomes a bottleneck.
Object caching stores the results of those database queries in memory so WordPress can reuse them instead of re-running the same query ten times per page. It’s not page caching (which saves entire HTML pages). It’s not browser caching (which stores assets locally). It’s an in-between layer that speeds up the dynamic parts of your site — the bits that change based on who’s logged in, what’s in the cart, or which posts are being displayed.
If you’re running a membership site, a high-traffic blog, or a WooCommerce store, object caching can cut server load by 40–60%. But it adds complexity, and it doesn’t help every site equally.
How object caching works in WordPress
WordPress has a built-in object cache — but by default, it only lasts for a single page load. Every time someone visits a page, the cache resets.
Persistent object caching extends that lifespan. Instead of storing query results in PHP memory (which disappears after each request), it stores them in Redis or Memcached — key-value stores that sit in RAM and persist across requests.
When a query runs, WordPress checks the object cache first. If the result is there, it skips the database entirely. If not, it runs the query, stores the result, and serves it from cache next time.
Common queries that benefit: navigation menus, widget output, post metadata, taxonomy terms, user data, WooCommerce product attributes. Anything that gets called repeatedly and doesn’t change on every page load.
When to turn it on
Not every site needs object caching. A static blog with 500 visitors a month won’t see a meaningful difference. But you’ll notice a real impact if:
You’re serving more than 10,000 page views per month
Your site uses complex queries (custom post types, taxonomies, meta queries)
You’re running WooCommerce, BuddyPress, or another plugin-heavy setup
Your database queries are taking longer than 50ms (check this in Query Monitor)
You’re hitting CPU or memory limits during traffic spikes
The easiest way to tell: install Query Monitor, load a few pages, and look at the query count and total query time. If you’re running 100+ queries per page or spending more than 200ms on database calls, object caching will help.
Most managed WordPress hosts (Kinsta, WP Engine, Cloudways) offer Redis as a one-click add-on. If you’re on a VPS with BigScoots or similar, you’ll need to install Redis yourself (or ask support to do it) and add a plugin like Redis Object Cache or Object Cache Pro.
The non-obvious gotcha
Object caching breaks badly written plugins.
If a plugin assumes every query hits the database — or if it doesn’t properly invalidate (clear) cached data when something changes — you’ll see stale content. A post updates, but the old version keeps showing. A product goes out of stock, but the cache still says it’s available.
Good plugins handle this automatically by calling wp_cache_delete() or wp_cache_flush() when data changes. Bad plugins don’t.
Before you enable object caching site-wide, test it on a staging environment. Update a post, change a menu, edit a product. If those changes appear immediately on the front end, you’re fine. If they don’t, you’ve got a plugin conflict.
One more thing: object caching doesn’t replace page caching. It speeds up dynamic queries, but you still want a layer (like WP Rocket, Cloudflare, or your host’s built-in cache) saving full HTML pages for logged-out users. The two work together — page caching handles static content, object caching handles the bits that can’t be fully static.
What to do next
If you’re not sure whether your site needs object caching, start here: install Query Monitor (it’s free), load your most-trafficked pages, and check the database panel. If you’re seeing 80+ queries or 150ms+ query time, object caching will make a measurable difference.
If you’re already on a managed host, check whether Redis is included or available as an add-on. If you’re on a VPS, ask your host whether they support Redis, or spin up a staging site and test it yourself.
And if you do turn it on: keep Query Monitor installed for a week and watch for stale content. Most modern plugins handle caching well, but the ones that don’t will show themselves quickly.
Got a question about WordPress performance, caching, or infrastructure? Hit reply — this is the sort of thing we dig into every week.
Most “host your own WordPress” guides assume you want to learn Linux. This one doesn’t. The goal here is a working newsletter site running on DigitalOcean, with One Two Three Send installed and ready to send your first email, in roughly 90 minutes. Cost: about $10/month all in.
If you’ve never touched a server before, you can still follow this. Wherever a step needs more explanation than a sentence, we’ve put it inline. Wherever you can safely skip a sub-task, we’ve said so.
Why DigitalOcean
For a single newsletter site, you have three real options:
Managed WordPress hosts (Kinsta, WP Engine, SiteGround). $25–35/month minimum. Someone else handles the server. Worth it if your time is genuinely worth more than the cost.
Shared hosts (Bluehost, Hostinger). $3–5/month. Cheaper, but resource-constrained, oversold, and slow once your list grows past a few thousand.
Cloud VPS (DigitalOcean, Linode, Vultr, Hetzner). $6–12/month. You get a real Linux server. Slightly more setup, dramatically more control.
DigitalOcean wins on simplicity for the cloud-VPS category. Their dashboard is the cleanest in the industry, their one-click WordPress image is genuinely good, and their pricing is predictable. Hetzner is cheaper if you’re in Europe; AWS Lightsail is comparable if you’re already on AWS for other reasons. For everyone else, DO is the default.
Sizing the droplet correctly
This is where most guides waste your money. The right droplet for a newsletter site depends almost entirely on subscriber count, not on traffic.
Subscribers
Droplet
Monthly
0–2,000
Basic 1GB / 1 vCPU
$6
2,000–15,000
Basic 2GB / 1 vCPU
$12
15,000–50,000
Basic 4GB / 2 vCPU
$24
50,000+
CPU-Optimised 8GB
$84
Start small. DigitalOcean lets you resize a droplet vertically (more RAM/CPU) with a five-minute reboot. There is zero benefit to over-provisioning. The $6 plan handles a couple of thousand subscribers comfortably.
Step 1 — Create the DigitalOcean account
Go to digitalocean.com and sign up. They’ll ask for a payment method. They give new accounts $200 in credit valid for 60 days, which is plenty to test multiple configurations before committing.
Add a payment method even if you have credit — without one, your droplet gets destroyed when the credit expires.
Step 2 — Spin up the WordPress droplet
From the control panel: Create → Droplet.
Region: pick the one closest to your subscribers. For a US/global audience, NYC3 or SFO3. For Europe, FRA1 or AMS3. For Asia/Pacific, SGP1 or SYD1. The droplet’s region determines the latency for your admin use; subscribers don’t see your droplet, they see the email’s sending IP (which is your email provider, not DO).
Image: click the Marketplace tab and search “WordPress”. Pick “WordPress on Ubuntu 22.04”. This is the official DigitalOcean one-click image — it ships with WordPress, MySQL, nginx, PHP, and Certbot pre-installed. Saves you about three hours of setup.
Plan: Basic → Regular. Pick the size from the table above.
Authentication: SSH key if you know what one is, password if you don’t. (You can switch to SSH later.) Set a strong password and store it in a password manager.
Hostname: something memorable like love-france-newsletter. Doesn’t affect anything outside the dashboard.
Backups: tick the box. It’s 20% of the droplet cost ($1.20 on a $6 droplet) and it’s the cheapest insurance you’ll ever buy. Weekly snapshots, four-week retention, fully automated.
Click Create Droplet. Wait 60 seconds.
Step 3 — Finish the WordPress install
Once the droplet’s ready, copy its IP address from the dashboard. SSH in:
ssh root@YOUR_DROPLET_IP
The first login runs the WordPress finalisation script automatically. It asks for:
Your domain name (or use the IP for now if you haven’t bought a domain yet)
An email address for Let’s Encrypt SSL certificate notifications
Whether to enable HTTPS (yes — it’s free and automatic)
The script provisions an SSL certificate via Let’s Encrypt and configures nginx for HTTPS. This is the single best part of the DO marketplace image — getting SSL right manually is an hour’s work that you skip entirely.
If you don’t have a domain yet, point your browser at the droplet’s IP and you’ll see the WordPress install wizard. Pick a strong admin password (NOT “admin” as the username — pick something obscure), set the site title, and finish.
Step 4 — Point your domain at the droplet
If you bought a domain (Namecheap, Cloudflare, or any other registrar), add two DNS records:
A record: @ → your droplet IP
A record: www → your droplet IP
DNS propagation takes 5 minutes to an hour depending on the registrar. While you wait, log into WordPress at https://YOUR_DOMAIN/wp-admin.
If SSL didn’t get set up during step 3 (because you didn’t have a domain yet), SSH back in and run:
certbot --nginx -d YOUR_DOMAIN -d www.YOUR_DOMAIN
Certbot handles the cert, the nginx config, and the auto-renewal cron job in one command.
Step 5 — Set up backups (the second kind)
You enabled DigitalOcean’s droplet backups in step 2 — those snapshot the entire server weekly. That’s good for “the droplet died” recovery.
You also need WordPress-level backups for “I broke a plugin” recovery. The free UpdraftPlus plugin is the operator standard. Install it from Plugins → Add New, configure it to back up to Google Drive or Dropbox daily, and forget about it.
Your insurance is now layered: UpdraftPlus restores the WP install in minutes, DO snapshots restore the entire server in an hour. Most operators never need either, but the one time you do, you’ll be glad you set both up.
Step 6 — Install One Two Three Send
From the WordPress admin: Plugins → Add New, search for “One Two Three Send”, click Install, then Activate.
The plugin walks you through initial configuration:
Claude API key. Get one from console.anthropic.com. Pasted into Newsletter → Settings → AI. Required only if you want AI generation; you can run the plugin without it and write everything by hand.
Email provider. Pick one in Newsletter → Settings → Provider. For under 50,000 emails a month, Resend or Postmark are the easiest. Above that, switch to Amazon SES — we wrote a separate post on that.
Signup form. The plugin creates a default form at Newsletter → Signup Forms. Copy its shortcode and paste it into a WordPress page (e.g. /subscribe) or a widget area.
Welcome email.Newsletter → Settings → Welcome. New subscribers see this immediately on signup. The default is fine; customise the body to match your brand voice.
That’s the minimum to start sending. Generate your first newsletter at Newsletter → New Newsletter.
Step 7 — Optional: install One Two Three Send Pro
If you want Stripe paywalls, custom newsletter templates, the public archive, the Newsletter Network cross-promotion widget, or the AI Agents blog generator, install the Pro companion plugin.
Pro is distributed by email to subscribers of the One Two Three Send newsletter — sign up at onetwothreesend.com and the install link arrives within minutes. Once installed, Pro auto-updates from the manifest server; no manual updates needed.
What you should NOT do on the droplet
Some categories of work that look reasonable but will cause problems:
Do not run your own SMTP server. Outbound port 25 on cloud providers is heavily blocked by inbox providers because so much spam comes from cloud IPs. Even if you got mail to leave the droplet, it would land in spam folders. Always use a dedicated email service (Resend, Postmark, SES) for sending. The droplet’s job is to host the WordPress admin and the public site, nothing more.
Do not skip the firewall. Run ufw enable on first login and only open ports 22 (SSH), 80 (HTTP), and 443 (HTTPS). DO has a network-level firewall in the dashboard that’s even better — set it up to lock everything else down.
Do not run as root forever. The marketplace image lets you log in as root by default. Within the first day, create a non-root user with sudo, copy your SSH key over, and disable root SSH login. There are guides for this; fifteen minutes of work that pays off the first time someone scrapes your IP looking for SSH brute-force opportunities.
Do not install random WordPress plugins. Each plugin is server code running with database access. The plugin ecosystem is broad and most plugins are fine, but the bad ones are spectacularly bad. Stick to plugins with 100,000+ active installs, recent updates, and active support. UpdraftPlus, Yoast SEO, Wordfence, and One Two Three Send all qualify.
Photo: Wikimedia Commons (CC)
Long-term maintenance
If you do nothing else, do these.
Weekly: log in to WordPress and click “Update” on anything with an update available. WordPress core, plugins, themes. WordPress’s auto-update for minor versions is on by default; you’re checking that nothing got missed.
Monthly: SSH in and run apt update && apt upgrade. Reboot if a kernel update comes through. This applies Ubuntu security patches.
Quarterly: review installed plugins. Anything not actively used should be deactivated and deleted. Inactive plugins still receive updates and can introduce security issues. The one-click image ships with about a dozen utility plugins; remove any you’re not using.
Annually: re-evaluate your droplet size. If your subscriber count has 5x’d, your $6 droplet is now under-provisioned. If your subscriber count hasn’t grown, your $24 droplet is overspending. DigitalOcean’s resize takes five minutes and a reboot.
When DigitalOcean is the wrong choice
If you genuinely don’t want to ever SSH into a server, pick managed WordPress hosting. Kinsta is the gold standard ($35/mo for a starter site); WP Engine is the enterprise default; SiteGround is the budget option. You pay 3–5x more, but you never have to think about Linux.
If you’re running 100+ sites, DigitalOcean stops being optimal. AWS Lightsail with a Multi-AZ database, or a Kubernetes cluster on DO/Linode, becomes worth the additional setup. The break-even point is around 10–20 sites.
If your audience is mostly in one specific region (say, Australia), pick a host with a data centre in that region. DO’s SYD1 region is fine; alternatives like Vultr Sydney or AWS ap-southeast-2 are also options.
For everyone else: DigitalOcean is the most boring infrastructure decision you can make for a newsletter site, and that’s the highest compliment infrastructure can earn.
You’ve built a beautiful public archive. Every issue, neatly catalogued and indexed by Google. SEO-friendly URLs, a clean grid layout, maybe even a search function. It feels like good practice—transparent, reader-friendly, discovery-oriented.
And it’s teaching your most interested readers that subscribing is optional.
This isn’t about paywalls or artificial scarcity. It’s about understanding what an archive actually does in the wild, and why the tension between discoverability and commitment isn’t resolved by simply making everything public.
The logic that breaks down
The standard argument goes like this: public archives build trust, enable search traffic, let people sample your work before committing, and give you an SEO footprint. All true. The problem is what happens after someone finds your archive and reads three excellent back issues.
They bookmark it. They add it to their RSS reader if you’ve enabled one. They remember your name and return when they think of it. What they don’t do is subscribe, because they’ve just learned they don’t have to. The value is already freely available, indexed, and accessible on their terms.
You’ve turned your newsletter into a blog with an optional notification system.
The readers who do subscribe from an archive page are often the least engaged cohort you’ll add to your list. They’re completionists, people who clicked the button out of vague interest, not urgency. They’re not waiting for your next issue—they’ve already read the ones that mattered to them. Your open rate from this segment will quietly drag down your overall metrics, and your deliverability along with it.
What partial access actually looks like
You don’t need to lock everything behind a signup wall, but you do need to create a meaningful difference between what subscribers get and what the public sees. That difference is where the value of being on your list lives.
Some operators show only the most recent issue publicly, letting it act as a live sample while older issues remain subscriber-only. Others make the first three paragraphs public and truncate the rest. Some publish selectively—only certain types of issues go public, while the main editorial thread stays private.
The key is that your archive shouldn’t answer the question “What does this newsletter contain?” It should answer “Is this worth subscribing to?” Those are different questions. The first one converts curiosity into passive readership. The second converts it into commitment.
The unsubscribe safety valve
Here’s the concern that always comes up: “But if people can’t read old issues, how will they know whether to subscribe?”
They won’t know for certain. That’s the point. Subscribing becomes a low-stakes experiment, not a fully informed decision. And because you’ve made unsubscribing easy and visible (you have, haven’t you?), the risk is nearly zero. They’ll try one issue, maybe two. If it’s not for them, they’ll leave. If it is, they’ll stay and actually read what you send.
This is healthier than a list padded with people who joined after reading six months of archives and now ignore everything in their inbox because they’ve already consumed your best work.
What this means for discovery
Yes, a restricted archive reduces your search surface area. You’ll get fewer organic landing pages, fewer inbound links to old issues, less passive traffic. That’s real.
But ask yourself what that traffic was doing for you. If it rarely converted to subscribers, or converted them into unengaged ones, you’ve lost vanity metrics and kept the part that matters: people who join because they want what you’re about to send, not what you’ve already sent.
If search visibility matters to your model—because you’re building authority, monetising traffic separately, or using the archive as a lead generation tool for something else—then a public archive may still make sense. But know what you’re trading. You’re optimising for attention, not for list quality.
For most newsletter operators, the list is the asset. Everything else is scaffolding.
Here’s the thing: if you’re not sure whether your archive is helping or hurting, try this—check how many of your most engaged subscribers originally joined via an archive page versus a landing page, referral, or direct link. The answer will tell you whether your archive is doing the work you think it is.
If you found this useful, subscribe to One Two Three Send and get insights like this in your inbox before they hit the archive. If they hit the archive at all.
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.
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.
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 (hello@yourbrand.com) 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. hello@yourbrand.com works. hello@yourbrand.zendesk.com 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.
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 whilst 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.
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 optimisation, 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 behaviour.
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 realise 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 optimising 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.
You’ve optimised 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 realise. 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 behaviour—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.
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 “noreply@emailplatform.com” 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.
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 behaviour 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.
.jpg){kind=link}