ZON
Best Minds Board Private
report-20260316-173239.html
Email Isolation · Zoho CN · zondev.top · Feishu Output

AI 独立邮箱架构：Zoho Mail 中国区 + zondev.top 绑定 + 本地优先处理链路

你真正要的不是“再注册一个邮箱”这么简单，而是一套 不会碰旧邮箱、不会把验证码和信用卡类邮件暴露给 AI、又能顺手喂给 AI 获取资讯 的新边界。结论很明确：对你当前的约束，最适合的是 Zoho Mail 中国区 + 你的独立域名 + AI 只读接入 + Feishu 做输出层， 而不是直接把飞书邮箱当 AI 的主邮箱后端。

Bruce Schneier · 最小权限先于方便 Simon Willison · 避免 AI 拿到 lethal trifecta 平台团队视角 · 优先 API / OAuth / 增量同步 本次检索与核验时间：2026-03-16
推荐服务
Zoho CN
中国可达 + Mail API + 自定义域名
域名建议
zondev.top
网站与邮件可共存；必要时也可切到子域
AI 权限
Read Only
只读 ai@，不发信、不删信、不转发
输出层
Feishu
做摘要、卡片、群通知，不做主邮箱底座

Direct Answer

一句结论：可以，而且值得。你可以直接把 zondev.top 绑定到新的邮件服务上，这不会影响已经在线的网站；网站继续走原来的 A / CNAME，邮件只新增 MX / SPF / DKIM / DMARC 记录。

真正该做的配置：建 3 个新邮箱 ai@zondev.top、ops@zondev.top、vault@zondev.top。AI 只读 ai@；账单、合同、需付款或需人工回复的邮件转到 ops@；验证码、银行、信用卡、恢复邮件只进 vault@，永远不让 AI 接触。

飞书邮箱不是最优底座。截至 2026-03-16，我能确认飞书/ Lark 有邮箱产品能力，但没有找到一个清晰、公开、面向开发者的 Mail API 面。因此更合理的角色分工是：Zoho 收信，AI 处理，Feishu 输出。

Best Minds

Bruce Schneier 视角

这个问题首先不是“哪个邮箱更方便”，而是“AI 能碰到哪一层”。正确边界是：先隔离身份与权限，再谈自动化。所以新域名/新邮箱是对的，旧个人邮箱不应该被 AI 直接接入。

Simon Willison 视角

危险组合不是单一邮箱，而是“AI 能读敏感内容 + 能读不受信输入 + 还能对外执行动作”。因此你的 AI 邮箱必须避开验证码/金融类邮件，且默认不授予发送、删除、转发能力。

平台团队视角

长期稳定方案应该建立在 OAuth / REST API / IMAP / 增量同步 上，而不是网页自动化。就这个维度看，Zoho 与 Microsoft 更成熟，飞书更适合成为协作层。

Four Principles

要点 1 · 先分域，再给 AI

不要先让 AI 进旧邮箱，再试着“靠规则挡住敏感内容”。正确顺序是反过来：先用新域名或新邮箱体系建一条干净管道，再决定 AI 能看到什么。

旧个人邮箱 历史账号 / 隐私沉淀 zondev.top AI 新邮箱体系 不迁移 ai@ ops@ vault@

要点 2 · AI 只读，不执行

先证明 AI 在读信、分类、摘要这件事上真的有价值，再考虑任何写操作。否则你得到的是更快的风险，而不是更快的效率。

能力更强 风险更高 只读 打标签 转发 自动回复/删除

要点 3 · 在线同步，离线处理

你做不到让邮箱“完全不依赖网络”，但你能把需要联网的阶段压缩到同步，把真正的 AI 处理放在本地镜像之后完成。

收信 同步 脱敏 摘要输出 需要网络 本地可跑

要点 4 · 飞书做输出，不做主数据源

