DNS 迁移 + 邮件基础设施方案

制定日期: 2026-04-17 适用范围: 生产域名 wellchina.top 关联文档: docs/performance-monitoring-plan.md、CLAUDE.md（环境变量章节）

背景

wellchina.top 目前 DNS 由 Namesilo 托管，指向 Vercel 部署。为了同时解决三件事，整体迁移一次：

邮件接收 — 需要 hello@wellchina.top 等地址收信
邮件发送 — 系统通知（联系表单、订单、Supabase Auth）通过 no-reply@wellchina.top 发件
未来 CDN / WAF / 中国优化 — 为后续可能的 Cloudflare 橙云模式做铺垫

选定方案：DNS 迁到 Cloudflare + Resend 发 + Cloudflare Email Routing 收 + Gmail Send As 做统一收发界面。全免费。

目标架构

┌─────────────────────────────────────────────────────────────┐
│ 域名注册商: Namesilo (只保留产权登记，每年续费)             │
│   ↓ nameserver 委托                                         │
│ DNS 权威: Cloudflare (全部 DNS 解析)                        │
│   ↓ A / CNAME → Vercel (站点)                               │
│   ↓ MX → Cloudflare Email Routing (收件)                    │
│   ↓ TXT (SPF/DKIM/DMARC) → 授权 Resend 代发                 │
│                                                             │
│ 发送路径: Next.js → Resend API → 收件人                     │
│ 接收路径: 发件人 → Cloudflare MX → 转发 Gmail               │
│ 读写界面: Gmail + Send As → 以 @wellchina.top 身份收发      │
└─────────────────────────────────────────────────────────────┘

组件角色

组件	角色	费用
Namesilo	域名产权登记	已付 ~¥20/年
Cloudflare	DNS 权威 + Email Routing	免费
Resend	发送服务（SMTP + API）	3,000 封/月免费
Gmail	读写界面（含 Send As 代发）	免费

目标邮箱

地址	用途
`hello@wellchina.top`	对外公开联系地址
`support@wellchina.top`	客服 / 工单
`no-reply@wellchina.top`	系统自动发件（Resend 发出）
`dmarc@wellchina.top`	DMARC 报告收集（可选）

职责分工

[USER] — 需要你在浏览器/后台操作的步骤
[CLAUDE] — 代码和配置文件改动，由 Claude 完成

Phase 1: 迁移 DNS 到 Cloudflare

`[USER]` 1.1 Cloudflare 侧添加域名

注册 cloudflare.com 免费账号（如果还没有）
Dashboard → Add a site → 输入 wellchina.top → 选 Free 套餐
Cloudflare 自动扫描现有 DNS 记录，确认列表包含：
- A @ 216.198.79.1
- CNAME www 6fad2b69a69b422b.vercel-dns-017.com
把这两条的代理状态都设为灰云（DNS Only） — 重要，防止和 Vercel 冲突
页面底部会显示 Cloudflare 的两个 nameserver，类似：
- xxx.ns.cloudflare.com
- yyy.ns.cloudflare.com
复制这两个值，下一步用

`[USER]` 1.2 Namesilo 侧切 nameserver

进 Namesilo → wellchina.top → Quick settings → NameServers → Edit
删除三个默认的 NS1/NS2/NS3.DNSOWL.COM
替换为 Cloudflare 给的两个 nameservers
Save

`[USER]` 1.3 等待激活（15 分钟 - 4 小时）

Cloudflare 页面 → 你的域名 → 状态从 Pending 变 Active 即完成
完成后 Cloudflare 发邮件通知
期间可以继续看本文档，但先别动其他 DNS 记录

`[USER]` 1.4 激活后验证

访问 https://wellchina.top，网站正常加载 ✅
Vercel Dashboard → Domains → wellchina.top 仍显示 Valid Configuration ✅
如有问题：Vercel 那边点 Refresh 强制重查

Phase 2: 配置 Resend（邮件发送）

`[USER]` 2.1 注册并添加域名

注册 resend.com 免费账号
Dashboard → Domains → Add Domain → 输入 wellchina.top
Resend 会显示 3-4 条需要添加的 DNS 记录（SPF TXT + 3 条 DKIM CNAME）

