A single-purpose MIT tool that converts newsletters into Atom feeds. No inbox required.

TL;DR

What it is: A minimal web app that generates a throwaway email address and converts anything sent to it into an Atom feed entry [1].
Who it’s for: Anyone who prefers reading in an RSS/Atom reader (Miniflux, Newsblur, NetNewsWire, FreshRSS) but doesn’t want to give their real email address to newsletter publishers [1].
Cost: Zero. The public hosted instance at kill-the-newsletter.com is free with no account required. Self-hosting is also free — just server costs [1][2].
Key strength: Does exactly one thing and does it well. Feed is ready in under 30 seconds. No account, no password, no settings page [1].
Key weakness: Newsletter publishers can and do block Kill-the-Newsletter email addresses. Old feed entries get purged to stay under size limits. The tool has no authentication — anyone with your feed URL can spam your address or unsubscribe you from newsletters [1].

Kill-the-Newsletter is a bridge between two formats that should never have been separate. Newsletters get sent as email. Most people who actually want to read them would prefer to read them in an RSS reader alongside everything else they follow. Kill-the-Newsletter solves this with the simplest possible mechanism: you generate a unique inbox address on the site, subscribe to a newsletter with that address, and every email that arrives gets converted into an Atom feed entry you can consume in any feed reader [1].

The project is built and maintained by Leandro Facchinetti, a developer who also maintains the “Radically Straightforward” framework ecosystem. The public hosted instance lives at kill-the-newsletter.com. The GitHub repo has 2,966 stars — respectable for a single-purpose utility — and the code is MIT-licensed [2].

There is no dashboard, no account, no email import, no settings panel. The entire user interface is a single form that takes a feed name and returns an email address and an Atom feed URL. That’s the product.

Why people choose it

The appeal is narrow but real. Email newsletters have become the dominant way content creators distribute long-form writing, but the experience of receiving them is bad in a specific way: they land in your inbox mixed with everything else, they’re styled to resist archiving, and subscribing to any of them means handing over your email address to whoever runs the list.

Kill-the-Newsletter solves three things at once:

Inbox separation. Your newsletters don’t go to your inbox. They show up in your feed reader alongside your RSS subscriptions. If you already live in a feed reader, this means zero workflow change [1].

Privacy separation. The email address Kill-the-Newsletter generates has no connection to your real identity. If a newsletter publisher sells or leaks their list, or starts spamming, you delete the feed and the address is gone [1].

Feed reader consolidation. People who read newsletters and RSS content tend to prefer doing both in one place. Kill-the-Newsletter makes that possible without convincing publishers to publish RSS feeds — most of them don’t [1].

The FAQ on the official site is also honest about what doesn’t work, which is worth quoting directly: some publishers block Kill-the-Newsletter addresses entirely. Some require you to reply from the subscribing address for confirmation — which Kill-the-Newsletter can’t support because it’s receive-only [1]. For those cases the workaround is to subscribe with your real address and set up email forwarding to the Kill-the-Newsletter address, which is clunky enough to be a real limitation.

Features

The feature set is intentionally minimal [1][2]:

Core:

Create a feed in one step — name it, get an address and Atom URL [1]
Emails received at that address are converted to feed entries automatically [1]
Confirmation emails from newsletter publishers appear as feed entries with clickable confirmation links [1]
Feed management link appears at the bottom of each entry (for deleting the feed) [1]

What it does NOT have:

User accounts or authentication
Email sending / reply support
Filtering or tagging
Multiple email addresses per feed
OPML import/export
A UI for browsing your feeds after creation

The size limit behavior deserves a callout: when Kill-the-Newsletter receives a new email, it may delete old entries to keep the feed file under a maximum size [1]. This is a pragmatic concession to feed readers that choke on large files, but it means this is not an archival tool. If you need a permanent record of newsletter issues, this isn’t it.

On self-hosting: the README points to Leandro’s “Radically Straightforward” deployment guide for self-hosted instances [2]. The app itself is a Node.js project. A self-hosted instance gives you control over storage, the email domain, and the size-limit policy [2].

Pricing: SaaS vs self-hosted math

Kill-the-Newsletter doesn’t charge for anything, which makes the pricing section short.

Public hosted instance (kill-the-newsletter.com):

Free, no account required
Sustained by Patreon, PayPal, and GitHub Sponsors donations from users who find it useful [1]
No advertised limits on number of feeds or emails received

Self-hosted:

Software: $0 (MIT license) [2]
Server: A $5–6/mo VPS handles it easily — it’s a Node.js app that writes files, not a database-heavy platform
Your own domain for generated email addresses if you want clean branding

What are you actually saving by using this?

Nothing direct — newsletters are free to subscribe to. The “cost” Kill-the-Newsletter eliminates is softer: inbox management time, privacy exposure, and the friction of reading two content types in two different apps. If you’re paying for a premium RSS reader (Inoreader Pro is ~$5/mo, Feedbin is $5/mo), Kill-the-Newsletter extends that investment to cover newsletters without adding any cost [1].

The one scenario with real dollar value: privacy-conscious users who would otherwise pay for a disposable email service (SimpleLogin, AnonAddy, etc.) can handle the newsletter use case entirely through Kill-the-Newsletter without another subscription.

Deployment reality check

The self-hosted deployment path references Leandro’s “Radically Straightforward” deployment guide [2][3], not a Docker Compose file or Helm chart. This is a lighter-weight project than Activepieces or n8n — no PostgreSQL, no Redis, no worker queues. It’s closer to a Node.js script with a web interface.

What you actually need:

A Linux VPS (512MB RAM is likely sufficient)
Node.js runtime
A domain and email routing setup — the generated addresses need to actually receive email, which means configuring MX records
A reverse proxy (Caddy or nginx) for HTTPS

