lijianfei.com

对于独立开发者、技术创作者以及侧边项目（Side Projects）主理人而言，拥有一个形如 hi@yourdomain.com 的专属域名邮箱，不仅是树立专业个人品牌与产品可信度的第一步，也是业务联络与商务沟通的核心入口。然而，为每个独立域名购买 Google Workspace 或商业企业邮箱成本高昂；自建邮件服务器又深陷 IP 信誉受损、25 端口封禁与垃圾箱拦截的泥潭。

本文深度拆解一套已被现代工程实践广泛验证的轻量级闭环方案：将“收信路由”与“发信中继”职责彻底解耦，由 Cloudflare Email Routing 负责无状态收信流转，Resend 承担高信誉 SMTP 发信中继，最终在个人 Gmail 终端内完成统一收发与智能分类，实现真正的零服务器、零月租与专业级收发体验。

1. 为什么“收信”与“发信”必须解耦？

在传统的系统架构认知中，提到“搭建域名邮箱”，许多工程师的第一反应往往是两种极端路径：

1. 重度商业化方案（SaaS 托管）：
   • 典型代表：Google Workspace、Fastmail、Zoho 商业版；
   • 痛点：Google Workspace 基础版起步价为每月 6 美元/用户。若开发者手头拥有 5 到 10 个独立域名或实验性项目，仅邮箱基础设施一项，每年就需背负数百美元的固定支出，对于轻量级展示型站点或冷启动项目而言性价比极低。
2. 极端自建方案（自托管 Postfix / Dovecot / Stalwart）：
   • 典型代表：在 VPS 上手动搭建邮件传输代理（MTA）与 IMAP 服务；
   • 痛点：云厂商（AWS、Linode、DigitalOcean 等）默认封禁 TCP 25 端口；数据中心 IP 缺乏历史信誉积累，即便精心配置了 PTR 反向解析、SPF 与 DKIM，发出的邮件依然极大概率被 QQ 邮箱、Outlook 和 Gmail 直接丢入垃圾箱或静默拒信。此外，还要防范暴力破解、垃圾邮件中继与存储爆满风险。

现代化解耦架构的破局思路

现代云计算基础设施的发展，为邮件服务提供了全新的 关注点分离（Separation of Concerns） 可能：

flowchart TD
    subgraph Inbound["📥 收信链路（透明流转 · 零存储）"]
        Sender["外部发件人"] -->|"发送至 hi@yourdomain.com"| CF["Cloudflare Edge (MX 路由)"]
        CF -->|"SPF 合规封包无缝转发"| GmailRecv["个人 Gmail 收件箱"]
    end

    subgraph Outbound["📤 发信链路（高信誉中继 · 纯白名单）"]
        GmailSend["Gmail 发信界面 (选择域名别名)"] -->|"Authenticated SMTP (465 SSL)"| Resend["Resend 发信引擎 (smtp.resend.com)"]
        Resend -->|"DKIM 签名 + 顶级 IP 池投递"| Recipient["目标收件人 (QQ/Outlook/Gmail)"]
    end

    subgraph Client["💻 交互终端（统一界面）"]
        GmailRecv -.-> GmailApp["Gmail Web / iOS / Android 客户端"]
        GmailApp -.-> GmailSend
    end

    classDef blue fill:#e3f2fd,stroke:#1565c0,stroke-width:1px,color:#0d47a1;
    classDef orange fill:#fff3e0,stroke:#e65100,stroke-width:1px,color:#bf360c;
    classDef purple fill:#f3e5f5,stroke:#7b1fa2,stroke-width:1px,color:#4a148c;
    class CF,Inbound blue;
    class Resend,Outbound orange;
    class GmailRecv,GmailSend,GmailApp,Client purple;

通过这一解耦模型，整个系统的三个组件各自只专注自己最擅长的环节：

• Cloudflare：依托遍布全球的边缘 Anycast 网络接收 MX 邮件流，毫秒级无损转发至个人 Gmail，无需在服务器上维护磁盘存储；
• Resend：现代开发者邮件服务商的标杆，提供开箱即用的高信誉投递通道，免费套餐每月提供高达 3,000 封邮件额度（日均 100 封），足以轻松覆盖个人商务联络与日常回复；
• Gmail：作为最成熟的终端交互界面，接管邮件搜索、标签归档、双重验证安全防御以及全球顶级的反垃圾过滤。

