编辑DNS之前选择产品
TinkMail 的个人域文档将自定义域描述为 Pro 功能。其业务指南使用帐户提供的值和占位符。不要假设将个人发送池应用于业务工作区。确认产品、预期发件人域、 DNS所有者以及移动入站邮件是否属于授权项目的一部分。本指南尚未测试 TinkMail 帐户。
个人自定义域程序
在“设置”>“域”中添加域并使用生成的DNS表。个人指南指定promx1.tinkmail.me和promx2.tinkmail.me的优先级为10和20； SPF 包括 prospf.tinkmail.me 并需要~all 。复制域生成的 DKIM 主机和公钥，然后运行 Check DNS 。激活取决于MX 、 SPF 、 DKIM和 DMARC 匹配。已发布的DMARC示例使用严格的 结盟 和 p=none。使这些要求与现有政策保持一致，而不是添加重复的记录。确切的个人域来源如下。
业务领域流程
业务页面的SPF包含和DKIM密钥是占位符，而不是生产值。获取真实的包含， 选择器 和来自客户经理的公钥，并获得合并现有SPF帮助。将丢失的帐户数据视为设置拦截器。不要替换猜测的主机名、个人池或伪造的密钥。
原创迁移验收设计
在更改票证中将入站切换与出站身份验证分开。包含MX个人域激活清单可能会影响新邮件的投递位置。在更改MX之前，清点现有邮箱、别名和恢复访问权限；保留之前的目的地。获取特定的入站迁移决策，而不是将MX视为无害的身份验证记录。
验收设计有两个产品分支，没有观测数据。在个人分支中，收集仪表板的预期值和实时值以及新发送的自定义域消息。在业务分支中，首先记录客户经理的实际值和产品范围，然后执行相同的接收者检查。使用包含无害内容的测试别名。通过严格对齐，父域及其子域不会被视为相同。确认签名的 d= 值和信封域，而不是仅仅为了使状态指示器变为绿色而削弱策略。
在接收方证明身份
使用受控的外部邮箱并通过生产工作流程发送，内容无害且无客户数据。保存原始消息、时间戳和接收系统的 Authentication-Results。忽略由不受信任的发件人插入的身份验证断言。记录可见的From域， Return-Path 或经过身份验证的信封身份，以及每个DKIM d= 和 s= 对。显示名称或回复地址不是DMARC身份。
SPF pass 授权连接服务器使用评估后的信封身份。 DKIM通行证验证其签名域的签名。 DMARC需要一个其域与可见From对齐的传递方法：严格对齐需要相同的域；宽松的对齐允许适用的组织域关系。提供商拥有的签名可以通过，无需验证您的可见发件人。一传对齐 DKIM签名 即使另一个签名失败也能满足DMARC 。这些协议规则来自RFC 7208 、 RFC 6376和 RFC 9989，如下所列。
在诊断缓存之前检查权威DNS 。向权威服务器询问确切的名称和类型，然后在其缓存生命周期后比较递归解析器。对于DKIM ，请遵循任何 CNAME 其公钥TXT响应。切勿发布私钥。对每个评估的名称保留一项SPF策略，并检查嵌套包含中的十个 DNS 查找导致术语限制。不要用提供商示例替换共享SPF策略。
恢复与验收
如果测试显示新的回归，请暂停受影响的工作流程。将更改的记录与保存的版本进行比较，并在检查其他发件人后仅撤消该更改。重新检查DNS并恢复后重新发送；恢复值不会立即刷新每个解析器。保持旧的DKIM验证记录可用，同时先前签名的邮件可能仍在传输中，除非安全事件需要撤销。
仅当DNS 、应用程序状态和实际收到的消息一致时才接受更改。记录流程所有者、证据时间戳和下一次审核触发器。收件箱放置本身并不能证明身份验证，并且成功的身份验证并不能保证收件箱放置。不要根据一个提供商的测试来收紧共享域的DMARC策略。首先盘点其他合法来源。
停止因缺少账户值而进行业务部署
书面案例 TM-01 假设业务工作区旨在support@example.org 。唯一可用的引用包含 YOUR_PROVIDED_KEY 和_spf.example.com占位符；当前的邮箱提供商仍会接收入站邮件。尚未提供实际的业务选择器、包含或迁移批准。工作区所有者必须获取其发布的记录，邮箱所有者必须单独决定任何入站迁移。请勿替换个人 prospf/promx 池、发布占位符或降级现有DMARC策略。所有DNS和接收器结果仍然未知。没有发生帐户、邮箱或DNS操作。
保留执行边界
RFC 9989第 7.4 节要求有效的DKIM ，而不仅仅是SPF来进行域发布 p=reject，并对间接邮件和邮件列表互操作性发出警告。一次成功的直接消息测试并不能证明每条合法路线都已准备好采取更强有力的政策。保留现有批准的保护，同时诊断实际差距；任何政策变化都需要自己的决定。