Every newsletter tool hands you an email address. That address is the lock-in.

Every newsletter tool I've examined gives you an email address. Meco assigns you something like edward@mecoinbox.com and instructs you to use that address to subscribe to any new newsletters you wish to read in Meco. Digest advertises a Newsletter Reader: a dedicated email address for all your newsletters. Readwise Reader, Matter, Kill the Newsletter, and the platform on which I'm writing all employ a similar approach.

(Both quotes confirmed live on 12 August 2026.) This strategy offers benefits: mail is the universal API newsletters utilize, and an intake address represents the most cost-effective integration method — it necessitates no OAuth, scraping, or partnership.

The issue here is that the subscription list isn't a file; it's a side effect. When you inquire about the location of your subscription list, it resides in twenty-odd separate publisher databases, each keyed by the address you provided during signup. Therefore, when you subscribe to twenty-five newsletters using you@mecoinbox.com, you effectively store your subscription list in a location you can't access, edit, or export.

This address is exclusively delivered by one vendor. This isn't a dark pattern, merely a consequence of the system.

Switching cost goes beyond the ten minutes of setup typically budgeted. It involves re-subscribing to twenty-five newsletters from memory, often recalling only the recent and popular subscriptions. I searched three tools I use most thoroughly and didn't find any offering an export feature that returns your subscription list. If any of them do provide such an export, please inform me in the comments so I can update this account.

Instead of entrusting your subscriptions to these tools, provide them with your forwarding address. This requires only one setup step and ensures you can easily switch tools. Depending on your preferences, you can achieve this in two ways. If you possess a domain, point a subdomain or a catch-all at your mail host, and subscribe as newsletters@lists.yourdomain.com.

Alternatively, use a per-sender alias, such as stratechery@lists.yourdomain.com or pragmatic@lists.yourdomain.com. This provides two advantages: you can easily terminate a sender's alias if it falls into the wrong hands, and you can manually review which addresses have received mail in the last ninety days through grep in your own mail, an export not provided by the vendors.

However, there are four potential pitfalls to consider. Firstly, SPF breaks on forwarding. When your server relays a newsletter onward, the connecting IP becomes yours, not the sender's. Therefore, an SPF check at the destination will fail unless your forwarder modifies the envelope sender. Secondly, DKIM usually remains intact since it signs the message independently.

But only if nothing in the relay process alters the message body or signed headers. Thirdly, mailing-list software that appends a footer to forwarded mail could break the forwarding. Lastly, if forwarded emails land in the recipient's spam folder, this should be your initial check. Additionally, plus-addressing isn't a reliable substitute.

An address like you+news@gmail.com may work partially, but many signup forms reject the plus sign outright, and some list tools normalize it away. Consequently, using a separate address or subdomain eliminates this complication. Confirmation and magic-link mails follow the address as well. Every double opt-in, account recovery request, and account recovery for the newsletter itself now goes to the alias.

One-click unsubscribe functions correctly, so unsubscribes the appropriate recipient. Lastly, this provides a good solution, but it's worth noting.