确认Dynadot具有权威性
在 Dynadot 注册的域名可以使用其他公司的DNS 。首先检查委托 名称服务器 并识别控制权威区域的账户。如果域使用外部名称服务器，请在那里发布。仅仅为了使用 Dynadot 编辑器而更改注册商名称服务器是DNS迁移，而不是普通的身份验证记录编辑。
收集发送平台的确切记录类型、完整所有者名称和值以及现有区域设置。本指南解释了发布，而不是应授权哪个发件人。邮件管理员必须提供并批准 SPF 政策， DKIM 记录或 DMARC DNS运营商保存策略之前。
将所有者翻译为编辑的字段
Dynadot 记录了我的域名 > 管理域名、域名选择、操作 > DNS设置以及 Dynadot DNS选项。对于 apex TXT数据，将域记录与TXT一起使用并将值放入 IP 地址/目标中。它指示用户省略周围的引号。 TXT说明
它的所有者名称规则很重要：@指令表示域记录部分，而不是文字@标签。非顶点所有者属于子域记录，并且提供的完全限定名称必须在输入前缀之前删除区域后缀。例如， example.com区域中的说明性所有者_dmarc.example.com变为_dmarc 。 DKIM所有者（例如selector1._domainkey.example.com ）将成为选择器1。 _domainkey 。这些是语法示例，而不是真实的帐户值。
使用保存设置保存，然后检查完整的发布所有者。不要假设成功提交表单就意味着DNS名称是正确的。输入仅需要前缀的整个域可能会产生重复的后缀并使所需的所有者留空。
保留所需的根配置
Dynadot 的TXT指南称其DNS配置还需要根 A、AAAA、 CNAME 或转发条目。这是提供商编辑器的约束，而不是一般的DNS规则。保留域的真实的、经批准的根配置。不要仅仅为了满足形式而发明占位符地址或更改网站。如果仅邮件设计没有适当的根条目，请在保存之前向 Dynadot 询问支持的配置。
对于DKIM CNAME ，请使用子域记录区域以及提供的 选择器 标签、 CNAME类型和目的地。丹纳多特 CNAME演练 使用网站示例；替换实际的邮件选择器，而不是复制 www 或示例转发目的地。避免在已提供其他活动服务的所有者处使用CNAME 。
验证接收方将查询的记录
独创验证方式：保留每个确切所有者和类型的前后权威答案。对于SPF ，检查适用的信封域并确保仅存在一个候选SPF策略。对于DKIM ，查询发送平台提供的选择器并遵循其CNAME如果存在）。对于DMARC ，查询预期的_dmarc所有者并将策略与批准的更改进行比较。
接下来使用发送平台的验证控制，然后通过预期的路由发送无害的消息。记录接收者的身份验证结果，并将传递的SPF或DKIM域与可见的 From 域进行比较。 DNS发布、提供商验证和消息 结盟 是不同的观察结果；保留所有三个指标，而不是将任何单个绿色指标视为结论性指标。
恢复准确记录
示例性失败： _dmarc.example.com被输入到仅包含前缀的字段中，从而创建了重复的后缀。检查实际发布的内容后纠正所有者；作为解决方法，不要在目标所有者处创建多个DMARC策略。保留不相关的 TXT记录 例如服务验证令牌。
如果发生任何故障，请将受影响的记录恢复到其批准的先前状态并允许缓存。名称服务器迁移或记录清理后重新检查。文档于 2026 年 11 月 8 日审核。此处未测试 Dynadot 帐户、实时DNS更改或传递的消息。
准备业主姓名翻译卡
对于每条记录，保留发送服务指令、完整的预期DNS所有者、区域后缀、编辑器字段、输入的标签、记录类型和权威结果。例如，区域example.com中的_dmarc.example.com映射到_dmarc子域标签；顶点映射到域记录。保存前比较重建的完整所有者。如果当前接口与记录的模型不同，请停止并确认字段语义而不是猜测。