对你来说，飞书最大的价值是“结果抵达你”。把它放在最右侧做卡片、日报与提醒，比把它放在最左侧做邮件底座更符合当前公开能力。

Feishu 输出层 AI 处理层 Zoho 邮件底座

Why Zoho CN Fits You

1. 中国可达性更稳。你明确要求“中国可访问”，Zoho 官方文档明确区分中国区与数据中心；这比把核心链路压在 Gmail 上更符合你的约束。

2. 开发者接入不差。Zoho 官方有 Mail API，也支持 IMAP。你可以先用官方 API 做在线读取，再补一个本地镜像层，把网络依赖降到“同步时需要网络，处理时可本地运行”。

3. 自定义域名天然隔离。你的旧个人邮箱和历史绑定账户不需要迁移。新注册的资讯源、SaaS 通知、GitHub、供应商更新直接用 @zondev.top 新体系即可。

4. Feishu 正好做下游。你平时的工作流已经有飞书，所以让 AI 把结果推回飞书卡片/群/文档，比让飞书邮箱做底座更顺手。

5. 迁移弹性更高。域名在你手里。以后如果你想从 Zoho 切到 Microsoft 365，邮箱地址不必改，只是换 MX 和后端服务商。

补一句现实判断：你想要的“尽量不依赖网络”在邮箱世界里只能做到“本地优先处理”，做不到完全离网。可行做法是：在线同步，离线处理。

Provider Matrix

服务 中国场景 开发者接入 最适合你的角色 结论
Zoho Mail 中国区 官方明确有中国区与自定义域名文档 Mail API + IMAP；适合本地只读镜像 AI 主邮箱底座 第一推荐
Microsoft 365 / Outlook 可用，但“中国优先”不如 Zoho 中国区明确 Graph 最强；支持 delta / 通知 / OAuth 若你更看重 API 完整度而非中国可达性 第二推荐
Feishu Mail 中国协作体验好 截至 2026-03-16，公开 Mail API 能力不清晰 人类协作层 / 输出层 不建议做 AI 主邮箱
Gmail 中国访问不是强项 API 成熟 国际化团队或海外链路优先时可选 不符合你的硬约束

Visual Comparison

开发者接入 中国可达性 Zoho MS Feishu
决策矩阵：Zoho 中国区在你的约束里是最平衡的点。
中国访问 API 完整 Zoho 偏左 Microsoft 偏右
权衡图：Zoho 赢在中国场景，Microsoft 赢在 API 深度。
全部新邮件 AI 可读邮件 Feishu Digest
漏斗图：越往下越是“经过过滤、可以放心交给 AI 或展示给你”的内容。
中国可达 API 本地优先 隔离度 迁移性
雷达图：这 5 个维度正是你这次选邮箱时最应该看的维度。

Domain Decision

推荐：直接绑定 zondev.top

你已经有一个清晰的品牌域，而且它与“旧个人敏感邮箱”不是同一套系统。对你来说，直接用 ai@zondev.top / ops@zondev.top / vault@zondev.top 会更自然，也更利于以后统一管理。

  • 邮件 DNS 与网站 DNS 可以共存；新增 MX 不会把网站冲掉。
  • 2026-03-16 本地 HEAD 核验里，https://board.zondev.top 已是在线站点；所以不建议为了邮箱去改网站入口本身。
  • 如果你未来还想在同一根域做“人类团队邮箱”，再考虑从根域拆到子域也不迟。

备选：用子域降低爆炸半径

如果你担心以后 zondev.top 还会接更多人工邮箱，可以一开始就选 mail.zondev.top 作为邮件域。这样地址会变成 ai@mail.zondev.top，可读性略差，但隔离更彻底。

我的判断：你当前最重要的是尽快建立“AI 新邮箱体系”，不是再做一层过度设计，所以先用根域更合适。

Mailbox Split

ai@zondev.top

只收 AI 应该看的东西：newsletter、产品更新、GitHub、Vercel、SaaS 通知、供应商资讯、监控告警、RSS 转邮件。