2. 核心架构时序与工作机理

为了彻底杜绝邮件交互中常见的“由 xxx 代发（via gmail.com）”警告与垃圾箱误判，整个系统在收发双向均需严格遵循 RFC 邮件投递标准。

2.1 双轨数据流时序拆解

sequenceDiagram
    autonumber
    actor Customer as 外部客户 / 用户
    participant CF_DNS as Cloudflare 边缘路由 (MX)
    actor Owner as 开发者 (Gmail 终端)
    participant Resend as Resend SMTP 集群
    participant TargetServer as 客户邮件服务器 (ISP)

    Note over Customer,CF_DNS: 链路一：接收外部邮件 (Inbound)
    Customer->>CF_DNS: 发送邮件至 hi@yourdomain.com (查询 MX)
    CF_DNS->>CF_DNS: 匹配 Routing Rule (目标地址映射)
    CF_DNS->>Owner: 转发原始邮件至 personal@gmail.com
    Note over Owner: Gmail 显示发件人为 Customer，收件人为 hi@yourdomain.com

    Note over Owner,TargetServer: 链路二：回复或发起邮件 (Outbound)
    Owner->>Owner: 点击“回复”，发件人自动保持为 hi@yourdomain.com
    Owner->>Resend: 通过 SMTP 协议提交发信请求 (AUTH API Key)
    Resend->>Resend: 校验域名所有权，注入 DKIM 私钥签名
    Resend->>TargetServer: 经由高信誉公网 IP 投递给 Customer
    TargetServer->>TargetServer: 校验 SPF、DKIM、DMARC (全部 PASS)
    TargetServer->>Customer: 纯净投递至收件箱 (无代发标签，发件人显示为 hi@yourdomain.com)

2.2 核心组件功能矩阵

3. 前置条件与准备工作

在开始配置前，请确保具备以下三项基础资源：

1. 一个已注册并托管至 Cloudflare 的顶级域名 （如 yourdomain.com，DNS 状态正常）；
2. 一个可正常登录的个人 Gmail 账号；
3. 一个已注册的 Resend 账号 （访问 resend.com 通过 GitHub 或邮箱直接注册）。

4. 全流程 5 分钟闭环配置实操

第一步：Cloudflare 开启 Email Routing 接管收信

进入 Cloudflare 控制台，点击左侧菜单的 Email Service（电子邮件） → Email Routing（电子邮件路由）。

1. 验证目标转发邮箱

• 切换至 Destination addresses（目标地址） 选项卡；
• 点击 Add destination address，输入你的个人 Gmail 地址（例如 youraccount@gmail.com）；
• 登录该 Gmail 查收来自 Cloudflare 的确认邮件，点击其中的验证链接完成激活。

2. 添加路由转发规则

• 切换至 Routing rules（路由规则） 选项卡；
• 点击 Create routing rule，新增一条规则：
  • Custom address（自定义地址）：填入你想公开的域名前缀，如 hi、contact 或 i；
  • Action（操作）：选择 Send to an email；
  • Destination（目标）：选择刚刚已通过验证的 Gmail 地址；
• 关于 Catch-all 规则的考量：

  [!TIP]
  Catch-all 规则用于兜底接收任何未单独声明的前缀邮件（如 support@、billing@）。如果你希望将所有发往该域名的邮件均转发给 Gmail，可将 Catch-all 的 Action 改为 Send to an email；若担心遭遇字典式垃圾邮件轰炸，建议保持默认的 Drop（丢弃）。

3. 确认 DNS 记录一键注入

Cloudflare 会提示自动向域名的 DNS 记录中写入 MX 解析与 SPF 认证记录：

• MX 记录：
  • route1.mx.cloudflare.net（优先级 13）
  • route2.mx.cloudflare.net（优先级 58）
  • route3.mx.cloudflare.net（优先级 87）
• TXT 记录（SPF）：
  • v=spf1 include:_spf.mx.cloudflare.net ~all