`[USER]` 2.2 在 Cloudflare 添加 Resend 的 DNS 记录

回到 Cloudflare → wellchina.top → DNS → Records：

按 Resend 给出的内容添加。大致长这样（具体值以 Resend 页面为准）：

Type	Name	Content	Proxy
TXT	`@` 或 `send`	`v=spf1 include:amazonses.com ~all`	DNS Only
CNAME	`resend._domainkey`	`resend._domainkey.resend.com`	DNS Only
CNAME	`resend2._domainkey`	`resend2._domainkey.resend.com`	DNS Only
CNAME	`resend3._domainkey`	`resend3._domainkey.resend.com`	DNS Only

所有邮件相关记录都必须灰云（橙云会把邮件流量挡住）。

`[USER]` 2.3 Resend 侧验证

回 Resend Domain 页面 → 点 Verify DNS Records
5-30 分钟内状态从 Pending 变 Verified
Resend → API Keys → Create API Key → 复制 re_xxxxx，妥善保存

`[USER]` 2.4 填入 Vercel 环境变量

Vercel Dashboard → 项目 → Settings → Environment Variables，在 Production 环境添加或更新：

RESEND_API_KEY=re_xxxxxxxxxxxxxxxxxxxxxxxx
FROM_EMAIL=WellChina <no-reply@wellchina.top>
ADMIN_EMAIL=你的个人@gmail.com

保存后，Vercel 会自动触发重新部署。

Phase 3: 配置 Cloudflare Email Routing（邮件接收）

`[USER]` 3.1 启用 Email Routing

Cloudflare → wellchina.top → 左侧菜单 Email → Email Routing
点 Get started → Cloudflare 自动添加所需 MX 和 TXT 记录（无需手动操作）
如果页面显示需要「Add missing records」，点一下 Cloudflare 会自动写入

`[USER]` 3.2 添加目标邮箱（Destination）

Email Routing → Destination addresses → Add destination address
输入你的个人 Gmail，比如 your-name@gmail.com
Cloudflare 发验证邮件到该 Gmail → 你在 Gmail 里点确认链接

`[USER]` 3.3 配置转发规则（Routing Rules）

添加三条：

Custom address	Action	Destination
`hello@wellchina.top`	Send to an email	your-gmail@gmail.com
`support@wellchina.top`	Send to an email	your-gmail@gmail.com
`dmarc@wellchina.top`	Send to an email	your-gmail@gmail.com

不要配置 catch-all 到个人邮箱（会收到大量垃圾邮件）。

`[USER]` 3.4 验证接收

用任意其他邮箱发一封到 hello@wellchina.top
1-3 分钟内应该出现在你的 Gmail 收件箱
如没收到：检查 Gmail 垃圾箱 + Cloudflare Email Routing → Activity log

Phase 4: Gmail Send As（统一收发）

让 Gmail 可以以 hello@wellchina.top 身份发邮件，对外看不到你的真实 Gmail 地址。

`[USER]` 4.1 Gmail 侧配置

Gmail → 右上齿轮 → See all settings → Accounts and Import
Send mail as → Add another email address
弹窗填：
- Name: WellChina
- Email: hello@wellchina.top
- 勾 Treat as an alias
Next Step，填 SMTP：
- SMTP Server: smtp.resend.com
- Port: 465
- Username: resend
- Password: 你的 Resend API key (re_xxxx...)
- 选 SSL
Next → Gmail 发确认邮件到 hello@wellchina.top → Cloudflare 转回你 Gmail → 你点确认链接
以后在 Gmail 写新邮件，From 下拉可选 hello@wellchina.top

`[USER]` 4.2 对 `support@` 重复一次

同样流程加一次 support@wellchina.top，这样可以按场景选择身份回信。

Phase 5: Supabase Auth 使用 Resend SMTP

让 Supabase 的用户注册验证邮件、密码重置邮件以 no-reply@wellchina.top 发出。

`[USER]` 5.1 Supabase Dashboard 配置

Supabase Dashboard → 项目 → Authentication → Emails → SMTP Settings
Enable Custom SMTP
填：
- Host: smtp.resend.com
- Port: 465
- Username: resend
- Password: Resend API key
- Sender email: no-reply@wellchina.top
- Sender name: WellChina
保存 → Supabase 会发一封测试邮件验证