ops@zondev.top

只给你或人工运营看：账单、合同、客户沟通、需要回复的正式邮件、需付款或需确认的事务。

vault@zondev.top

永不进 AI：验证码、恢复邮件、银行、信用卡、云平台 root、安全警报、身份与合规材料。

最重要的禁令：不要把旧邮箱做“全量自动转发”给新 AI 邮箱。你应该从今天开始，让新的低风险订阅与服务直接使用 ai@zondev.top；旧邮箱里的订阅，按低风险项目逐个迁移，而不是一键搬空。

Zoho Setup

步骤 你要做什么 注意点
1. 创建 Zoho Mail 中国区组织 在 Zoho Mail 中国区后台添加 zondev.top 如果想用子域，就在这里直接填 mail.zondev.top
2. 验证域名 按后台提示添加 TXT 或 CNAME 验证记录 验证 token 由 Zoho 后台生成，不要手写猜测
3. 创建邮箱 先建 ai / ops / vault / dmarc dmarc@zondev.top 用于接收 DMARC 报告
4. 切 MX 添加 Zoho 的 MX 记录并移除旧 MX 网站记录不动，只改邮件相关记录
5. 补 SPF / DKIM / DMARC SPF 与 DKIM 让邮件更可信；DMARC 先 p=none 先观察 3 到 7 天，再收紧到 quarantine
6. 给 AI 配只读接入 优先官方 API；需要本地镜像时再补 IMAP 只读同步 AI 不拿管理员权限，不拿全域权限
7. 做第一封测试邮件 从外部发一封测试邮件到 ai@zondev.top 确认收信、分类、摘要、飞书推送全部打通

常见 DNS 结构示例：如果使用根域 zondev.top，主机记录通常写 @；如果使用子域 mail.zondev.top，就把这些记录挂到 mail 上。

TXT   @          zoho-verification=后台给出的 token
MX    @          mx.zoho.com.cn        10
MX    @          mx2.zoho.com.cn       20
TXT   @          v=spf1 include:zoho.com.cn ~all
TXT   zmail._domainkey   后台生成的 DKIM 公钥
TXT   _dmarc     v=DMARC1; p=none; rua=mailto:dmarc@zondev.top; fo=1

MX / SPF 示例来自 Zoho 中国区官方帮助与其指向的配置指引；最终以你后台当前给出的值为准。

首次配置时序图

时序图适合解释“先做什么、后做什么”。这里我只保留 5 个角色和 8 个关键动作，不把所有 DNS 细节塞进去，否则第一次看的人会被信息量压垮。

你 DNS / 域名服务商 Zoho Mail 中国区 本地同步 / AI Runner Feishu 添加域名 zondev.top 要求 TXT / CNAME 验证 添加验证 + MX / SPF / DKIM / DMARC 域名生效，开始收信 创建 ai / ops / vault 邮箱 给本地 runner 配只读 token / IMAP 只拉 ai@ 队列并做脱敏摘要 推送 digest / 风险提醒
时序图只服务“第一次接起来”。你以后排查配置问题，就先看这张图；排查运行问题，再看下面的泳道图。

长期运行泳道图

泳道图适合解释“谁负责哪一步”。这里用三种纹理区分自动化等级：实线 是全自动，斜线虚线 是半自动或需要登录态，灰虚线 是人工动作或 AI 禁区。

