分别对待地址验证和身份验证
经过验证的发件人地址证明可以访问该邮箱；它本身并不能证明时事通讯已经一致 DKIM 或者 SPF。从您的组织控制的域、批准的发件人地址、 DNS管理访问权限和活动所有者开始。在更改记录之前，清点已为该域发送的其他服务。
GetResponse 记录的域工作流程位于“个人资料”>“电子邮件和域”下。自定义DKIM使用帐户中生成的密钥和标识符。不要使用通用的 选择器 来自教程或从其他帐户导出的密钥。相关问题是哪个域对实际消息进行签名，而不是发件人地址是否已成功添加。
将此电子邮件域的工作与网站和登陆页面域配置分开。重定向 名称服务器 或者连接网站并不只是为了在现有DNS主机上发布身份验证记录。
生成并发布DKIM记录
在电子邮件地址中，打开域的操作菜单，选择查看 TXT记录 并使用DKIM验证您的域。复制显示的标识符和密钥。该文档还提供了 2048 位密钥 选项并警告确认生成会使现有密钥和标识符无效。将该操作计划为协调轮换，而不是无害的显示偏好。
在轮换之前，记录当前选择器和签名状态，确定可以及时发布DNS人员，并商定如果验证失败，活动将如何暂停或恢复。不要认为旧密钥在产品失效后仍然可用。在依赖提供商之前解决任何重叠或回滚功能。
将返回的TXT所有者和完整值发布到权威DNS服务处。检查编辑器的后缀规则和长TXT处理。截断的键、丢失的选择符或重复的域后缀可能会使明显保存的记录无法使用。如果 UI 无法保留整个值，请获取受支持的 DNS 主机指南，而不是将密钥拆分为独立的记录。
在批准之前检查自动设置
GetResponse 还记录了使用 Entri 的自动流程。添加并验证发件人地址后，从域菜单中选择“身份验证”。该流程可以在继续之前显示建议的文本记录、检测DNS提供商并请求相关登录和确认。如果集成无法完成作业，手动设置仍然是一种替代方案。
记录了添加自定义DKIM 、 SPF TXT记录和 p=none DMARC 当正确的策略尚不存在时。在授权之前，根据现有记录检查提议的更改。自动化并不能消除保留强制策略的需要，避免重复 SPF记录 或查看授予DNS集成的权限。
不要假设成功的集成确认可以证明每个请求的记录都已发布在正确的所有者处。之后比较权威答案并保留准确的更改集。如果过程中途失败，请在重试之前检查已更改的内容，以便第二次尝试不会造成冲突或难以恢复。
了解单独的SPF决定
GetResponse 的SPF页面显示其发送域已经具有SPF并且添加 一个记录 仅通过服务发送不需要到客户的可见发件人域。它为选择配置它的客户提供帐户显示的SPF信息。使用这些当前值而不是猜测通用包含。
协议区别很重要： SPF评估 信封发件人 域，而不是可见的 来自标题。如果邮件实际上使用不相关的信封域，则添加到example.com权限无法制造对齐。与example.com一致的有效自定义DKIM签名可以独立提供DMARC路径。在将根SPF更改视为修复之前，请验证该消息的作用。
如果需要合法的SPF更新，请检查现有策略及其 DNS 查找成本。在该所有者处保留一条有效的候选SPF记录，并保留其他批准的发件人。请勿连接两个完整的v=spf1策略或在第一个策略旁边创建第二个TXT策略。
验证实际活动
查询每个权威服务器以获取确切的DKIM所有者，并将完整的公共值与帐户进行比较。根据需要重复产品验证，以便在权威发布正确后允许之前缓存的答案。然后通过预期的 GetResponse 工作流程将受控新闻通讯发送给有权访问原始接收标头的授权收件人。
捕获可见的发件人、信封域、每个DKIM d= 和s=,以及受信任的接收者身份验证结果。综合示例：消息具有 From news@example.com ， SPF通过提供商拥有的信封， DKIM通过d=example.com.提供商拥有的SPF通行证与example.com不一致，但精确域DKIM通行证可以满足DMARC 。如果签名域由提供商拥有，请勿仅仅因为DKIM本身已通过而将其称为自定义域成功。
测试每个本质上不同的域和发送工作流程。从与验收样本不同的地址发送的新闻通讯可能会采用不同的域配置。成功的DNS测试并不能替代路由级验证。
诊断并保留恢复记录
如果DNS中缺少该密钥，请修复确切的所有者或值。如果密钥正确但签名不存在或使用其他域，请检查所选的发件人和产品设置。如果身份验证通过但放置较差，请分别调查同意、声誉、内容和接收者策略； DKIM不保证收件箱的放置。
保留旧配置、建议更改、实际更改、验证结果和消息证据。不要削弱域范围的DMARC策略来隐藏失败的轮换。本指南基于保留的第一方文档和综合解释，而不是实时 GetResponse 租户或交付的活动。生产验收需要管理员的当前证据和人工批准。
确定失效后恢复的含义
对于写入轮换情况 GR-01，假设管理员确认生成 2048 位选项，新帐户标识符为 demo-new，并且该区域仍仅包含 demo-old。没有观察到当前的公钥或收到的签名。活动所有者暂停受影响的发布，而DNS所有者在其所需所有者处获取并发布确切的新生成值。在记录的失效之后重新发布旧值不是受支持的恢复假设；在依赖提供商之前询问其任何可恢复的签名状态。仅在权威比较和实际d=/s=且可信结果满足接受的受控活动之后才关闭。此示例未发生密钥生成、 DNS编辑或发送。
保留执行边界
对于发布p=reject, RFC 9989第 7.4 节要求有效的DKIM而不仅仅是SPF ，并就间接邮件和邮件列表互操作性发出警告。一次成功的直接消息测试并不能证明每条合法路线都已准备好采取更强有力的政策。保留现有批准的保护，同时诊断实际差距；任何政策变化都需要自己的决定。