`[USER]` 5.2 按需自定义模板

Supabase Auth → Emails → 各类模板（Confirm signup / Reset password / Magic Link 等）

模板用 Supabase 提供的变量插值，和普通 HTML 一致
可以后续再做中英多语言模板，当前默认英文够用

Phase 6: DMARC 策略

邮件反钓鱼配置，保护品牌不被冒充。

`[USER]` 6.1 在 Cloudflare 添加 DMARC 记录

Cloudflare → DNS → Add record：

Type	Name	Content
TXT	`_dmarc`	`v=DMARC1; p=none; rua=mailto:dmarc@wellchina.top; pct=100;`

策略解释：

p=none — 观察模式：收集数据不拦截，运行 2-4 周后升级
rua=mailto:dmarc@wellchina.top — 每日聚合报告发到这个地址（Cloudflare Email Routing 转到你 Gmail）
pct=100 — 对 100% 邮件应用策略
不设置 adkim/aspf — 使用默认 relaxed 对齐。关键原因：Resend 用 send.wellchina.top 作 Return-Path，严格对齐（aspf=s）会判 SPF 对齐失败

策略升级路径（2-4 周数据稳定后）：

p=quarantine — 可疑邮件进收件人垃圾箱
p=reject — 直接拒收

Phase 7: 代码与文档更新

此阶段由 Claude 完成。以下为实际执行范围（比初稿扩大）：

运行时代码

src/lib/email.ts
- L8 FROM_EMAIL 默认值：noreply@wellchina.top → no-reply@wellchina.top
- L166 env var 归一化：NEXT_PUBLIC_BASE_URL → NEXT_PUBLIC_SITE_URL
src/app/[locale]/layout.tsx
- L26 BASE_URL fallback：https://wellchina.top → https://wellchina.top

配置模板 + 脚本

.env.example 新增 NEXT_PUBLIC_SITE_URL 字段，更新 FROM_EMAIL
scripts/migrate-images-to-supabase.mjs L55 User-Agent → hello@wellchina.top
scripts/migrate-city-images.mjs L43 同上

文档

CLAUDE.md 环境变量章节：新增 NEXT_PUBLIC_SITE_URL 说明，引用本迁移文档
README.md L84 更新 FROM_EMAIL 示例 + 新增 NEXT_PUBLIC_SITE_URL 示例
docs/getting-started.md L62 同上
docs/internationalization-plan.md 8 处 wellchina.top → wellchina.top
docs/mvp-monetization-plan.md L548 footer attribution
本文档 Phase 7 章节刷新为实际执行结果

`[USER]` 代码部署后的外部动作

Vercel Dashboard → Production env → 新增 NEXT_PUBLIC_SITE_URL=https://wellchina.top
若 Vercel 里还有旧的 NEXT_PUBLIC_BASE_URL 环境变量，删除（已归一化到 SITE_URL）
触发重新部署（NEXT_PUBLIC_* 是 build-time baked，env 变更后必须 redeploy 才生效）
本地开发者若 .env 里设过 NEXT_PUBLIC_BASE_URL，改名为 NEXT_PUBLIC_SITE_URL

Phase 8: 长期投递率优化（持续进行）

新域名 + .top TLD 的初期邮件大概率进收件人垃圾箱，这是 Gmail/Outlook 对新域和 .top 的结构性不信任，不是配置错。本节列出持续优化项。

为什么新域名进垃圾箱（根因分析）

原因	权重	时间尺度
域名注册时间短	高	3-6 个月内慢慢改善
`.top` TLD 历史声誉	高	结构性，无法完全消除
发件 IP 共享池	中	Resend 已保证，无需管
缺历史互动	中	通过用户回信积累
无 DMARC 策略	低	Phase 6 已解决

立刻能做的快速动作（对自己的 Gmail 有效）

把垃圾箱里的邮件标 "Not spam" — Gmail 立刻记住 wellchina.top 可信
把 no-reply@wellchina.top 和 hello@wellchina.top 加为 Gmail 联系人
回复一次自己收到的邮件（即使发回自己）— 形成双向对话信号

中期优化清单

