技术自托管：Cloudflare全栈方案搭建私有临时邮箱服务

临时邮箱这类工具，数据主权问题一直存在。公共服务用着方便，但域名、地址、存储全在别人手里。规则一变、平台一关，历史邮件清零，用户毫无办法。

自己动手搭建一个，成本可控，复杂度可控。CloudflareWorkers跑前端，EmailRouting处理入站邮件，D1做数据持久化，这套组合足够支撑一个功能完整的私有临时邮箱服务。

技术选型依据

FlashInbox是开源项目，采用Next.js+OpenNext架构，专门适配CloudflareWorkers环境。选择它的理由很直接：

不需要维护传统邮件服务器的MX、SPF、DKIM、DMARC配置。EmailRouting接管入站，Workers处理逻辑，D1存储数据，三者各司其职。成本方面，Workers日请求配额够个人使用，D1免费额度足以应付轻量场景。

三Worker架构协同机制

这套系统不是单体应用，而是三个Workers协同工作。主应用flashinbox负责网页、API、用户收件箱和管理后台。EmailWorker即flashinbox-email接收EmailRouting转发的邮件并写入D1。ScheduledWorker即flashinbox-scheduled处理清理过期邮箱、统计数据等后台任务。

关键约束：三个Worker必须指向同一个D1实例。配置错误会导致页面能打开但收不到信的奇怪现象。排查时首先确认三份wrangler配置文件中的database_id是否一致。

域名规划策略

Web访问域名与收信域名需要分开规划。推荐方案：mail.example.com用于网页访问，example.com用于实际收信域名。CloudflareEmailRouting的catch-all规则作用于主域而非子域，这个细节直接影响邮件能否正确路由。

DEFAULT_DOMAIN变量设置的是收信域名，不是网页访问域名。这个值错误会导致前端生成的临时邮箱地址与预期不符。

Secrets配置要点

部署前需要配置五组Secrets：ADMIN_TOKEN是管理后台登录凭证；KEY_PEPPER用于Key哈希，与恢复流程强绑定，修改会导致所有旧Key失效；SESSION_SECRET用于会话签名；TURNSTILE_SITE_KEY和TURNSTILE_SECRET_KEY用于防机器人验证。

KEY_PEPPER一旦设定就不要轻易改动。如果必须修改，需要同步处理已生成邮箱的Key重置问题。

domains表初始化

EmailWorker不会无条件接收邮件。它先查询D1中domains表的域名状态，只有状态为enabled的域名才能接收邮件。这个表需要在部署完成后主动初始化，否则邮件会被直接丢弃。

初始化方式二选一：通过管理后台Domains页面添加并启用域名，或者直接执行D1SQL命令插入记录。批量管理多域名时，每条域名都需要单独写入。

收信链路验证

部署完成后按顺序验证：确认domains表中收信域名存在且状态正常，检查EmailRoutingcatch-all规则是否指向flashinbox-emailWorker，确认三个Worker全部部署完成，确认三份wrangler配置的database_id一致。

使用wranglertailflashinbox-email查看EmailWorker实时日志。如果看到Domainnotfound或Domainisdisabled提示，直接回去检查domains表配置。

适用场景边界

这套方案适合：想用自有域名接收临时邮件、不想依赖公共临时邮箱服务、不想自建完整邮件服务器、愿意将基础设施统一在Cloudflare体系内的场景。

不适合：作为正式办公邮箱、接收大附件、处理复杂邮件协作。CloudflareEmailRouting对邮件大小有25MiB限制，超大邮件会被丢弃。