点击确认后，使用手机或第三方邮箱向 hi@yourdomain.com 发送一封测试邮件，Gmail 秒级收到即代表收信通道完全打通。

第二步：Resend 添加发信域名与 DNS 认证

收信解决后，重点攻克“发信”。普通邮件之所以进垃圾箱，核心在于缺少 DKIM 数字签名与 SPF 发件人准入。

1. 登录 Resend 控制台，在左侧导航栏点击 Domains → Add Domain；
2. 输入你的主域名（例如 yourdomain.com），Region 保持默认（如 us-east-1）；
3. Cloudflare 自动一键授权：
   • 现代 Resend 会自动识别当前域名托管在 Cloudflare，界面会弹出 Authenticate with Cloudflare 快捷授权按钮；
   • 点击授权后，Resend 会通过 OAuth 自动将 DKIM（CNAME）与发信 SPF（TXT）注入 Cloudflare DNS，完全免除手动一条条复制粘贴的繁琐过程；
4. 若选择手动添加，请务必核对以下解析条目：

[!WARNING]
手动添加 DNS 记录时的致命避坑点：
在 Cloudflare 添加 DNS 记录时，Cloudflare 会自动为所有 Name 字段隐式追加 @yourdomain.com 后缀。因此在输入 Name 时，必须只输入 resend._domainkey 或 bounces，绝对不要手动拼入完整的 resend._domainkey.yourdomain.com，否则生成的解析将变成 resend._domainkey.yourdomain.com.yourdomain.com，导致 Resend 永远显示 Not Verified！

通常等待 1~3 分钟，刷新 Resend 页面，域名状态显示为绿色的 Verified 即告成功。

第三步：生成 Resend API Key 与获取 SMTP 凭据

为了让 Gmail 能够借由 Resend 的引擎发信，我们需要获取标准的 SMTP 接入凭据。

1. 在 Resend 左侧点击 API Keys → Create API Key；
   • Name：建议填写 gmail-smtp 或域名标识；
   • Permission：选择 Sending access （仅允许发信权限，遵循最小特权原则）；
   • Domain：选择刚刚已通过验证的域名；
2. 点击创建后，页面会展示一串形如 re_12345678_xxxxxxxxxxxxxxxxxxxx 的秘钥。请立刻复制并妥善保存，关闭弹窗后无法再次查看；
3. 查看 Resend 官方标准的 SMTP 连接参数（位于 Settings → SMTP）：

SMTP 服务器 (Server) ：smtp.resend.com
服务端口 (Port)     ：465（推荐 SSL）或 587（TLS）
登录用户名 (Username) ：resend
登录密码 (Password)   ：刚刚复制的 API Key（re_ 开头）

[!IMPORTANT]
Gmail 认证高频踩坑点：
绝大多数用户在配置时报错“用户名或密码错误”，是因为习惯性地将用户名填成了自己的邮箱地址（如 hi@yourdomain.com），或将密码填成了 Resend 网页控制台的登录密码。
请牢记：用户名必须固定填纯文本 resend，密码必须填 re_ 开头的 API Key！

第四步：在 Gmail 中配置“通过其他地址发送”

现在，将 Resend SMTP 接入 Gmail 核心引擎，实现“以专属域名身份发信”。

1. 开启别名配置

• 登录个人 Gmail 网页端，点击右上角齿轮图标 → 查看所有设置（See all settings）；
• 点击顶部的 账号和导入（Accounts and Import） 标签页；
• 找到 用这个地址发送邮件（Send mail as） 栏目，点击右侧的 添加其他电子邮件地址（Add another email address）。

2. 填写身份基础信息

• 在弹出的黄色窗口中：
  • 名称（Name）：对方收件人看到的发件人姓名（例如：李剑飞 或 Jeffery Li）；
  • 电子邮件地址：你的完整域名邮箱（例如：hi@yourdomain.com）；
  • 视为别名（Treat as an alias）：保持勾选 （确保 Gmail 将其与主账号智能聚合）；
• 点击 下一步（Next Step）。

3. 填入 Resend SMTP 接入参数

• SMTP 服务器：smtp.resend.com；
• 端口：选择 465；
• 用户名：填入 resend；
• 密码：粘贴刚刚生成的 re_ 开头 API Key；
• 连接安全类型：勾选 使用 SSL 的安全连接 （推荐）；
• 点击 添加账号（Add Account）。

