自己发邮件，才是真自由

自己的 Newsletter 平台：别再靠别人了

还记得 Tinyletter 吗？很多写作者都用过。那时候的它又轻又好用：写完直接发，读者收到了就看。没有任何花里胡哨的转化漏斗、点击率追踪。

后来呢？2024 年 2 月，Mailchimp 直接把它关了。很多人这才发现一个残酷事实——你不付费、或者你不是他们的核心用户，服务随时可能说关就关。

这不是个例。现在越来越多的独立创作者、开发者、小型内容站开始把 Newsletter 收回来，自己管。

第三方平台的坑

用别人的平台听起来很省事。SPF、DKIM、DMARC、退信处理这些麻烦事都不用管，别人帮你搞定。

但问题来了。

大多数平台是为营销团队做的，不是为写作者准备的。它们主推模板、拖拽编辑、追踪像素、用户分群……你真正想知道的其实只有一件事：读者有没有看懂我的内容。可这些工具偏偏不关心这个。

更麻烦的是按订阅人数收费。小众但忠实的读者群，费用却可能高得离谱。而且一旦你的用法跟平台的主流用户不一样，你就成了“边缘用户”，随时可能被砍掉功能。

最要命的一点：你的读者其实不属于你。一旦平台倒闭或改方向，你得从零开始。

自己托管其实没那么难

自己管 Newsletter，不等于要当运维。关键是把东西放在自己能控制的地方，用稳定的工具搭一套简单的系统。

现在的做法大致是这样的：

内容用 Git 管理
把每一期 Newsletter 写成普通的 markdown 文件，存在代码仓库里。想迁移就迁移，不会被锁在别人数据库里。

用 API 发邮件
你不需要营销后台，只需要一个干净的 API。把订阅者列表和邮件内容传过去，剩下的投递、退信、合规问题交给专业服务商处理。Postmark、Resend、SendGrid、Mailgun 这些都能用，开源的 Plunk 也可以。

命令行就够了
做一个简单的 CLI 工具，放在仓库里。把 markdown 转成邮件，管理订阅者 CSV，跟发送服务对接。不要网页界面，少点干扰。

保持简洁
纯文本加个简单 HTML 版就行。读者看的是你的文字，不是设计。

一个实际的目录结构

newsletter/
├── issues/           # 每期一个 md 文件
│   ├── 1.md
│   ├── 2.md
│   └── 3.md
├── subscribers.csv   # 订阅者列表，放进 Git
├── send/             # 发送脚本
│   ├── send.py
│   └── config.yaml
├── web/              # 简单的订阅接口
│   └── subscribe.py
└── .github/workflows/
    └── backup.yaml   # 定期备份

整个系统可预测、好排查，也方便迁移。想换发送服务，改个配置文件就行。想加 RSS 或自动发到社交平台，自己在代码里加就好了。

关于送达率

很多人担心自己发邮件会被归到垃圾箱。

其实现在不用自己全包。靠谱的发送服务商已经把 SPF、DKIM、DMARC、域名信誉这些事做好了。你只要用他们的 API，就能借用他们维护好的基础设施。

真正重要的还是内容本身。停更很久后重新发一封诚恳的邮件，读者反而更愿意打开。

成本其实很低

自己托管不是免费，但很便宜。小规模发送的话，一千封邮件大概只要 1-2 美元，比你写稿时喝的咖啡还便宜。

和按订阅人数收费的平台比，这笔钱几乎可以忽略。

把渠道拿回来

掌握自己的分发渠道，就像拥有自己的印刷机。你不用再租别人的平台，担心哪天对方改方向。

这对独立写作者、技术博主、公开做项目的创始人尤其重要。Newsletter 是你和读者最直接的联系方式，比 Twitter 稳定，比博客更亲密，也不会被算法左右。

现在工具已经足够成熟。Fly.io、AWS Lambda、Railway 让跑小服务变得又便宜又简单。开源的发送层也越来越好用。

怎么开始

想把 Newsletter 收回来，可以按下面几步走：

1. 先看看你现在用什么服务，订阅者列表存在哪里，有没有备份。
2. 挑一个 API 好用、按实际用量收费的发送服务。
3. 从最简单的开始：一个放 markdown 的文件夹 + 一个 CLI 脚本 + 一个订阅接口。
4. 所有东西都放进 Git，方便版本管理。
5. 别忘了读者体验。自己托管不是借口，内容质量还是第一位。

Newsletter 的“自建潮”正在发生。不是因为时髦，而是因为大家发现：把渠道握在自己手里，才是最稳的。

你的文字，值得一个不会突然消失的地方。