Email infrastructure for newsletter operators when open rates stopped meaning what they used to

Roughly €100K/year in paid subscription revenue. Below that, Substack's 10% take is real money but the network effects (Notes, recommendations, the discovery loop) are worth more than the 10%. Above that, you're paying €10K+/year for infrastructure you could rent for €9K. The other migration triggers are non-financial: needing editorial control Substack doesn't allow, needing to send to a non-paying list for ads, needing real list-hygiene tooling, or wanting to own the subscriber relationship without Substack as the intermediary.

The migration itself is not trivial. Substack's paid-subscriber export gives you the subscriber data, but the Stripe customer IDs don't transfer cleanly — paid subs need to re-authorize their card on the new platform, and a percentage will churn during that step. Plan for 10-20% paid-subscriber loss during migration as the realistic worst case.

Clicks, replies, poll votes, survey responses, paid-subscriber conversion, page visits to your archive. Every metric that requires a deliberate human action. Open rates are useful for exactly two things in 2026: deliverability monitoring (a 60% open rate dropping to 35% week-over-week tells you something is wrong even if you can't trust either number absolutely) and broad trend analysis at the publication level. Stop using opens for segmentation, automation triggers, or content optimization decisions.

The Beehiiv blog and the Validity 2026 benchmark report both make this point with the data: open rates inflated by ~15-20 points industry-wide post-MPP, Apple's April 2024 prefetching adjustments caused open-rate drops with no real engagement change, only 15% of marketers still treat opens as primary. The newsletter ecosystem has moved on; the only operators still optimizing for opens are the ones who haven't internalized what 2021-2026 did to the metric.

Two stages. Stage 1, days 90-180: tier-throttle — reduce send frequency by 75% for subscribers who haven't clicked anything in 90 days. They stay on the list, addressable, but they're not dragging your domain reputation. A monthly "we miss you" email and the next month's flagship issue is plenty; sending them every Tuesday is what gets you demoted by Gmail. Stage 2, day 180: send a final re-engagement message ("we're going to stop emailing you unless you click here") and unsubscribe non-responders.

For a list that's been accumulating dormants for years and has never been pruned, the first sunset wave is going to feel huge — you might cut 40-60% of the list. The Gmail-reputation improvement typically shows up within 2-3 weeks of the sunset, and click-through rates on the remaining list often improve by 30-50% within the first month. The dormants weren't reading anyway; what changed is that Gmail no longer treats your domain as a sender of unwanted mail.

Yahoo's August 27, 2025 cut from 1 TB to 20 GB caused a wave of over-quota soft bounces for senders with Yahoo-heavy lists. The mailbox is full, not gone; the user isn't necessarily unengaged, they just have no room for new mail. Treating these as hard bounces and unsubscribing aggressively will hurt you because some of those users will eventually clear out their inbox. Treating them as engaged readers will hurt you because they can't actually receive your mail.

The pattern we use: distinguish over-quota from address-doesn't-exist at the SMTP code level (Yahoo returns specific codes for each), retry over-quota addresses on a slower schedule (every 3-4 days instead of daily), unsubscribe after 30 consecutive over-quota events. Below the 30-event threshold, the user has a non-trivial chance of clearing the mailbox and coming back; above it, you're paying reputation cost for nothing.

The traditional industry guidance — 50K+ daily volume — is from the pre-2024 world. In 2026 the answer depends more on whether you want isolation from other senders. For a 50K-subscriber weekly newsletter, the daily-equivalent volume isn't enough to "fill" a dedicated IP, but the per-domain engagement signal that Gmail measures is per-IP-and-per-domain together. Sharing an IP with another publication means inheriting some of their engagement profile.

If your engagement rate is meaningfully better than the platform average, dedicated IPs help. If it's worse, dedicated IPs hurt (you lose the inherited reputation lift from being on a good shared pool). At 100K+ active subscribers sending weekly, dedicated IPs almost always make sense. Below 50K, it's a judgment call.

Three common patterns. Self-hosted Ghost for publications that want a polished, modern editorial experience and a public archive — Ghost handles the writing UI, the member management, the paid-subscription Stripe integration, and the public site; we sit underneath as the SMTP relay. MailWizz for publications that already have one or that want a more traditional email-marketing UI with deeper automation. Custom platform for the small number of publications that have unusual workflow needs (multi-author editorial workflows, custom paywall logic, integration with an existing CMS).

We don't push any of these particularly hard; what matters is that the publishing platform integrates with our SMTP relay or HTTP API correctly, that the DKIM-aligned authentication is set up right, and that the subscriber list lives in the publication's database rather than a vendor's.

Newsletter subscriptions are a paradigmatic legitimate-interest + explicit-consent scenario under GDPR. The subscriber opted in to your list; that's the legal basis. The consent record needs to be kept (timestamp, IP, source URL) for the duration of the subscription plus a defensive period (typically 3 years post-unsubscribe). Our system records all of this automatically; the data is yours to export at any time.

For publications based in the EU sending to global lists, our default EU-only routing keeps the data inside the EU regardless of where the subscriber lives. For publications based outside the EU sending to EU subscribers, the standard contractual clauses framework applies and our DPA includes them. The Schrems II issue that complicates US-routed mail doesn't apply when the routing stays in Stockholm/Frankfurt.