用 Muse 整理 Resend 发信子域名 DNS，先核对再改

01｜先把发信域名和现有邮件分开

先决定在 Resend 里添加哪个域名。若添加 example.com，默认 return path 是 send.example.com；若把专用发信子域名 mail.example.com 添加进去，默认 return path 会是 send.mail.example.com。两者只是示意写法。Resend 允许改 return path 的名称，保存前要查该位置有没有被别的服务使用。这样能把应用发信和已有邮件用途分开，也不会误以为 return path 就是你添加的那个域名。

Resend 生成的记录会按域名配置和启用能力变化。它可能列出 SPF、DKIM、MX 或其他记录。不要从教程、搜索结果或别人的截图复制值。你要用的是自己 Resend 域名页面当前显示的每一行。

02｜先确认谁在管理权威 DNS

域名在哪家注册和 DNS 由谁回答是两回事。先确认域名当前的 nameserver 委派到了 Cloudflare，还是别的 DNS 服务商。只有权威记录确实由 Cloudflare 管理时，才在 Cloudflare 改这批记录；如果区域被委派到别处，就回到那个服务商的控制台。不要为发信验证去改 nameserver。

改动前导出 DNS 区域或逐行保存现有记录，至少包括类型、名称、目标或内容、TTL、MX 优先级和代理状态。圈出网站 A、AAAA、CNAME，现有 MX、根域 SPF、DKIM 和 Cloudflare Email Routing 相关记录。这个快照用来比较和回退，不要把整个区域文件贴进聊天。

03｜让 Muse 先做记录清单，不提交变更

Meta 对 Muse 的说明是，它可以浏览网页、跨步骤行动，并让用户设置权限、查看过程和批准操作。公开帖子里也有人描述用 Muse 帮忙连接域名和 Resend，不过那只是个人使用经历，不能证明你的账户权限、界面或执行结果相同。这里把 Muse 用在整理和对照上，不把它当成 DNS 管理员。

先从 Resend 页面复制当前待添加记录，再给 Muse 一份删去账户信息的旧记录快照。可以这样写。请只比较我贴出的 Resend DNS 要求和当前区域记录，输出一张待审清单，字段包括记录类型、完整名称、目标或内容、TTL、MX 优先级、当前是否已有同名同类型记录、可能冲突和依据。不要登录其他账户，不要创建、修改或删除记录，不要点验证。任何字段对不上都标为待确认。

如果 Muse 没有安全的浏览器访问方式，或你看不到要批准的具体操作，就手动打开 DNS 控制台逐行填写。不要把 Resend API key、Cloudflare API token、登录验证码或密码写进普通提示词。

04｜把 TXT、MX 和 CNAME 分清再填写

TXT 是文本内容，常用来发布 SPF、DKIM 或域名验证信息。MX 指向接收邮件的服务器，并带有优先级。CNAME 是一个名称指向另一个名称。Resend 当前页面可能为不同用途列出不同类型，不能把一条 MX 当成 CNAME，也不能把 DKIM 名称和 SPF 内容互换。

DNS 面板的 Name 或 Host 字段有时只收子域标签，有时允许完整域名。按照面板说明输入，并检查保存后的完整名称有没有被重复拼上区域后缀。MX 的优先级只填写在 MX 行。TXT 内容按 Resend 给出的原样放入，别自行加引号、换行或改大小写。

Cloudflare 的 MX 和 TXT 记录不能开启代理。用于邮件认证或第三方验证的 CNAME 也应按服务商要求设为 DNS only。不要把网页服务器的橙云代理规则套到邮件记录上。

05｜SPF 冲突先停下来核对

SPF 是以 TXT 发布的一项策略。RFC 7208 规定同一个完整名称下不能放多条 SPF 策略，接收方遇到重复策略可能返回 permerror。根域和发信子域名是不同的 DNS 名称，各自的 SPF 要看对应位置。根域已有的 SPF 通常服务于现有邮件来源，不能为了 Resend 直接覆盖，也不要在同一名称下并排加一条 v=spf1。

Resend 的 return path 默认使用 send，也支持自定义 return path；官方说明该位置会用到 SPF 和 MX，且 send 这个名称可能已经被其他服务占用。先检查实际记录冲突。如果 Resend 要求修改根域 SPF，或你不确定哪些服务正在使用它，停在草稿阶段，让邮件管理员决定是否合并策略或改用受支持的专用 return path。

06｜逐行人工检查后再保存

保存前把待改行和旧快照并排看一遍。每行都核对类型、完整主机名、目标值、TTL、MX 优先级和 Cloudflare 代理状态。确认这次操作没有碰到根域 MX、现有 SPF、网站记录或不相关的邮件转发。多出一条未说明记录、同名不同类型冲突或 Resend 与清单不一致，就先取消并回头检查。

每个字段都能对应到 Resend 当前记录后，再由有权限的人在 DNS 控制台提交清单里的具体变更。保存后把实际记录和审核清单对一遍，再回 Resend 检查对应状态。测试邮件另外安排，先确定收件箱和内容，不把域名验证直接当成发信授权。

07｜回 Resend 看每条记录的状态

变更后回到 Resend 域名详情，看当前状态具体指出哪一条 DKIM、SPF 或 MX 记录仍缺失或格式不符。Resend 在 2026 年更新了逐步验证状态和具体错误提示，也支持只完成发信或收信其中一项的部分验证。只开通发信时，页面不一定会列出收信所需的全部记录。下图是 Resend 发布的部分验证示例，里面的域名和记录只用于展示状态，不要照抄；它展示的是 Resend 页面，不是 Muse 实测。

DNS 缓存和不同服务商的传播时间会有差异。Cloudflare 的 TTL 只是递归 DNS 缓存的一个因素，五分钟不代表各处都已同步，也不代表 Resend 会在五分钟内完成验证。先等一段时间，再按错误信息复查对应记录；不要因为状态还在 pending 就连续创建重复记录。Resend 自己的 DNS 检查针对其所需记录，比随便查一个公共 DNS 结果更贴近验证目标。

08｜留好回退记录，验证和发信分开

记下这次实际新增或调整的行、操作者、时间、Resend 状态和仍待处理的项目。若要回退，只移除经确认属于本次新增的记录；恢复被改动的值时，对照事前快照并由域名管理员复核。不要删除看起来陌生但无法确认用途的旧 MX、SPF、DKIM 或邮件转发记录。

DNS 验证通过也只说明 Resend 识别到了相关配置，不代表邮件内容、收件人名单、退信处理或发件人身份都已准备妥当。要开始发信，还得确认产品授权、测试收件箱和邮件内容，再由负责人决定是否发送。实际准备发信时，可以接着看 Muse 发信审批教程。