Vendasta 合作伙伴营销和客户端域邮件具有单独的配置上下文。在请求DNS更改之前确定发送消息的帐户。合作伙伴的已验证域并不能证明每个客户端域都经过身份验证。记录企业所有者和独立更改每个客户端DNS权限。
使用正确的帐户记录
对于合作伙伴域，打开合作伙伴中心 > 营销 > 电子邮件设置，然后找到“电子邮件域”卡。当前文档描述了四个生成的记录： SPF TXT, DMARC TXT和两个 DKIM CNAME。复制两条DKIM记录。对于客户端，使用其业务应用程序 > 管理 > 电子邮件配置并授权域，然后发布该客户端显示的值并等待验证。 Vendasta 身份验证参考
将生成的SPF和DMARC建议与现有策略相协调，而不是创建重复项。保留其他合法发件人和批准的报告目的地。该文件最多允许 72 小时内出现验证；在重复重新创建记录之前，比较实际的DNS答案和确切的帐户状态。
在不改变无关策略的情况下诊断交付
对于客户网站表单，请检查发件人域以及它是否在该客户的帐户中获得授权。平台“已交付”标签可能意味着接收服务器已接受消息，而不是消息已到达收件箱。检查隔离区和收到的标头（如果可以访问）。不要采用过于广泛的故障排除捷径： SPF通过不是由终端~all或-all选择引起的，并且更改该终端机制不会修复通过但未对齐的签名。接收器过滤不是由一台DNS交换机决定的。使用下面基于标准的验收检查来单独授权， 结盟 和安置。
继续向域名所有者报告目的地和保留决策。不要仅仅为了消除报告量而删除 rua 或 ruf，而不了解所失去的可见性。提供商的简化交付表不会凌驾于接收者的自由裁量权之上： p=none 不是收件箱投递的承诺，并且将~all更改为-all不能更改之前匹配的SPF通行证。
验证DNS和真实的接收结果
在更改合作伙伴或客户营销域授权之前，导出现有DNS值、记录批准的差异并命名回滚所有者。确认DNS编辑器需要相对标签还是完全限定名称；加倍域名后缀会创建 一个记录 没有预期的验证者会发现。保存后查询实际所有者名称，包括任何 CNAME 目标，而不是依靠编辑的成功旗帜。
SPF必须在相关域中保留一项策略，并保持在 DNS 查询术语限制内 RFC 7208。添加包含本身并不建立对齐。在下面 RFC 9989，当至少一个成功的SPF或DKIM结果与适用模式下的可见发件人域一致时， DMARC通过。不需要将两种机制对齐作为标准强加的条件，并且不要将提供商域通行证误认为是对齐的客户域通行证。
从其域被授权到您控制的邮箱的确切帐户发送活动或客户通知。保存接收系统的可信身份验证结果、可见发件人、信封身份、 DKIM d= 和 s= 值、时间戳和提供商状态。 DNS查找仅显示可用的密钥； RFC 6376 验证还评估接收到的消息的签名。使用非敏感内容并避免将完整的客户消息暴露给公共检查人员。
使用有界接受和回滚决策
仅虚构的书面诊断案例：VD-01 假设代理域已在合作伙伴中心进行验证，而表单使用来自未验证域的客户端业务应用程序的info@client.example 。电子邮件历史记录显示已发送；收到的文件夹、 SPF和DKIM结果未知。客户端所有者必须在该客户端上下文中授权正确的域并检查受控接收的通知。机构验证和验收标签不会关闭客户对齐或收件箱放置。此示例没有测试任何帐户、 DNS 、中继或消息。
如果测试失败，单独缺少DNS ，错误 选择器、不活动的提供程序配置、意外的路由和消息修改，然后再进行另一次更改。每次批准的更正后重新测试相同的工作流程。不要削弱整个域的DMARC策略来隐藏单个发件人问题。在需要回滚的情况下，恢复批准的先前路由或发件人配置并保留关键记录，而排队的签名消息仍然需要它们。将测试证据和未解决的异常与域清单一起保存。在准备本指南时未执行租户访问、 DNS更改或实际发送。
保留可靠的验收记录
每个帐户、域和实质上不同的路由创建一行。记录企业所有者、 DNS所有者、更改参考、预期发件人、观察发件人、信封域和SPF结果、每个DKIM d= 和 s= 及其结果、适用的对齐模式、可信接收者和时间戳、提供商激活状态、放置观察、未解决的问题和下一步操作。将缺失值标记为未知，而不是将其视为通过或失败。车主仅接受有记录证据支持的预期路线和身份；否则保留该路线并遵循批准的恢复计划。
将传递的消息与执行准备情况分开
RFC 9989 第 7.4 节要求有效的DKIM才能进行域发布 p=reject 并对间接邮件互操作性提出警告。单个对齐的SPF结果本身并不能证明拒绝策略的推出是合理的。与此提供商设置分开审查所有合法路由和策略所有权。