确认确切的GoodData产品和路线
支持本指南的第一方程序标记为 GoodData Legacy Growth、Configure DKIM 对于传出电子邮件。它涉及白标外发邮件，需要客户和 GoodData 双方共同努力。请勿自动将其应用到当前的 GoodData Cloud、其他计划或不同的通知服务。
首先与帐户所有者确认产品、白标域、预期发件人地址和实际消息工作流程。确定处理白标签配置的DNS管理员和 GoodData 支持所有者。自定义应用程序 URL 或品牌主题并不能证明外发电子邮件是使用同一域签名的。
读者的任务是建立受支持的签名安排，然后测试预期的邮件。该目录的广泛提供商标签并不能证明每个 GoodData 产品都支持相同的内容 选择器、中继或密钥管理过程。如果记录的旧范围与您的租户不匹配，请在更改DNS之前获取匹配的第一方过程。
选择支持的按键排列
Legacy Growth 文档描述了使用特定的私钥（使用 GoodData 生成的唯一密钥作为替代），或使用 GoodData 共享密钥。在共享密钥路由中，支持人员提供包含公钥的DNS记录。在特定密钥路由中，各方通过签名配置协调选择器和域。没有提供通用选择器或公钥值供客户从本指南中复制。
首选适合组织的签名密钥所有权政策并最大限度地减少不必要的暴露的安排。明确谁生成密钥、谁可以使用密钥、如何协调轮换以及服务退役时如何删除提供商的签名权限。公共DNS记录可以广泛可见；不能以同样的方式处理私钥。
提供商文档描述了使用客户提供的私钥时的加密传输。请勿将私钥粘贴到聊天、普通支持评论、公共文档或DNS 。让授权的安全所有者验证预期的接收者和安全传输过程。请求或接受提供商生成的替代方案仍然需要了解谁持有和控制私人签名材料。
仅公开公开验证材料
从支持的设置中获取准确的记录类型、完整的所有者、选择器和公共值。将它们与批准的签名域进行比较。单独记录所需的 DNS 编辑器标签，因为相对名称字段可能会自动附加区域。在进行更改之前检查现有选择器是否已属于另一个邮件服务。
A DKIM签名 d=example.com和s=analytics1在analytics1._domainkey.example.com查找其密钥。这是一个合成名称构造示例，而不是 GoodData 默认值。在不同选择器或域下正确发布的密钥将不会验证该签名。当编辑代表长篇文章时，保留完整的公共价值和记录边界 TXT记录 作为多个字符串。
发布后，查询权威DNS以确定确切的所有者。保留答案并确认活动委托正在提供您编辑的记录。然后让支持负责人完成 GoodData 端配置。无需签名激活的DNS发布只是任务的一半。
保持可选SPF与对齐方式不同
Legacy Growth 页面列出了include:relays.gooddata.com作为可选 SPF 此外还授权其邮件中继。使用前请确认这是适用的路线。不要仅因为组织中存在不相关的 GoodData 工作流而添加它，并且不要在同一所有者处创建第二个SPF策略。
从整体上审查任何必要的SPF更新：保留现有批准的发件人、检查策略的 DNS 查找依赖性并确认其终端行为。如果没有明确的维护计划，请避免将中继 IP 地址复制到静态白名单中。提供商管理的授权目标和当前答案的冻结列表具有不同的操作后果。
SPF成功本身并不能证明 DMARC 结盟。评估的身份是 信封发件人 领域。如果邮件使用提供商拥有的信封，同时在“发件人”中显示您的域，则该提供商域的SPF通行证将与您的域不一致。与可见发件人对齐的传递DKIM签名可以提供所需的路径。
测试真实的白标消息
将范围内的每个材料工作流程触发到受控的、授权的测试邮箱。保留收到的原始消息并记下工作流程、发送方配置和测试时间。记录可见的发件人、信封身份、每个DKIM签名域和选择器以及受信任的接收者身份验证结果。不要仅从白标签 URL 或签名显示推断这些值。
综合接受示例：来自reports@example.com ，消息的DKIM签名通过d=example.com进行验证，并且接收者在该对齐路径上成功评估DMARC 。即使SPF仅通过不相关的信封域，精确对齐的DKIM也可以提供DMARC路径。如果签名使用不同的不相关域，则仅DKIM通行证不足以支持此接受结论。
在密钥轮换或更改邮件传输后重复该示例。如果没有预期的签名，请在添加更多记录之前检查 GoodData 端激活和实际工作流程。如果签名存在但无效，请比较选择器、域、公钥和任何消息修改。如果身份验证通过但传送效果不佳，请分别调查其他接收者和声誉因素。
计划轮换、退休和康复
保留变更前的记录集以及签名安排各部分的记录所有者。协调提供商开始使用新选择器进行签名的时间以及公钥可用的时间。不要假设删除单个记录会撤销所有功能，或者立即删除旧密钥对于仍在传递的已发送邮件是安全的。
停用集成时，请在删除选择器或SPF权限之前验证是否没有工作流程仍然需要它。在组织的安全流程下协调私钥保留和提供商方签名访问。如果密钥可能已暴露，请使用事件和轮换流程，而不是将问题视为正常的DNS缓存延迟。
这是专门标记的遗留产品的文档指南。这些例子是综合的。未访问或测试私钥、租户配置、 DNS更改、支持交换或传递的 GoodData 消息。生产验证和任何更广泛的产品范围决策仍由帐户和安全所有者负责。
在调用路由完成之前使用激活分类帐
书面案例 GD-01 假设租户已确认 Legacy Growth，批准的发件人为reports@example.com ，商定的说明性选择器为analytics1。 DNS所有者在analytics1._domainkey.example.com上有一个规定的公钥，而提供商端签名激活仍未得到确认。仅靠DNS无法完成该任务。要求白标所有者获取支持的签名配置的确认，然后检查无害的授权通知。后来假设的可信DKIM通过d=example.com, s=analytics1将提供精确的对齐，但在证据存在之前，消息结果仍然未知。这里没有使用私钥、支持请求、 DNS查找或租户操作。
保留执行边界
RFC 9989 第 7.4 节要求有效的DKIM ，而不仅仅是SPF来进行域发布 p=reject，并对间接邮件和邮件列表互操作性发出警告。一次成功的直接消息测试并不能证明每条合法路线都已准备好采取更强有力的政策。保留现有批准的保护，同时诊断实际差距；任何政策变化都需要自己的决定。