The email routing part is the real work. This is what separates Kill-the-Newsletter from most self-hosted tools. It’s not just a web app — it receives actual SMTP email. Setting up MX records, handling SMTP delivery, and ensuring your server isn’t on spam blocklists is non-trivial. The README links to the deployment guide rather than explaining this inline, which suggests the process has enough moving parts to need its own documentation [2].

Realistic time estimate:

Technical user comfortable with DNS and SMTP: 1–2 hours
Non-technical founder following a guide: probably a full afternoon, and there will be debugging involved
If “setting up MX records” is not a phrase you recognize: use the public instance and donate on Patreon

Pros and Cons

Pros

Genuinely free. No tier limits, no account required, no credit card. The public instance just works [1].
MIT license. Self-host, fork, embed in your own product — no commercial agreement needed [2].
Zero-friction privacy layer. Generated email addresses have no connection to your real identity. Delete the feed and the address evaporates [1].
Works with any Atom-compatible feed reader. Miniflux, FreshRSS, NetNewsWire, Inoreader, Feedbin — if it reads Atom, it works.
Confirmation emails just work. The confirmation link from a new newsletter subscription appears as a feed entry — no need to check a real inbox [1].
Tiny, auditable codebase. 2,966 GitHub stars for a tool this focused means a lot of people found it useful enough to star, and the code is simple enough to audit before self-hosting [2].

Cons

Publishers actively block it. This is listed in the official FAQ as a known limitation [1]. The Kill-the-Newsletter domain is well-known enough that publishers who want to prevent read-without-email-exposure will flag it. No workaround other than forwarding from a real address.
No reply support. Some publishers require reply-based verification. Kill-the-Newsletter can’t send email — it only receives [1]. These publishers can’t be subscribed to directly.
Feed entries get deleted. The size-limit purge means this isn’t an archive [1]. If you want to reread a newsletter issue from six months ago, it may be gone.
No authentication on feeds. Anyone who gets your Atom feed URL can see your entries. Worse, the email address is embedded in the URL, and anyone with it can spam you or trigger unsubscribes [1]. The project is explicit about this — don’t share your feed URL.
Email delivery is not guaranteed. The project acknowledges this in the FAQ: if your feed isn’t updating, first test by sending directly, then contact the publisher [1]. Deliverability issues are possible and opaque.
No active development signal. The README is four lines. The GitHub metadata in the merged profile shows “Last commit: n/a,” which combined with the minimal documentation suggests maintenance-mode status — it works but don’t expect new features [2].
SMTP self-hosting complexity. If you want your own instance, the email infrastructure setup is meaningfully harder than deploying a standard web app.

Who should use this / who shouldn’t

Use Kill-the-Newsletter if:

You already live in an RSS/Atom reader and want newsletters there too.
You’re privacy-conscious and don’t want to give your real email to every newsletter you try once.
You want a throwaway address specifically for newsletters — one you can nuke without affecting your inbox.
You’re on the public instance: zero commitment, no setup, immediate value.

Self-host it if:

You want a custom domain for the generated addresses (looks cleaner when subscribing to newsletters).
You’re building a service that needs to ingest email programmatically.
You want full control over the size-limit policy and don’t want entries purged.
You’re already comfortable with SMTP and DNS setup.

Skip it if:

The newsletters you care about actively block Kill-the-Newsletter addresses. Check before switching.
You need to archive every newsletter issue permanently — the size-limit purge makes this unreliable.
You need to reply to confirmation emails directly. Forward-from-real-address is a clunky workaround.
You don’t use an RSS/Atom reader. If you don’t have a feed reader, this tool gives you nothing — you’d need to adopt one first, and that’s a bigger behavior change.
You want a polished self-hosted deployment with Docker Compose and a maintained ops story. This is a minimal personal project, not infrastructure software.

Alternatives worth considering

Rssto.email / similar feed-from-email services: A handful of services do the same thing as Kill-the-Newsletter’s public instance. The advantage of Kill-the-Newsletter is the MIT license and the ability to self-host.

SimpleLogin / AnonAddy: If the real goal is email privacy rather than feed-reader consolidation, these are more powerful — they support replies, aliases, and catch-all domains. More complex setup, often freemium. Not focused on feed conversion.

Inoreader’s Newsletter inbox feature: Inoreader (the RSS reader) has a built-in feature that gives you an email address and adds incoming newsletters to a special folder. It works similarly but is SaaS, not self-hostable, and requires an Inoreader account. The Pro plan is ~$5/mo [no direct pricing source — verify before citing].

FreshRSS with extensions: FreshRSS is a self-hosted RSS reader that can be extended with email-to-feed plugins. More complex but keeps the entire stack in one place.

Just forwarding to your feed reader: Some feed readers accept email directly. If you’re on a platform that supports this, you may not need Kill-the-Newsletter at all.

For the target user — someone who reads RSS and wants newsletters in the same reader without giving out their email — Kill-the-Newsletter and Inoreader’s built-in feature are the practical options. Kill-the-Newsletter wins on self-hostability and zero cost. Inoreader wins on integration with a full reading UX.

Bottom line

Kill-the-Newsletter is a rare thing in software: a tool that does exactly what it says, doesn’t try to grow into something larger, and costs nothing. For the narrow use case — reading email newsletters in an RSS reader without exposing your real address — it works well. The public instance requires no commitment and is ready in 30 seconds. The limitations are real (publishers block it, entries get purged, no archive, no authentication on feed URLs) but they’re documented honestly by the project itself rather than buried in a changelog. This is a utility for a specific kind of reader, not a platform for everyone. If you already live in a feed reader and find yourself managing a separate email folder for newsletters, Kill-the-Newsletter is the fastest fix available.