Resend.com 怎样配置只收邮件？保姆级教程来了
最近在折腾项目的时候，发现不少小伙伴都在用 Resend.com 这个服务，毕竟比起传统的 SMTP 服务，它的 API 调用实在方便太多，而且自带不错的 Deliverability（送达率）。不过，大家大多把它当成一个纯粹的“发信工具”，实际上 Resend 也是支持接收邮件的（Inbound Email）。
既然收到了不少私信问“Resend.com 怎样配置只收邮件？”，今天干脆写个保姆级流程，教大家如何把这个“发信神器”变成一个“收信中转站”。
为什么要用 Resend 收信？
可能你会问，收信用 Gmail 啊、企业邮啊不香吗？确实，但在某些自动化场景，或者你想把邮件直接转发到自己的私有服务器做二次处理（比如工单系统、自动回复机器人），Resend 的 Webhook 方式就显得非常优雅。
甚至有些域名，我们只想收信不想发信（或者说不需要它承担发信任务），这时候配置一个 Inbound 的路由就非常合适。
准备工作：域名解析先行
在登录 Resend 控制台之前，你得先搞定 DNS。Resend 的收信原理其实很简单：通过 MX 记录告诉全世界，“发给这个域名的邮件，请送到 Resend 的服务器上”。
Resend 控制台中的 Inbound 配置界面，展示如何设置 Webhook URL
具体操作如下：
- 打开你的域名 DNS 管理面板（比如 Cloudflare、Namecheap 或阿里云）。
- 找到 MX 记录设置项。
- 添加一条新的 MX 记录（通常需要添加两条以确保冗余）。根据 Resend 官方目前的指引，主机记录（Host/@）填你想收信的域名（比如
example.com或mail.example.com），记录值指向 Resend 提供的 MX 服务器地址（通常是mx.resend.com这类的，具体以控制台显示为准）。
注意： 如果你原本域名有其他邮箱服务（比如腾讯企业邮、Google Workspace），添加 MX 记录可能会冲突，这会导致你的老邮箱收不到信。所以请确保你是在一个专门用于测试的域名，或者做好了备份。
控制台配置：设置接收路由
DNS 生效后（通常几分钟到几小时不等），就可以在 Resend 里开始干活了。
- 进入 Resend Dashboard，找到 "Inbound" 或者 "Domains" 下的相关设置。
- 这里会有一个选项让你设置“如何处理收到的邮件”。
- 核心步骤来了： 很多卡在这一步的朋友其实不知道填什么。你需要配置一个 Webhook URL。也就是说，当邮件飞到 Resend 服务器时，它需要知道往哪里“扔”这封信。
如果你只是想测试接收，而暂时没有现成的后端服务器，可以使用一些 Webhook 测试工具（如 webhook.site）生成一个临时链接填进去，这样就能亲眼看到邮件数据包长啥样了。
对于只想“只收不发”或者单纯看看效果的场景，我们其实不需要配置复杂的 Sending API Key，除非你还要用这个域名回信。
进阶玩法：把邮件存下来或转发
只收邮件的最终目的肯定不是为了看一眼 JSON 数据，通常我们有两种常见的处理方向：
- 自动转发： 写一段简单的 Node.js 或 Python 脚本，监听 Resend 发过来的 POST 请求，解析出邮件正文和附件，然后通过 SMTP 转发到你常用的个人邮箱。这相当于造了一个属于你自己的邮件转发网关。
- 存入数据库： 比如你在做一个 SaaS 产品，用户的反馈邮件可以直接通过这种方式入库，自动创建 Ticket，完全不需要人工去查收。
避坑指南与常见问题
- 收不到邮件怎么办？ 这通常是 DNS 解析还没全球生效，或者是 MX 记录优先级（Priority）设置错误。一定要再次检查 MX 记录是否指向了正确的 Resend 服务器，且没有其他优先级更高的记录在抢占。
- 被标记为垃圾邮件？ Resend 的 inbound 筛选相对宽松，但如果你的域名信誉不好（比如刚注册且发过垃圾信），可能会影响接收。建议保持 IP 和域名的健康度。
- 关于“只收”的限制： 技术上讲，只要你不调用 Resend 的 API 去发信，它对于你来说就是一个“只收”的服务。但 Resend 的计费通常是捆绑的，即使你只用 Inbound，可能也需要关注下套餐里的额度限制，别玩脱了被扣钱。
总结
Resend.com 不仅仅是个发信大户，利用好它的 Inbound 功能，我们可以搭建起非常灵活的邮件流转管道。不管你是为了自动化测试，还是想避开传统邮局的繁琐配置，试试这个方案，可能你会打开新世界的大门。
如果你在配置 Webhook 或者 DNS 解析上遇到具体的问题，欢迎在评论区留言，咱们一起排查！
评论已关闭