Resend 域名验证失败，优先查 DNS 记录本身，不要第一反应换发信服务。一个人做 SaaS 时，最容易在发布前夜卡在这里：欢迎邮件已经接入，from 地址也写好了，Resend Dashboard 却一直显示 pending、partially_failed 或 failed。这类问题多数不是代码错，而是 DKIM、SPF、MX 或 DMARC 在 DNS 托管商那里填法不对，或者记录还没完全传播。
Resend 的域名文档列出了域名状态：pending 表示 Resend 仍在检查记录，verified 表示可用于发信，partially_failed 表示某个能力没有通过，failed 表示 72 小时内没有检测到需要的 DNS 记录。这个 72 小时很关键：24-48 小时内可以修明显错误，但不要每隔十分钟改一次记录。
Resend 为什么一直显示 pending 或 failed？
pending 不等于失败，它只说明 Resend 的检查器还没有确认所有记录。刚在 Cloudflare、Namecheap、GoDaddy 或 Route 53 里保存 DNS 后，很多人会立刻点 Verify DNS Records，然后看到 pending 就开始删记录、换 Host、重加域名。这样做会把问题变复杂。
更稳的判断顺序是：
- 打开 Resend Dashboard -> Domains -> 目标域名。
- 把页面上每条记录的
Type、Name/Host、Value、Priority逐条抄到同一张表。 - 到 DNS 托管商后台看实际发布的记录，不看本地截图。
- 用
dig或在线 DNS 查询工具查公网结果。 - 记录已经一致时，等待传播；记录不一致时，只修不一致的那一条。
这里的现场信号是 Resend 的状态名，而不是你的 Next.js、Supabase、Stripe webhook 或队列代码。只要邮件还没发出，先别去改业务层。
DNS 记录表该怎么填？
下面这张表不是让你照抄固定值。Resend 会给每个域名生成自己的记录值，你应该以 Dashboard 显示为准。表格的作用是防止把 Type、Host、Value 三列混在一起。
| 记录用途 | 常见 Type | Host/Name 怎么看 | Value 怎么看 | 常见误填 |
|---|---|---|---|---|
| DKIM 签名 | CNAME 或 Resend 页面指定类型 | 通常是带 selector 的子域名，例如 resend._domainkey 这类格式 | 指向 Resend 提供的目标值 | 把 CNAME 当 TXT；Host 里重复写根域名；手动改短 selector |
| SPF 授权 | TXT | 以 Resend Dashboard 为准，常见是 send 子域 | 以 v=spf1 开头，Resend 当前常见值会包含 include:amazonses.com | 填到根域；同一 Host 新增第二条 SPF；把 Dashboard 值改成自造 include |
| MX 反馈记录 | MX | 以 Resend Dashboard 为准，常见是 send 子域 | Resend 提供的 MX 目标和 priority | 漏填 priority；把 MX 填到根域；DNS 后台代理导致公网查不到 |
| DMARC 策略 | TXT | _dmarc 或 _dmarc.example.com，取决于 DNS 托管商输入习惯 | 以 v=DMARC1 开头，常见起步是 p=none | 把它当成 Resend 验证必需项；填到根域；一开始就用强策略影响旧发信系统 |
| Return-Path | 多为 CNAME | Resend 指定的子域，例如 bounce、outbound 一类 | 指向 Resend 提供的目标值 | 自己换成更好看的名字后没有同步 Resend 设置 |
| 跟踪域名 | 多为 CNAME | Resend 指定的 tracking 子域 | 指向 Resend 跟踪服务目标 | 以为不影响验证就随手删掉，导致打开/点击追踪失效 |
SPF、DKIM、MX、DMARC 的分工不要混。SPF 是授权哪些主机可以代表域名发信；DKIM 是用签名和 DNS 公钥证明邮件没有被改过；MX 在 Resend 验证里用于退信和反馈链路；DMARC 是收件方在 SPF 或 DKIM 未通过、或域名未对齐时如何处理邮件。DMARC 更像投递信任增强项，不要把它和 Resend 必需的 DKIM、SPF、MX 记录混成一类。
24-48 小时内该等还是该改？
刚保存 DNS 后，先给自己一个 24 小时窗口。这个窗口里只修肉眼确定的错误，例如 Type 错、Host 多写一段域名、Value 少复制一段、SPF 出现两条。除此之外，不要因为 Resend 还在 pending 就连续重填。
到了 24 小时后，用公网查询确认三件事：
dig TXT send.example.com能看到 Resend Dashboard 给出的 SPF 记录；如果 Dashboard 给的是别的 Host，就查那个 Host。dig MX send.example.com能看到 Resend Dashboard 给出的 MX 目标和 priority。dig CNAME <Resend 给出的 DKIM Host>能看到 Resend 给出的目标值。dig TXT _dmarc.example.com能看到v=DMARC1。
48 小时后仍未通过，通常已经不是「等等看」就能解决的阶段。此时把 Resend Dashboard 截图、DNS 托管商截图、公网查询结果放在一起看：如果公网结果和 Resend 要求不一致，继续修 DNS；如果完全一致但 Resend 仍显示 pending，可以等到 Resend 文档提到的 72 小时检查点，再联系支持。
DKIM、SPF、DMARC 分别怎么排错？
DKIM 失败，先看 selector。很多 DNS 后台会自动补根域名，例如你填 resend._domainkey.example.com，它实际发布成 resend._domainkey.example.com.example.com。如果你看到 Host 里域名重复，删掉后半段，只保留后台要求的相对 Host。
SPF 失败，先看 Host。Resend 给 send 子域时，就在 send 这个 Host 放 Resend 给出的 SPF，不要合并到根域的 Google Workspace、Postmark 或 Mailgun SPF。只有同一个 Host 已经存在 v=spf1 时，才考虑合并；同一 Host 不能有两条 SPF TXT。Resend 当前 Dashboard 常见形态类似：
send TXT v=spf1 include:amazonses.com ~all上面只是示意，不代表 Resend 当前给你的真实值。真正上线时用 Dashboard 的 Host 和 Value，不要自己发明 include:resend.example 这类不存在的片段。
DMARC 失败，先看 Host 是否在 _dmarc。如果你把 DMARC TXT 填到了根域，Resend 或收件方都不会按 DMARC 策略读取。新接 Resend 的域名，不建议第一天就把 p=reject 写死；如果老系统还在用同一个 From 域发票据、登录验证码或账单提醒，强策略可能先伤到你自己的邮件。
什么时候该找 Resend 支持？
不要在记录刚保存 20 分钟时开工单。支持能帮你看 Resend 侧的检查结果，但不能让全球 DNS 立刻同步。
可以开工单的情况是：
- 已经超过 72 小时，Resend 仍显示
failed。 - 公网 DNS 查询结果和 Resend Dashboard 要求逐字一致。
- 你确认 DNS 托管商没有代理、转发或隐藏记录。
- 同一个域名之前 verified，后来变成
temporary_failure，且你近期没有主动改 DNS。 - Dashboard 显示
partially_failed，但失败项和页面记录不一致。
工单里不要只写「验证失败」。把域名、Resend 状态、失败记录类型、DNS 托管商、公网查询结果和大致修改时间写清楚，支持才能判断是记录读取延迟、验证器缓存，还是域名配置异常。
这篇不处理哪些情况？
这篇只处理 Resend 域名的 DKIM、SPF、MX、DMARC、Return-Path 和跟踪相关 DNS 验证，不处理收件箱投递率调优，也不承诺 Gmail、Outlook、Yahoo 会把邮件放进主收件箱。域名通过验证，只代表身份认证记录可被检测到，不等于所有营销邮件都会被收件方接受。
这里也不覆盖多租户发信系统的完整架构。如果你的 SaaS 要让客户绑定自己的发信域名，需要额外处理每个租户的 DNS 指引、状态轮询、错误提示、退订页和滥用风控。Resend API 可以创建域名，但产品侧还要设计租户可读的引导流程。