+-----------------------------------------------------------+
| 添加其他电子邮件地址                                       |
+-----------------------------------------------------------+
| 通过你的 SMTP 服务器发送邮件：                             |
|                                                           |
| SMTP 服务器： smtp.resend.com             端口：465       |
| 用户名    ： resend                                      |
| 密码      ： re_••••••••••••••••••••                     |
|                                                           |
| (•) 使用 SSL 的安全连接 (推荐)                            |
| ( ) 使用 TLS 的安全连接                                   |
|                                                           |
|                   [ 取消 ]       [ 添加账号 ]              |
+-----------------------------------------------------------+

4. 闭环验证：第一封验证信去哪儿收？

点击添加账号后，Gmail 会立即向 hi@yourdomain.com 发送一封包含 8 位数字验证码的确认邮件。
此时，第一步中搭建的 Cloudflare 转发链路瞬间发挥奇效：
这封邮件会在 1 秒钟内被 Cloudflare 截获并无缝推送到当前同一个 Gmail 收件箱！打开 Gmail 收件箱，复制验证码并粘贴回确认窗口，点击“验证”即可。

5. 关键优化配置：自动化智能回复

回到 Gmail 的 账号和导入 设置页，找到 回复邮件时（When replying to a message） 选项：

• 务必勾选：从接收邮件的地址回复 (Reply from the same address the message was sent to)。

[!TIP]
开启此选项后，凡是发往 hi@yourdomain.com 的客户咨询，你点击回复时，Gmail 会自动锁定发件人为你的域名邮箱；而发往你个人私密邮箱的信件，回复时依然保持个人 Gmail。彻底告别因粗心大意导致私密邮箱泄露的窘境。

第五步：全链路投递与邮件信誉深度测试

完成配置后，必须执行端到端的发信联调与合规性自检。

1. 真实收发测试

• 使用外部邮箱（如 QQ 邮箱、163 邮箱或公司 Outlook 账号）向 hi@yourdomain.com 发送一封测试邮件；
• 在 Gmail 中收到后，直接点击回复，正文中输入测试内容并点击发送；
• 回到外部邮箱查收，确认两项核心视觉细节：
  1. 发件人完整显示为 李剑飞 <hi@yourdomain.com>；
  2. 没有任何“由 xxx 代发”或 via gmail.com 的劣质外链标注。

2. 原始邮件安全头检查（SPF / DKIM / DMARC）

在收到的邮件右上角菜单中，点击 查看邮件源码（Show original），检查安全指标头：

Authentication-Results: mx.qq.com;
  spf=pass (smtp.mailfrom=bounces.yourdomain.com) ...
  dkim=pass header.i=@yourdomain.com ...
  dmarc=pass (p=NONE) ...

当 SPF: PASS 与 DKIM: PASS 双绿灯点亮时，代表该发信节点的信誉评级已达到主流邮件运营商的最高准入标准。此外，登录 Resend 后台的 Logs 页面，还可以清晰观测到每一封邮件的投递耗时、ISP 握手状态与送达情况。

5. 深度技术原理与避坑清单

许多初次搭建该架构的工程师常会遇到一些难以排查的“幽灵故障”，以下梳理底层原理与避坑要领：

5.1 为什么 Cloudflare 与 Resend 的 SPF / MX 不会产生冲突？

许多开发者担心：在同一个根域名下既配了 Cloudflare 收信的 MX，又配了 Resend 发信，DNS 记录会不会互相污染？

• MX 记录隔离：
  • 域名在根域（yourdomain.com）只能有一套生效的 MX 记录。Cloudflare Email Routing 接管了根域 MX；
  • Resend 作为发信中继，其自身处理退信通知的 MX 记录被放置在独立的 二级子域名 （bounces.yourdomain.com）上，与主域收信完全物理隔离。
• SPF 记录准则：
  • 国际邮件协议严禁同一个主机名下存在两条独立的 v=spf1 TXT 记录（否则会被判定为 PermError）；
  • 主域名的 SPF 指向 Cloudflare（include:_spf.mx.cloudflare.net）；
  • 发信流量由 Resend 子域的专属 SPF（bounces.yourdomain.com 对应的 include:amazonses.com）承担，因此两者相安无事、完美共存。