优化项	预期效果	难度	触发时机
DMARC `p=none` → `p=quarantine`	中等声誉提升	低	Phase 6 后 2-4 周
DMARC `p=quarantine` → `p=reject`	高等声誉提升	低	前一步稳定后再 4 周
注册 Google Postmaster Tools	拿到投递反馈数据	低（10 分钟）	有一定发信量后
添加 `List-Unsubscribe` 头	营销/通知类必需	中（代码层）	开始做 newsletter 前
发信量温和爬坡	建立 IP/域信誉	自然	上线后 1-3 个月
持续监控退信率	控制在 < 2%	低	Resend Dashboard 每周看

长期战略决策

.top TLD 的垃圾箱倾向是结构性的。即使 SPF/DKIM/DMARC 全绿、Google Postmaster 里所有指标优秀，Gmail 对 .top 的基础分就是低于 .com/.org。

如果未来 WellChina 实现商业化且确认长期运营，建议把 wellchina.top 作为 MVP 阶段临时方案，正式品牌用 .com。届时迁移成本包括：

注册新 .com 域名
重配 DNS（Cloudflare 多域支持原生）
Resend / Cloudflare Email Routing 添加新域（旧域可保留作 redirect）
全站 FROM_EMAIL / metadataBase / Vercel 域名切换
SEO 301 redirect（旧域→新域），保留至少 6 个月

投递率监控

定期看这三处数据：

来源	查什么	频率
Resend Dashboard → Logs	退信率、投递失败原因	每周
Google Postmaster Tools	Gmail 用户垃圾箱率、域信誉评分	每 2 周
Cloudflare Email Routing → Activity	收件的 SPF/DKIM/Spam 状态	有问题时查

绝对不要做的事

❌ 群发大量邮件建立声誉 — 反效果，会被标为垃圾邮件源
❌ 买第三方邮件列表 — 直接封号
❌ 发送时加入过多营销话术 — "FREE"、"CLICK HERE" 等关键词会触发过滤
❌ 用公共 SMTP 中继（如 Gmail 普通账号）代发 — SPF 对齐失败

验证清单（全部完成才算收工）

DNS

[ ] Cloudflare Dashboard → wellchina.top 状态 = Active
[ ] Namesilo 的 nameservers 已更换为 Cloudflare 的
[ ] dig +short wellchina.top @1.1.1.1 返回 216.198.79.1
[ ] 访问 https://wellchina.top 网站正常打开
[ ] Vercel Dashboard → Domains → 全部 Valid Configuration

发送（Resend）

[ ] Resend Domain 状态 = Verified
[ ] Vercel 环境变量 RESEND_API_KEY / FROM_EMAIL / ADMIN_EMAIL 已设置
[ ] 部署后从网站提交联系表单，验收管理员收到通知 + 用户收到确认邮件
[ ] 检查收件邮件 headers 的 SPF / DKIM / DMARC 都是 pass

接收（Cloudflare Email Routing）

[ ] Email Routing 状态 = Enabled
[ ] 从其他邮箱发到 hello@wellchina.top → Gmail 收到
[ ] support@wellchina.top 同上验证
[ ] Cloudflare → Email Routing → Activity log 显示转发成功

Gmail Send As

[ ] Gmail 写信可选 hello@wellchina.top 作为发件人
[ ] 用 Send As 发一封测试邮件到外部邮箱，对方看到发件人是 hello@wellchina.top 而非你的 Gmail

Supabase Auth

[ ] Supabase Auth → 测试用户注册 → 收到验证邮件，发件人为 no-reply@wellchina.top

代码

[ ] src/lib/email.ts 默认值已更新
[ ] .env.example 已更新
[ ] CLAUDE.md 已更新
[ ] 本地 .env 对应更新
[ ] 所有更新已提交 PR

回滚方案

如果任一阶段出问题需要回退：

DNS 迁移失败（Phase 1）

Namesilo → NameServers → 改回原来的 NS1/NS2/NS3.DNSOWL.COM
等 DNS 传播（15 分钟 - 4 小时）
所有 Cloudflare 配置保持不动，下次可以重试

Resend 验证不过（Phase 2）

