打开编辑器前确认DNS权限
GoDaddy可以是注册商、 DNS主机、邮件提供商或同时担任其中多个提供商。本指南涉及使用GoDaddy进行域名的DNS发布 名称服务器。如果活动权威名称服务器属于另一个提供商，请改为编辑该提供商的区域。不要仅仅为了使用熟悉的DNS编辑器而移动名称服务器。
从发送服务获取实际所需的身份验证值。一个 SPF 包括， DKIM选择器 或自定义弹跳域目标取决于该服务和路由。 GoDaddy的DNS主机角色并不意味着通用邮件授权值。在更改任何内容之前，记录可见的发件人域、已知的预期信封域、选择器和当前域策略。
识别建议所有者名称处的所有现有记录并保存更改前的记录。域可能有不相关的验证 TXT记录，一个现有的SPF策略，几个 DKIM 选择器和一个 DMARC 政策。目标是对相关记录进行精确更改，而不是清理所有看起来不熟悉的内容。
将预期所有者转换为GoDaddy字段
记录的路由是域组合，选择域、 DNS ，然后添加新记录。对于TXT ，Name 字段是不带域的主机名或前缀； @代表根。在值中输入提供的文本并选择 TTL。帮助页面指定最多 1,024 个字符的 ASCII TXT值。如果提供的密钥超出支持的字段或显示被截断，请在保存之前解决限制。
对于合成example.com区域， _dmarc.example.com的DMARC所有者映射到名称_dmarc 。 selector7._domainkey.example.com的DKIM所有者映射到 Selector7。 _domainkey ，假设选择器7是实际提供者提供的标签。 apex SPF策略映射到 @。这些是名称翻译示例，而不是真实账户的密钥或策略。
在变更请求中写下完整的预期所有者和编辑者标签。完整名称是您要查询以进行验证的名称。避免将完整主机名复制到再次附加域的字段中。当编辑者的记录规则禁止时，请勿在相对名称字段中添加最后一个句点。
根据发件人选择TXT或CNAME
SPF和DMARC策略是TXT记录。 DKIM可以使用TXT公钥或提供商要求的 CNAME 别名。遵循发送服务的确切记录类型。粘贴到CNAME目标中的公钥不是DNS别名，并且粘贴为任意TXT提供商主机名不是等效委托。
GoDaddy的CNAME工作流程在名称中使用前缀，不接受 @，并且需要其他记录尚未使用的名称。发布提供商的目标域名，而不是 https 地址或其网站路径。如果选择器名称被占用，请识别相关服务并请求支持的替代服务。不要仅仅为了保存表单而删除其他发件人的选择器。
请求的跳出域 MX记录 与用于普通入站邮件的根域MX是分开的。除非批准的邮件服务设置明确要求进行更改，否则请勿更改现有的入站路由。在身份验证登录期间保留不相关的邮件和网站依赖性。
保留政策边界
添加另一合法发件人时，请更新相关所有者处的一个有效SPF策略，而不是创建第二个候选策略。检查 DNS 查找依赖性并保留其他批准的发件人。普通的不相关的TXT记录可能会共存；该错误是多个选定的SPF策略，而不是多个TXT数据的每个实例。
DMARC还需要深思熟虑的域级别决策。在添加其他策略之前，请检查适用的策略是否已存在。不要将强制执行的策略降级为 p=none 因为新提供商的样本使用了监控。新的路由在被组织的策略所依赖之前应该证明一致的身份验证。
仅使用批准的报告目标。教程的邮箱或报告端点不是复制到生产中的值。如果更改会将域报告发送到外部服务，请在批准中包含该目的地和目的。
保存、查询、检查消息
GoDaddy可能需要对受保护的域进行额外的身份验证。授权帐户所有者必须完成所有必需的安全步骤。保存后，在各个权威服务器上查询完整的所有者名称和类型。确认完整的TXT值或CNAME目标，而不仅仅是编辑者的行。保存的行证明编辑已被接受；它并没有规定活跃的代表团为其服务。
GoDaddy表示，更新通常会在一小时内生效，但在全球范围内可能需要长达 48 小时的时间。将其视为广泛的期望，而不是在检查错误名称或截断值之前等待的理由。首先比较权威答案，然后根据以前的 TTL 评估递归缓存。
接下来验证或激活发送服务并通过其实际路由发送受控消息。记录发件人、信封身份、所有DKIM签名域/选择器和可信接收者结果。 SPF对信封进行验证； DKIM验证签名的域； DMARC需要可见的发件人的对齐传递路径。
综合情况： selector7._domainkey.example.com可以正确解析，但发件人使用 selector8 进行签名。 DNS托管正在运行，但预期密钥无法验证该签名。协调邮件服务生成的选择器和发布。添加另一个根SPF策略并不是补救措施。
缩小范围恢复并记录限制
保持 一个记录 新旧值以及受影响的业务工作流程。如果更改失败，请在检查干预更改后仅恢复相关批准的记录集。重新测试预期的出站路由以及更改所涉及的任何入站依赖性。如果签名已经转移到新的选择器，请不要盲目删除它。
本指南使用第一方GoDaddy文档和综合示例。没有GoDaddy帐户、 DNS发布、权威查找或已发送的邮件被访问作为实时证据。变更负责人必须提供这些意见并单独批准生产完成。
记录下未知的事
对于书面的selector7/selector8 情况，假设来自notices@example.com和DKIM d=example.com, s=selector8. Selector7 键本身不提供有关所需的 Selector8 查找的证据。 Selector8 DNS 、签名验证、 SPF身份/结果等签名未知；不要将整个消息称为DMARC失败。在选择修复之前，请向发送所有者询问其当前生成的记录并保留实际的选择器8答案。没有执行任何真正的消息或查询。
保留执行边界
RFC 9989 第 7.4 节要求有效的DKIM ，而不仅仅是SPF来进行域发布 p=reject，并对间接邮件和邮件列表互操作性发出警告。一次成功的直接消息测试并不能证明每条合法路线都已准备好采取更强有力的政策。保留现有批准的保护，同时诊断实际差距；任何政策变化都需要自己的决定。