INBOUND LOCAL MIRROR AI WORKER OUTPUT 新邮件进入 zondev.top 资讯 / GitHub / SaaS / 供应商更新 Zoho 规则分流 AI / OPS / VAULT 三层邮箱或文件夹 只读同步 AI 队列 Mail API 或 IMAP -> 本地 Maildir / SQLite 脱敏与阻断 剥离 OTP / 附件 / 卡号 / 恢复邮件 分类 + 摘要 资讯 / 待办 / 风险 / 跟进 生成 digest / task feed 保留来源链接与主题聚合 禁止自动发信 默认不回复、不删除、不转发 Feishu digest 日报 / 卡片 / 群通知 ops@ 人工复核 账单 / 合同 / 需付款 / 需回复 vault@ 永不进 AI 验证码 / 银行 / 信用卡 / 恢复邮件
泳道图：Zoho 负责收信与分流，本地 runner 只读镜像 AI 队列后再做脱敏与摘要，Feishu 只接收结果，vault 永不进 AI。

AI Flow

推荐处理链路

  1. Zoho 收到新邮件，先用规则分成 AI / OPS / VAULT 三层。
  2. 本地 runner 只读同步 ai@ 或其指定文件夹，不读取 vault@。
  3. 本地先脱敏：剥离附件、验证码、卡号样式、恢复链接，再交给 AI。
  4. AI 做分类、摘要、待办提取，并按主题聚合成 digest。
  5. 结果推到 Feishu，敏感或需执行的事项升级到 ops@ / 人工复核。

一开始不要做的事

  • 不要让 AI 自动回复邮件。
  • 不要让 AI 自动删除、归档、转发邮件。
  • 不要给 AI 邮箱管理员权限或全域权限。
  • 不要把旧邮箱全量导入或全量转发到新邮箱。
  • 不要默认把附件正文都喂给模型，先只处理标题、发件人、摘要和纯文本。

Feishu Role

Feishu 最适合做的事：承接 AI 处理结果。比如：每天 9 点把 ai@zondev.top 昨天的资讯摘要发到一个飞书群；遇到“需人工回复”或“账单异常”时单独推送卡片给你。

Feishu 现在不适合做的事：作为 AI 邮件主数据源。因为截至 2026-03-16，我没有找到一个清晰、公开、稳定的 Feishu Mail API 文档面。所以更稳的做法是：上游用 Zoho，下游用 Feishu。

What To Subscribe With The New Inbox

适合进 ai@

  • GitHub / Vercel / OpenAI / SaaS changelog
  • 行业 newsletter
  • 内容平台周报
  • 供应商产品更新

适合进 ops@

  • 发票与付款
  • 客户往来
  • 合同与法务
  • 需要你回邮件的事

只进 vault@

  • OTP / MFA
  • 银行与信用卡
  • 密码重置
  • 云平台 root / 安全告警

迁移策略

  • 新注册的资讯源直接用新邮箱
  • 旧订阅按低风险逐个迁移
  • 先迁 newsletter，再迁 SaaS
  • 永不迁恢复与金融类

Display Guide

时序图怎么画

只画 4 到 6 个角色，箭头不超过 8 条。第一次配置时，把“域名验证、MX 切换、只读接入、飞书回推”画清楚就够了，不要把每条 DNS 记录都塞进箭头标签。

泳道图怎么画

按责任主体拆泳道：收信服务、本地同步、AI、人工/飞书。这样你以后看到故障时，第一眼就能知道是“上游没收到、同步没拉到、AI 没处理，还是飞书没发出去”。

通俗易懂的关键

不要一张图同时讲“配置过程”和“长期运行”。前者用时序图，后者用泳道图；两张图各讲一件事，普通人也能跟上。

Sources

以下优先采用官方文档或官方产品页；检索与核验时间为 2026-03-16。

这份报告的推荐是：先把“AI 读信”做成只读、可撤销、可降级的本地链路；不要一上来就把整套邮箱控制权交给模型。
这份报告把“给 AI 单独建邮箱”从想法落到可执行架构：推荐 Zoho Mail 中国区 + zondev.top 绑定，AI 只读 ai@ 邮箱，本地只读镜像后再做脱敏、摘要与飞书输出；验证码、银行、信用卡、恢复邮件永不进 AI。报告同时给出域名配置、DNS 记录、角色分层、首次接入时序图，以及长期运行的泳道图。
— One small system