委派子域可以使发送服务更易于操作，但它也可以分散对组织身份的控制。一个有用的 DKIM 设计将DNS所有者、私钥保管人和企业所有者分开命名。它还准确说明了授权的内容以及授权将如何结束。
不要从发布限制性记录或假设子域仅发送邮件开始。建立其当前和预期目的，包括接收、应用程序使用和继承的依赖关系。 DKIM配置本身并不能决定命名空间是否应该接受消息、为网站提供服务或保持休眠状态。
定义授权边界
区分选择器级别 CNAME 使用 NS 记录委托整个DNS区域。一个 选择器 CNAME指向以下提供商管理的验证数据的特定查找 RFC 1034 §3.6.2。区域代表团为该区域内的名称分配权威责任，但须进一步削减区域，根据 RFC 1034 §4.2;范围可以包括与DKIM无关的记录。在将这两种机制视为可互换之前，请先审查更广泛的权威。
记录完整的选择器查找名称、目标或权威区域、预期域名和提供商帐户。 RFC 6376 §3.1 描述选择器用例和 RFC 6376 §3.6.2.1 定义键查找。它没有规定特定提供商控制面板中的权限。获取提供商的最新说明以及这些权限的负责所有者。
分配三种所有权
企业主知道哪些消息必须继续有效。 DNS所有者可以发布或删除查找或委派。密钥保管人控制私有签名密钥，无论是内部系统还是托管提供商。一个团队可以担任多个角色，但每个职责都应该明确。
询问谁可以轮换密钥、更改签名域、导出证据并禁用发送帐户。公共验证数据不是私人签名密钥。切勿仅仅为了证明这一点而索取提供商的私钥 一个记录 是正确的；使用记录的控制和收到的消息验证来代替。
通过一个范围示例进行工作
说明性设计： receipts.mail.example被分配给计费服务，并使用d=receipts.mail.example和选择器 bill1 支持签名。该组织保留其父DNS ，而提供商控制bill1._domainkey.receipts.mail.example到达的验证材料。根据该确切名称记录账单所有者、 DNS更改所有者和提供商密钥保管人。
如果可见的发件人域是receipts.mail.example ，则身份完全匹配。如果 From 使用mail.example ，则评估配置的 结盟 模式下 RFC 9989 §3.2.10 和组织域发现 RFC 9989 §4.10.2;不要假设严格对齐。传递签名证明了其d域的密码关系，而不是父级下的每个地址都具有相同的业务授权。这是一个设计固定装置，而不是实际租户的结果。
更改前检查隐藏的依赖项
使用子域搜索配置清单以查找计划作业、收购时代的应用程序和旧的活动系统。单独审查接收要求。 DNS委派更改可能影响的不仅仅是DKIM ，而删除选择器可能会影响已使用该选择器签名的延迟消息。
为每个已知的发送路由准备代表性测试。捕获来自、d、s、受信任的接收器结果和对齐，以及DNS答案和时间戳。验证正常路径以及恢复路径。标记为已验证的仪表板是有用的配置证据，但不能替代收到的消息示例。
使离板成为初始设计的一部分
记录如何停止新签名、在计划的过渡期间保留必要的验证以及在依赖关系结束后删除未使用的委派。分别协调帐户访问和 API 凭证；删除一条DNS记录并不能完全关闭提供商。如果怀疑密钥被泄露，安全遏制可以优先于普通重叠。
最终寄存器应显示名称空间用途、授予的权限、所有者、测试和退出条件。该记录可以让下一个管理员区分必要的依赖关系和废弃的指针，而无需根据DNS中的提供者名称进行猜测。
记录下一个决定
在批准之前，将所请求的确切名称和记录类型与预期的权限进行比较。不应将整个区域的一个选择器CNAME默默地替换为 NS 委派。如果提供者需要更广泛的范围，请列出受影响的名称和依赖项并获得负责的所有者的决定。该示例未授予实际的DNS权限。