5.2 常见异常自查手册

6. 2027 年 Google Gmail 政策收紧与长期演进推演

在规划技术选型时，必须保持对上游平台政策的敏锐度。Google 此前已发布针对个人 Gmail 账号的合规演进通告：计划在 2027 年起逐步收紧或弃用免费版 Gmail Web 端直接配置第三方外部 SMTP（Send mail as）的功能。

这一变动会对当前架构造成实质性威胁吗？答案是：完全无须焦虑，解耦架构赋予了我们极致的平滑演变弹性。

flowchart LR
    Origin["当前架构 (2026 前半场)"] --> CF_In["Cloudflare 收信 (永久免费)"]
    Origin --> Resend_Out["Resend SMTP (3000封/月)"]
    Origin --> Gmail_Web["Gmail Web 外部 SMTP"]

    Gmail_Web -.->|"2027 政策收紧"| Evolutions["演进路径储备"]
    
    subgraph Pathways["平滑演进方案"]
        P1["路径 A：原生客户端 (macOS Mail / Thunderbird / Spark)<br/>直接多端直连 Resend SMTP + Gmail IMAP"]
        P2["路径 B：无服务器化 Cloudflare Workers<br/>Email Routing + Workers 调用 Resend REST API"]
        P3["路径 C：迁移至高性价比独立托管平台<br/>(Migadu / Purelymail 等极简纯邮箱)"]
    end

    Evolutions --> Pathways

    classDef curr fill:#e8f5e9,stroke:#2e7d32,stroke-width:1px,color:#1b5e20;
    classDef warn fill:#fff3e0,stroke:#e65100,stroke-width:1px,color:#bf360c;
    classDef path fill:#e3f2fd,stroke:#1565c0,stroke-width:1px,color:#0d47a1;
    class Origin,CF_In,Resend_Out curr;
    class Gmail_Web,Evolutions warn;
    class Pathways,P1,P2,P3 path;

1. 路径 A：本地客户端原生直连（零改造成本）：
   • Google 收紧的仅是个人 Gmail 网页端（Web Interface）的外部 SMTP 中继行为；
   • 开发者常用的系统原生客户端（如 macOS Mail、iOS 邮件、Thunderbird、Spark、Outlook 桌面端）天生支持任意维度的 SMTP 发信配置。在客户端中，收件走 Gmail IMAP，发件直接连 smtp.resend.com，使用体验丝滑无感。
2. 路径 B：Cloudflare Email Workers + REST API 全自动化：
   • 伴随 AI Agent 与工作流的普及，邮件早已不仅仅是人工查看的工具。通过 Cloudflare Email Workers 脚本，我们可以在边缘端编写几行 JavaScript，在邮件到达瞬间直接触发 Webhook，甚至借助 Resend 的官方 Node.js / Python SDK 自动完成智能回复与事件流转。
3. 路径 C：按需平滑迁移至专业域名邮箱：
   • 当业务规模扩张、发信量突破每月数万封时，再平滑升级至 Google Workspace、Migadu 或自建高可用集群。在业务冷启动与快速验证期，当前方案依然是 ROI（投入产出比）最高的工业级最优解。

7. 总结

在现代软件工程实践中，“不花冤枉钱”与“不浪费运维精力在低价值琐事上”是保持敏捷开发的核心法则。

通过本文拆解的 Cloudflare + Resend + Gmail 组合拳，我们用极简的配置打破了商业软件的高昂门槛，在 5 分钟内构建出了一个包含完整 SPF、DKIM 认证、零服务器开销且每月享有 3,000 封免费发信额度的现代化个人域名邮箱系统。

8. 原文链接与参考资料

• 原文链接：🎉免费个人域名邮箱！Cloudflare + Gmail + Resend 5分钟配置「完整教程」 - Lonely (@Lonely__MH)
• 官方参考资料：
  • Cloudflare Email Routing 官方快速入门文档
  • Resend SMTP Service 官方发布与接入指引
  • Google 帮助中心：通过其他电子邮件地址发送邮件 (Send mail as)