从自动任务域状态开始，而不是通用DNS配方
Autotask 的域设置文档显示版本 2026.6，将使用发送域的权限与可选域分开 DKIM 验证。该页面表示，从版本 2023.3 开始，发送地址必须使用经过验证的域。该产品要求与一般电子邮件协议不同。看起来有效的地址不一定是应用程序允许的地址，并且允许的地址本身并不是收件人一致身份验证的证明。 自动任务域设置
支持的范围包括记录的自动任务外发电子邮件域工作流程。它并不能确定不相关的邮件服务、单独配置的应用程序或客户租户中的每个通知路径都已准备就绪。在进行任何更改之前，请确定实际环境、受影响的发件人地址和负责的管理员。此草案未执行任何帐户访问、 DNS更改或消息测试。
盘点受验证影响的地址
提供商识别支持地址、用作从资源电子邮件发送的主要用户地址、备用发送地址以及模板、工作流规则、调查、发票电子邮件和联系人组中手动输入的地址。查看这些类别，而不是将单个测试通知视为所有业务邮件的代表。目录中的接收消息证据要求仍然适用于最终批准的确切路线。 自动任务域设置
每个实际域和发送用途创建一个清单行。记录应用程序是自动发现域还是管理员建议添加域。指定一个可以解释为什么该域应该保持可用的所有者。否则，过时的备用地址可能会产生误导性要求，要求在业务流程转移到其他地方后保留域。
提供商区分“活动”、“域已验证”和DKIM已验证”状态。其系统域autotask.com和datto.com由 Kaseya 配置，无法通过此工作流程进行编辑或停用。客户域决策不应基于这些系统域的状态。记录的客户DKIM限额是五个附加域；该限制与其他地址类别的存在是分开的。 自动任务域设置
获取值前确认管理权限
记录的权限是能够配置电子邮件通知和调查的管理安全级别以及编辑公司DNS条目的权限。导航是“管理”、“管理类别”、“自动化”、“电子邮件通知和调查”，然后是“域设置”。添加唯一域使用“新建”，然后使用“添加域”，这会打开身份验证对话框。这些说明描述了建议的授权工作流程，而不是授予访问权限或声明已添加域。 自动任务域设置
当应用程序管理员与DNS更改审批者的职责属于不同的团队时，将这些职责分开。保留每个提供的记录的域上下文。显示没有选定域的值的屏幕截图是薄弱的更改证据。操作员应该能够将建议的所有者名称、记录类型和内容与预期的应用程序域相匹配，而无需猜测。
将两个验证记录视为不同的控件
自动任务的强制验证使用 SPF TXT策略和域验证 TXT记录。后者在 ._autotask 之前有一个帐户提供的域代码。该文档列出了该验证记录的依赖于提供者的内容选择：空格、句点或所需的单词名称。不要发明域代码，假设该值可以独立证明任何事情，或者将此所有者名称与域的SPF所有者混淆。在发布之前解决实际的对话框和 DNS 编辑器要求。 自动任务域设置
SPF示例包括include:autotask.net.提供商表示要保留现有内容，将其放在冗长策略的前三个条目中，并注明对~all的验证偏好，同时承认-all可以工作。这些是产品特定的说明和兼容性问题，而不是新的SPF协议规则。不要为了满足检查人员的要求而默默地削弱现有的失败策略。将任何冲突上报给负责的策略所有者，并在批准之前建立受支持的配置。 自动任务域设置
将一项适用的SPF策略保留在其所有者名下。保留仍然授权的发件人并审查整个评估路径。 SPF对 DNS 查询项的限制并不是建议将每个提供商放在第一位，也不是对网络数据包进行简单的计数。重新排序机制可以改变行为，并且必须使用完整的策略进行评估，而不是作为装饰性编辑。 RFC 7208 ，多记录和DNS查找限制
不要将可选的DKIM与已完成的签名混淆
提供商将此应用程序工作流程中的DKIM身份验证称为可选。这并不意味着它与组织的身份验证目标无关。 SPF身份与其可见发件人域不一致的路由可能需要合格的对齐DKIM结果 DMARC 通过。审核者必须建立实际的标识符，而不是从绿色验证图标推断它们。 RFC 9989 ，标识符对齐
保留的当前页面描述了DKIM状态、域限制和身份验证操作，但未公开完整的信息 选择器 将食谱记录在其可读的说明中。在提出建议之前获取受支持的帐户特定的DKIM详细信息 一个记录。不要复制较旧的第三方 CNAME 将配方纳入此工作流程并将其标记为当前提供者证据。实际消息中的选择器和签名域决定密钥查找；公共DNS值必须与该签名配置相对应。 RFC 6376 、 DKIM-Signature和密钥存储
用正确的证据验证每一层
通过批准的流程发布预期记录后，提供商指示操作员重新打开对话框并选择“验证域”。其文档描述了可能的 5 分钟到 48 小时间隔，并将验证错误与DKIM错误区分开来。将这些计时语句视为故障排除指南，而不是保证单独等待即可修复不正确的记录或超出的域限额。 自动任务域设置
与应用程序状态分开记录公共DNS观察结果。然后获取每个相关路由的授权接收消息证据，包括可见作者、信封身份、签名域、选择器和接收者身份验证结果。应用程序验证结果不能替代该消息级表。身份验证也不能保证收件箱的放置或证明消息的业务请求是安全的。 RFC 9989 ，范围和接收器操作
虚构诊断：验证成功，接受不成功
虚构的服务公司 Fernbridge Support 准备来自两个域的发票和票证通知。其管理员会看到第一个域的“域已验证”，并报告两条路由均经过完全身份验证。审阅者注意到第二个域的状态从未被记录，并且没有收集收到的消息身份。这是一个虚构的审查场景，而不是观察到的客户事件。
审核者将域验证、 DKIM状态和路由证据分成不同的行。第一个域的验证被保留为一个狭窄的事实，而不是被丢弃或夸大。第二个域仍然悬而未决。两条路线在发布前仍需要经过授权的消息评估。更正是证据边界修复：一种状态无法为另一个域或不同的身份验证层建立结果。
空白验收工作表
- 产品版本和租户适用性确认：______
- 发送域和受影响的地址类别：______
- 应用程序管理员和DNS审批者：______
- 带有时间戳的活动状态和域验证状态：______
- 帐户生成的验证所有者和确切内容：______
- 现有SPF政策和已审查的拟议变更：______
- 产品验证约束与组织政策决策：______
- DKIM津贴、生成的详细信息和当前状态：______
- 公共DNS证据和权威来源：______
- 每个路由的接收消息身份表：______
- 回滚、主题审查和发布决定：______
剩余释放条件
工作表未填写，虚构的诊断不是可操作的证据。帐户适用性、原始实施证据、人工主题审查、生产路线、视觉可访问性和所有者发布仍然开放。域语法的源描述和改进的交付不被采用作为通用互联网规则或保证。最终接受决定必须使用当前支持的租户工作流程和来自预期路线的实际证据。