范围和准备
此过程适用于外发 Technolutions Slate 邮件。获取 Slate 管理员和机构的DNS所有者。记录每个预期的发件人域，包括可能使用不同域的招生和校友流。在更改已建立的路由之前保留当前的DNS和旧配置。本指南未执行租户访问或实际消息测试。
生成并验证域配置
打开数据库> DKIM 配置，查找电子邮件域并创建其配置。仅在未使用时才使用建议的 slate-mx 子域。保存，然后将每个生成的DNS行传递给 IT，包括任何 DMARC 行以根据现有政策进行审查。发布后返回验证配置。提供者使用黑色条目表示有效记录，使用红色条目表示未解决的记录。允许范围之外的其他域需要配置密钥下的允许服务域列表；验证错误可能需要支持。请遵循下面当前的 Slate 配置源。
以正确的身份保留SPF更改
Technolutions 表示配置的子域提供 信封发件人 并拥有提供商管理的 SPF。如果没有DKIM设置，信封将使用mx.technolutions.net 。其出站服务器文章称，该路由不需要添加父域SPF 。不要仅仅因为列出的服务器 IP 地址出现在源中而将它们硬编码到机构的SPF中：提供商表示该列表可以更改。
原创机构测试设计
为招生和校友信息创建单独的工作表行。对于每个，记录请求的发件人、实际发件人、信封、 DKIM签名域、 选择器 和可信接收器结果。仅验证屏幕截图并不能说明消息使用的域。这些是测试指令，不是捕获的 Slate 输出。
一种有用的负面情况是应用程序中尚未可用的允许域配置。在提供商记录的传播间隔后重试查找，但区分应用程序可用性和DNS缓存过期。不要仅仅为了更改状态而删除工作设置。让 IT 首先识别冲突并保留回滚路线。
在接收方证明身份
使用受控的外部邮箱并通过生产工作流程发送，内容无害且无客户数据。保存原始消息、时间戳和接收系统的 Authentication-Results。忽略由不受信任的发件人插入的身份验证断言。记录可见的From域， Return-Path 或经过身份验证的信封身份，以及每个DKIM d= 和 s= 对。显示名称或回复地址不是DMARC身份。
SPF pass 授权连接服务器使用评估后的信封身份。 DKIM通行证验证其签名域的签名。 DMARC需要一个传递方法，其域与可见的 From: strict 一致 结盟 需要相同的域；宽松的对齐允许适用的组织域关系。提供商拥有的签名可以通过，无需验证您的可见发件人。一传对齐 DKIM签名 即使另一个签名失败也能满足DMARC 。这些协议规则来自RFC 7208 、 RFC 6376和 RFC 9989，如下所列。
在诊断缓存之前检查权威DNS 。向权威服务器询问确切的名称和类型，然后在其缓存生命周期后比较递归解析器。对于DKIM ，请遵循任何 CNAME 其公钥TXT响应。切勿发布私钥。对每个评估的名称保留一项SPF策略，并检查嵌套包含中的十个 DNS 查找导致术语限制。不要用提供商示例替换共享SPF策略。
恢复与验收
如果测试显示新的回归，请暂停受影响的工作流程。将更改的记录与保存的版本进行比较，并在检查其他发件人后仅撤消该更改。重新检查DNS并恢复后重新发送；恢复值不会立即刷新每个解析器。保持旧的DKIM验证记录可用，同时先前签名的邮件可能仍在传输中，除非安全事件需要撤销。
仅当DNS 、应用程序状态和实际收到的消息一致时才接受更改。记录流程所有者、证据时间戳和下一次审核触发器。收件箱放置本身并不能证明身份验证，并且成功的身份验证并不能保证收件箱放置。不要根据一个提供商的测试来收紧共享域的DMARC策略。首先盘点其他合法来源。
遵循附加域状态分类账
书面案例 SL-01 假设该机构需要alumni@example.org ，但该域超出了其实例的允许范围。管理员已将example.org保存在允许的服务域列表中；说明性的经过时间为五分钟，配置可用性仍然未知，并且尚未为其生成DKIM记录。记录的 15-20 分钟应用程序传播窗口与DNS缓存不同。 Slate 所有者应等待该时间间隔，重试查找并遵循生成的域验证工作流程，然后再测试校友邮件。来自、信封和所有接收器结果仍然未知。不要删除不相关的工作准入配置。未访问任何机构数据、配置密钥或消息。
保留执行边界
RFC 9989第 7.4 节要求有效的DKIM ，而不仅仅是SPF来进行域发布 p=reject，并对间接邮件和邮件列表互操作性发出警告。一次成功的直接消息测试并不能证明每条合法路线都已准备好采取更强有力的政策。保留现有批准的保护，同时诊断实际差距；任何政策变化都需要自己的决定。