将 Concep SEND 域选择与签名激活分开
康塞普官方 域名选择指南，于 2020 年 9 月 18 日更新，区分公司发送域和子域。它是 使用DKIM指南签名，于 2020 年 7 月 2 日更新，描述了支持辅助密钥和激活工作流程。这些过时的说明提供了具体的起点，但当前产品的适用性仍然开放。本文并不声称当今的每个 Concep SEND 帐户都使用相同的基础设施或控件。
第一个决定是活动将在其发件人地址中使用哪个域，以及托管链接是否需要单独的品牌名称。域指南称，公司域和子域都可以用于发送，而只有子域可以在其记录的安排中托管活动链接。如果没有该子域选择，链接将托管在emailcc.com上。不要将成功的品牌链接视为发件人域已通过身份验证的证据。
准备一份包含预期发送域、链接域、帐户和负责的DNS管理员的清单。在提交之前确定提议的名称的现有用途。与员工邮件或其他营销系统共享的域需要协调；不应仅仅因为活动所有者可以编辑发件人地址而重新配置它。本稿件未访问任何帐户或DNS设置。
查看历史子域和公司域说明
对于子域名的安排，2020 年指南指定了 CNAME 指向emailcc.com 。对于公司发送域，它指定 SPF 使用include:emailcc.com.保留区别，而不是将子域别名放置在组织的区域顶点或假设相同的记录用于这两个目的。在进行生产更改之前确认当前提供商发布的配置。 Conceptp 域选择指南
该指南有关附加完整SPF示例的措辞不应从字面上理解为连接两个v=spf1策略的指令。在下面 RFC 7208 ，第 3.2 节，一个域不得发布导致选择多个SPF策略的多条记录。将批准的授权合并到现有策略中并保留其他合法发件人。不要插入第二个版本标记或默默地替换终端限定符。
CNAME所有者还需要进行冲突审查。建议的记录不允许覆盖现有的邮件、网站或验证依赖项。记录完整的所有者和目标，并将它们与DNS编辑器的命名约定进行比较。如果在不检查其解释的情况下复制输入，则附加区域名称的编辑器可能会产生意外的重复后缀。
请求DKIM之前确认发送域
这 DKIM 指南指出，在DKIM请求之前，必须已使用 Concep 设置子域或公司域。然后，支持人员与 IT 部门协调生成密钥，客户的DNS团队将其作为密钥发布 TXT记录。该文章不提供可重复使用的 选择器 或所有客户的公钥。使用预期域的实际提供的所有者和值，并将请求引用附加到该更改。 Concep 与DKIM签约
明智的建议切换会识别发送域、帐户范围、 DNS运营商和预期完成证据。它不需要包括活动收件人、机密内容或凭据。发送支持请求是一种外部通信，需要经过授权的操作员；本指南既不创建票证也不暗示已提交票证。在得到确认之前，域当前是否符合记录流程的资格仍悬而未决。
在发布之前查看请求的选择器中的现有数据。较旧的密钥可能仍可服务于活跃流量，并且更换可能需要协调。公共DNS密钥不是对提供商私有签名密钥的请求。保持明确的区别，以便支持移交不会成为不必要的凭证共享或签名责任中未经审查的变更。
保留提供商端激活步骤
保存TXT记录时，历史DKIM工作流程不会结束。它说客户在发布后通知支持人员； Concep 验证传播并将相关帐户切换到其专用的DKIM邮件服务器安排。然后它描述了来自帐户的提供商测试消息以及dkim=pass.将此视为记录的序列，而不是任何当前账户已完成这些操作的证据。 Concep 与DKIM签约
记录提供商完成确认与DNS发布分开。这种区别很重要，因为正确发布的密钥不能导致不相关的发送系统用它进行签名。如果提供商表示当前的工作流程有所不同，请根据该帐户特定的证据更新实施计划，而不是将历史顺序强加到新的产品版本上。不要发明引用的工作流程未记录的启用签名控件。
提供商的测试描述建立了有用的DKIM检查点，但单独dkim=pass并不能证明 结盟 与活动的可见作者域。 RFC 6376 ，第 3.5 节 标识签名的 d= 签名域和 s= 选择器。通过授权证据流程捕获这些值并将它们与批准的配置相关联。属于另一个服务身份的成功签名是不同的结果。
检查实际路由上的SPF和DMARC
SPF评估SMTP身份，而不仅仅是活动编辑器显示的地址。 RFC 7208 ，第 2.4 节 描述了 邮件来自 身份，而第 4.6.4 节对评估的 DNS 相关术语设置了限制。查看实际的信封域和完整的策略，包括嵌套依赖项。可见的包含字符串既不能证明接收者使用该策略，也不能证明完整的评估预算评估。
RFC 9989 ，第 4.4 节 添加作者域和传递的经过身份验证的身份之间的对齐。通过对齐的SPF或通过对齐的DKIM可以满足该身份验证条件。不要声称 Concep 的历史提供商测试会关闭所有 DMARC 要求或多品牌帐户中的所有域共享相同的结果。每个预期身份都需要自己的证据边界。
来源对非垃圾邮件传递的广泛保证并不能保证。身份验证、 SMTP接受、文件夹放置和参与是不同的观察结果。因此，没有记录观看次数的活动并未被证明未经验证或被阻止。使用实际的诊断证据并避免广泛的收件人允许列表请求作为识别故障的替代方法。这里没有提出这样的请求或测试。
虚构的诊断：已发布密钥，未完成的提供商过渡
一个虚构的专业协会 Alder Council 从支持部门收到DKIM值，并要求其DNS团队发布该值。变更单关闭后，活动所有者立即将项目标记为完成。后来的准备情况审查没有发现提供者端帐户转换或所描述的测试已经发生的确认。因此，该团队将DNS发布记录为虚构案例中的完整证据，但未解决发送准备问题。
建议的下一步是获得授权提供商的确认，然后检查无害的消息证据以了解预期的发送者身份。并不是重复更换密钥或假设单独等待就会激活签名。此示例是虚构的：它不代表真实的票证、 DNS观察、帐户迁移或收到的消息。
空白验收工作表和发布边界
- 注明日期的指南的当前帐户、产品路线和适用性：______
- 发送域与链接托管域以及现有依赖项：______
- 已批准的SPF授权合并为一项一致的政策：______
- 支持请求参考和域设置先决条件：______
- 已颁发DKIM所有者、公共价值和DNS发布证据：______
- 提供商激活或转换确认：______
- 授权消息d=, s=,信封域和可信结果：______
- DMARC一致性评估、剩余例外情况和所有者决定：______
该目录的原始实施证据、人工审查、来源适用性、生产路线、视觉可访问性和所有者发布仍然开放。历史公共工作流程支持该文档草案；它不建立当前租户执行或授权发布、支持外展或DNS更改。