Every newsletter tool I’ve looked at hands you an email address. Meco gives you something like [email protected] and tells you to “use this email to subscribe to any new newsletters that you want to read in Meco.” Digest advertises a “Newsletter Reader: get a dedicated email address for all your newsletters.” Readwise Reader, Matter, Kill the Newsletter, and the thing I work on all do a version of the same trick. (Both quotes checked live on 12 August 2026.)
It’s a good trick. Mail is the one universal API newsletters expose, and an intake address is the cheapest possible integration: no OAuth, no scraping, no partnership. I’d build it the same way.
But there’s a consequence nobody puts in the onboarding flow, and it took me a while to see it.
Your subscription list isn’t a file. It’s a side effect.
Ask where “the list of newsletters I subscribe to” actually lives. It isn’t in your reader. Your reader only knows what has arrived recently. The list lives as one row per sender, in twenty-odd separate publisher databases, keyed by the address you typed into each signup form.
So the moment you subscribe to twenty-five newsletters using [email protected], you have written your subscription list into a place you can’t read, edit, or export, in a format only the sender can query, and you’ve pinned every row to an address that exactly one vendor delivers.
That’s not a dark pattern. It’s just what happens. But it means the switching cost of a newsletter tool isn’t the ten minutes of setup people budget for. It’s re-subscribing to twenty-five things from memory, and the honest version of that sentence is: from partial memory, because the ones you’ll forget are the quarterly ones you actually like.
I went looking for an export in the three tools I know best and didn’t find one that hands you back a subscription list. I’d genuinely like to be wrong about that. If any of them ships one, say so in the comments and I’ll correct this.
Don’t give the tool your subscriptions. Give it your forwarding.
The fix costs one setup step and makes every tool in this category swappable:
Subscribe with an address you control. Forward that address to whatever tool you’re using this month.
Two versions, depending on how much you want to own.
If you have a domain. Point a subdomain or a catch-all at your mail host and subscribe as [email protected]. Better: use a per-sender alias, [email protected], [email protected]. That gives you two things for free. You can kill one sender’s alias when it’s sold to a list broker and watch exactly which one leaks. And you can grep your own mail for “which addresses got mail in the last ninety days,” which is the export the vendors don’t give you.
If you don’t. A plain Gmail address with a filter that auto-forwards to the tool works fine. Gmail makes you confirm the destination once (it mails a code to the forwarding address, so you need to be able to read the tool’s intake address, not just send to it — some tools show you the confirmation mail, some silently swallow it, and that is worth testing before you migrate twenty-five subscriptions).
Now switching readers is one filter edit. The publishers never hear about it, which is the point.
Four things that actually bite
I don’t want to hand you a clean-sounding recipe with the sharp edges filed off.
SPF breaks on forwarding. When your server relays a newsletter onward, the connecting IP is now yours, not the sender’s, so an SPF check at the destination fails unless your forwarder rewrites the envelope sender. DKIM usually survives, because it signs the message itself, but only if nothing in the path modifies the body or the signed headers. Mailing-list software that appends a footer to forwarded mail will break it. If issues start landing in spam at the destination, this is the first thing to check.
Plus-addressing is not a substitute.
[email protected]is the obvious move and it half works, but a meaningful number of signup forms reject a+in the address field outright, and some list tools normalize it away. A separate address or subdomain has none of that failure surface.Confirmation and magic-link mail follows the address. Every double opt-in, every “click here to confirm,” every account recovery for the newsletter itself now goes to the alias. If the alias is write-only, you’ll discover this at the worst moment.
One-click unsubscribe still works, and unsubscribes the right thing.
List-Unsubscribeis keyed to the recipient the publisher has on file, which is your alias, so hitting unsubscribe from a forwarded copy does the correct thing. This one is good news, but I’d rather state it than let you wonder.
The evaluation question this changes
Once you’ve separated “where my subscriptions point” from “what reads them,” the question you ask about a newsletter tool changes. Not what features does it have, but what does it cost me to leave, and does it accept mail I forward, or does it insist on being the subscription address.
That second one is a real fork, and it’s roughly the shape of the difference between these tools:
- Meco is a dedicated reading app: your newsletters move into it and you read them there. The intake address is central to the model.
- Mailbrew composes many sources into one digest email you design, and mails it back to you. (I could not verify its intake mechanics from a static fetch of the homepage — it renders client-side — so I’m describing the product, not making a claim about its address handling.)
- Digest does source aggregation plus AI summaries into a daily briefing, and ships the dedicated address as a named feature.
Those three links go to comparison write-ups I did on each. They are on my own product’s site, so read them with that in mind: I build Weekly Brief, which ranks a week of newsletters and sends one short document into Readwise Reader, Matter, or a Kindle. It takes a forwarded address, which is convenient for me to argue for, so I’m telling you plainly rather than burying it.
The advice holds regardless of which one you pick, including none of them. Own the address. Let the tool be the part you can throw away.
답글 남기기