HubSpot营销电子邮件和销售人员的连接邮箱是不同的发送安排。首先确定您正在配置的工作流程。验证营销发送域并不会建立与 CRM 关联的每条消息的状态。
本指南涉及用于HubSpot营销电子邮件的电子邮件发送域。在进行更改之前记录相关帐户、发件人域及其企业所有者。
选择适合工作流程的域
选择名称之前，请阅读当前的域资格指南。 HubSpot目前的说明规定，电子邮件发送域不得已用于其他目的，例如托管内容。合适的子域可以使该路由保持独特，但它仍然需要明确的所有者和经过测试的配置。
根据建议的发送域连接检查营销发件人地址中使用的确切域。看起来与品牌相似的新名称对于实际活动来说仍然可能是错误的名称。
映射域或子域的其他用途：托管内容、接收邮件、重定向、另一个HubSpot帐户和外部服务。在接受生成的DNS更改之前解决冲突。
将生成的DNS请求作为更改集进行查看
使用当前的电子邮件发送连接工作流程以及为帐户生成的值。 HubSpot的指南涵盖MX 、 DKIM, SPF 和 DMARC，其详细信息必须在其指定的所有者名称处进行检查。
请勿移动机构正常邮箱 MX记录 仅仅因为发件人工作流程显示MX要求。在生成的请求中确定确切的名称和用途。特定于子域的更改和根域更改会产生不同的后果。
对于SPF ，检查正在更改的确切名称处的现有策略。如果已经存在，请将所需的授权调整到该策略中，而不是在那里创建第二个SPF策略。将授权机制置于终止所有机制之前，并确保结果评估保持有效并在依赖于 DNS 的查找限制内。
将DMARC视为域所有者的策略决策。保留现有的合适策略和报告配置。营销设置不应重置对不相关邮件的控制。
检查DNS如何发布值
识别活跃的权威主机，而不是依赖注册商的名称。发布后比较完整的结果所有者名称和值。
HubSpot特别提到了Cloudflare代理和域范围的 CNAME 扁平化设置。遵循当前支持的身份验证记录要求，并单独评估任何更广泛的DNS更改。不要仅仅为了清除电子邮件设置警告而更改不相关的网站行为。
对于自动连接，请检查更改并记录实际写入的内容。对于手动连接，请检查后缀处理和记录类型冲突。两条路径都需要可观察到的公开答案。
验证实际的营销信息
完成HubSpot的身份验证检查，然后通过预期路由发送适当的受控活动测试。保留原始收到的消息、帐户上下文和发送时间。
检查可见的发件人、信封身份、 DKIM签名域和可信接收者结果。记录 结盟 支持DMARC路径。传递不相关服务域的签名本身是不够的。
在综合案例中， DNS团队成功连接了营销子域，但该活动仍然使用旧的根域发件人地址。配置和消息描述不同的身份。更正预期的发件人配置，然后重复活动路由测试，而不是向每个看似合理的名称添加记录。
不要将一项测试推广到每个连接的邮箱、事务路由或集成服务。测试与此更改范围相关的工作流程。
保留有用的完成记录
切换应识别帐户、选择的发送域、生成的记录、 DNS更改所有者和经过验证的消息。包括选择该域以及使用该域的任何其他帐户的原因。
当营销活动所有权发生更改或引入新的子域时，请检查配置。保留旧的依赖项直到验证停用为止，而不是在新活动成功后立即删除它们。
使用发件人库存将营销所有权与更广泛的邮件计划联系起来。身份验证建立身份路径；联系收件人的权限、列表质量和收件箱放置仍然是不同的事项。
将发件人更正与策略更改分开
书面案例 HS-01 假设营销帐户已连接news.example.com ，而计划的营销活动发件人为updates@example.com 。假设的可信消息结果是DKIM传递，其中d=news.example.com, s=demo1.该签名可以在普通宽松的组织域对齐下对齐，但与adkim=s. SPF和所有其他签名仍然未知，因此不要报告整体严格模式DMARC故障。营销负责人必须确认预期的发件人和匹配的产品连接，然后获取授权的营销活动样本；更改域范围的策略不是此处建议的修复。 example.com上的普通员工邮箱MX仍然不受此更改的影响。未测试HubSpot帐户、邮箱或DNS 。
使用生成的记录所有者和值，而不是将故障排除示例转变为通用选择器。 HubSpot目前会在存在策略时记录配对的DKIM CNAME 和SPF合并。它的状态标签描述了设置检查；即使经过完全验证的标签也不能证明此计划的活动选择了正确的发件人身份。
保留执行边界
RFC 9989 第 7.4 节要求有效的DKIM ，而不仅仅是SPF来进行域发布 p=reject，并对间接邮件和邮件列表互操作性发出警告。一次成功的直接消息测试并不能证明每条合法路线都已准备好采取更强有力的政策。保留现有批准的保护，同时诊断实际差距；任何政策变化都需要自己的决定。