不影响线上，RESEND_API_KEY 未设置时 src/lib/email.ts 会 skip 发送
检查 Cloudflare DNS 里 Resend 给的 4 条记录是否拼写正确
用 dig TXT wellchina.top / dig CNAME resend._domainkey.wellchina.top 直查

Email Routing 收不到（Phase 3）

Cloudflare Dashboard 检查 MX 记录是否存在
Activity log 查看是否有投递被拒绝（常见：Destination address 未验证）
重新发 Destination 验证邮件

Send As 验证失败（Phase 4）

常见原因：SMTP 密码填错（应该填 Resend API key 本体，不是 Bearer 前缀版）
确保 Resend Domain 是 Verified 状态
检查端口是 465（SSL）而不是 587

执行顺序总结

[USER] Phase 1 (DNS 迁移)           ← 必须先做，其他都依赖这个
   ↓ 等 Cloudflare Active
[USER] Phase 2 (Resend 添加域名)    ┐ 这两个可以并行
[USER] Phase 3 (Email Routing)      ┘
   ↓ 两个都 ready
[USER] Phase 4 (Gmail Send As)      ← 依赖 Phase 2 + 3
[USER] Phase 5 (Supabase SMTP)      ← 依赖 Phase 2
[USER] Phase 6 (DMARC)              ← 依赖 Phase 2 验证通过
[CLAUDE] Phase 7 (代码更新)          ← 可以随时做，代码默认值更新与上线解耦
[USER+CLAUDE] 最终验证清单           ← 全部打勾收工
[USER] Phase 8 (长期优化)            ← 持续进行，跨越数月

预估时间

总操作时间：约 1.5-2 小时（不算 DNS 传播等待）
DNS 传播等待：15 分钟 - 4 小时
整体完成（含等待）：当天内

DNS 迁移 + 邮件基础设施方案 ​

背景 ​

目标架构 ​

组件角色 ​

目标邮箱 ​

职责分工 ​

Phase 1: 迁移 DNS 到 Cloudflare ​

[USER] 1.1 Cloudflare 侧添加域名 ​

[USER] 1.2 Namesilo 侧切 nameserver ​

[USER] 1.3 等待激活（15 分钟 - 4 小时） ​

[USER] 1.4 激活后验证 ​

Phase 2: 配置 Resend（邮件发送） ​

[USER] 2.1 注册并添加域名 ​

[USER] 2.2 在 Cloudflare 添加 Resend 的 DNS 记录 ​

[USER] 2.3 Resend 侧验证 ​

[USER] 2.4 填入 Vercel 环境变量 ​

Phase 3: 配置 Cloudflare Email Routing（邮件接收） ​

[USER] 3.1 启用 Email Routing ​

[USER] 3.2 添加目标邮箱（Destination） ​

[USER] 3.3 配置转发规则（Routing Rules） ​

[USER] 3.4 验证接收 ​

Phase 4: Gmail Send As（统一收发） ​

[USER] 4.1 Gmail 侧配置 ​

[USER] 4.2 对 support@ 重复一次 ​

Phase 5: Supabase Auth 使用 Resend SMTP ​

[USER] 5.1 Supabase Dashboard 配置 ​

[USER] 5.2 按需自定义模板 ​

Phase 6: DMARC 策略 ​

[USER] 6.1 在 Cloudflare 添加 DMARC 记录 ​

Phase 7: 代码与文档更新 ​

运行时代码 ​

配置模板 + 脚本 ​

文档 ​

[USER] 代码部署后的外部动作 ​

Phase 8: 长期投递率优化（持续进行） ​

为什么新域名进垃圾箱（根因分析） ​

立刻能做的快速动作（对自己的 Gmail 有效） ​

中期优化清单 ​

长期战略决策 ​

投递率监控 ​

绝对不要做的事 ​

验证清单（全部完成才算收工） ​

DNS ​

发送（Resend） ​

接收（Cloudflare Email Routing） ​

Gmail Send As ​

Supabase Auth ​

代码 ​

回滚方案 ​

DNS 迁移失败（Phase 1） ​

Resend 验证不过（Phase 2） ​

Email Routing 收不到（Phase 3） ​

Send As 验证失败（Phase 4） ​

执行顺序总结 ​

预估时间 ​