将电子邮件和SMTP视为共享设置的单独测试
SendPulse 记录了电子邮件和SMTP的共享身份验证域列表。适用的域名限额为两个计划中的较高限额，每个子域名单独计算；跟踪域不消耗该身份验证限额。其当前指南提供了一个免费计划示例，其中包含一个电子邮件域和两个SMTP域，允许两个共享条目。在规划多个品牌或子域名之前，请先确认真实账户的限额。 SendPulse 电子邮件身份验证，生成您的DKIM和SPF记录.
共享设置减少了重复的DNS工作，但它们并不能证明每个应用程序都选择了预期的 From 域。库存营销活动、自动化和通过SMTP或 API 提交的应用程序。捕获每个路由的帐户和预期域、企业所有者、应用程序所有者和DNS管理员。将提交凭据保留在此工作表之外。
本指南涵盖提供商的公共电子邮件和SMTP身份验证工作流程。它不假设无限的域名限额，独立选择的自定义 Return-Path 或每次集成中的最终身份相同。如果业务需求依赖于严格的 结盟 或特定的包络域，请在提交之前从 SendPulse 获取支持的设计。
在生成记录之前检查现有域
在电子邮件中，记录的入口点是“设置”>“域设置”，然后在经过身份验证的域区域中激活。在SMTP中，使用SMTP设置 > 域设置和发送域区域。两个工作流程都会生成 SPF 和 DKIM 输入域的记录。 SMTP文档称现有电子邮件身份验证不需要另一个DKIM设置，因为服务共享记录设置。 SendPulse SMTP DKIM 、共享记录设置和添加新域.
当已有域存在时，首先打开现有域。记录其当前连接状态和公共值。不要仅仅因为新应用程序正在使用SMTP就生成第二个安排。如果两个帐户或团队声明相同的域，请在更改共享之前比较其当前提供商发布的说明并澄清所有权 选择器.
计算部署所需的域，包括单独验证的子域。如果帐户处于其允许范围内，请勿仅仅为了暴露“添加”控件而删除工作域。确定使用该域的内容，并与帐户所有者一起选择计划或域策略。商业权利决策与DNS故障是分开的。
使SPF指令与现有策略保持一致
SendPulse SPF指南指导用户使用现有的 SPF记录 将提供者的授权添加到该记录中，而不是创建第二个记录。引用的指南名称include:mxsspf.sendpulse.com ，作为现有政策的补充。确认当前帐户的域设置的适用性；样本 a 和 mx 项不是自动添加的。请勿将完整策略示例复制到现有策略之上。 SendPulse SMTP SPF ，复制SPF记录并将条目添加到DNS提供商网站.
在编辑之前导出确切所有者的当前TXT答案。列出依赖于其SPF策略的其他服务，并在可能的情况下识别基线消息中的实际信封身份。公司发件人域和 SPF 身份验证的域可能不同。在任意顶点发布包含无法修复在其他地方评估的故障。
根据十个术语评估限制，检查所有 DNS 查询SPF术语，包括嵌套包含。符合编辑器长度限制的DNS记录仍然可能超出协议的评估限制。保留合法授权和批准的结束限定符。除非域所有者已评估其授权内容，否则请勿使用示例 a 或 mx 机制扩大权限。 RFC 7208 ，选择记录和DNS查找限制.
如果提供商的请求与组织的现有政策无法安全协调，请在发布之前停止。要求邮件所有者评估受支持的发送子域或其他适当的设计。在做出决定时保持现有工作路线可用。
将帐户公钥发布给正确的所有者
SendPulse 的说明将DKIM显示为 TXT记录 并明确区分演示公钥和帐户自身的值。该指南说明了标志。 _domainkey作为TXT所有者；从域设置中检索当前的全名和公共值，而不是将插图视为每个帐户的证据。不要重复使用文章中的长示例密钥。 SendPulse SMTP DKIM ，复制现有域记录.
检查建议的选择器所有者处的任何现有记录。预先存在的密钥可以支持不同的帐户、提供商或操作路线。请求支持的解决方案，而不是默默地替换它或发明一个服务不会使用的新选择器。保留先前公共记录的副本有助于审核者评估恢复情况，但它并不授权在不协调签名状态的情况下恢复过时的密钥。
使用权威的DNS提供商，不一定是域名注册商。确认编辑器是否需要相对主机名或完全限定名称。保存后，查询完整所有者，并将完整的公开值与帐户输出进行比较。 TXT字符串可以分段显示；比较它们的组合内容，而不是在片段之间插入空格。
只有公共验证材料才属于DNS或实施工作表。 DNS审核不需要私人签名密钥、 SMTP密码和 API 机密。为受影响的域和公共记录证据提供支持，而无需发送凭据。
验证连接状态和发件人选择
电子邮件文档使用“检查DNS记录”并将成功条目更改为“已连接”。其设置指令还要求经过身份验证的域与发件人地址域相匹配。 SendPulse 电子邮件身份验证，生成您的DKIM和SPF记录并检查条目状态.
检查两个服务视图中的适用状态并记录时间戳。如果一个团队看到不同的域列表，请在更改DNS之前验证两个团队是否都在预期帐户中。请勿假设一个帐户的状态证明另一帐户已准备就绪。
然后检查营销工作流程和每个提交应用程序中配置的发件人地址。查看迁移后可能保留旧域的自动化模板和应用程序默认值。在预览屏幕中选择的发件人可能与后台作业使用的地址不同。捕获正在测试的类似生产工作流程的实际设置。
保持跟踪域配置不同。品牌跟踪域对于链接很有用，但它不能替代发件人选择的经过身份验证的域。接受记录绝不能从跟踪主机名或明显品牌化的消息中推断出DKIM或SPF一致性。
独立证明电子邮件和SMTP路由
通过一项代表性活动和一份代表性申请提交来发送无害的消息。为不同的 From 域、应用程序覆盖或路由安排添加更多案例。使用受控的外部收件人并保留原始标头、消息 ID、提交时间和工作流程标识符。
对于每种情况，记录可见的发件人、SPF 验证的域、 Return-Path以及每个DKIM d= 和 s= 值。 DKIM签名域和选择器标识公钥查找； DNS中的有效密钥本身并不能证明实际消息使用了它。 RFC 6376 ， DKIM-Signature标头字段和从消息中提取签名.
使用受信任的接收方结果来区分加密通行证和对齐通行证。 DMARC 可以通过合格的对齐SPF或DKIM结果，并且对齐模式影响域比较。记录哪个机制提供结果，而不是只写“身份验证通过”。 RFC 9989 ，标识符对齐解释和DMARC评估.
如果活动通过但应用程序未通过，请先比较实际的发件人、帐户和路由。不要将共享密钥作为第一响应进行轮换。该更改可能会影响有效的营销流，同时保持应用程序的错误发件人地址不变。
在不中断两个服务的情况下诊断共享记录问题
对于DNS验证失败，请检查发布的所有者、记录类型、完整值和权威提供商。对于丢失的签名，请确认测试使用了经过身份验证的域和预期的 SendPulse 帐户。对于签名失败，请比较观察到的选择器和密钥，并检查另一个网关是否更改了签名内容。
如果SPF通过但DMARC失败，请在添加授权之前比较身份。如果SMTP提交在传送前被拒绝，请将提交错误与收件人身份验证结果分开。仅通过DNS检查无法诊断凭证、配额或应用程序格式问题。保留精确的错误，而无需将机密复制到支持包中。
如果自定义信封要求仍未满足，请获取适用于确切帐户的 SendPulse 支持的选项。审查的说明并未规定每个客户都可以分配任何所需的Return-Path域。不要发明MX或 CNAME 安排来近似尚未确认的特征。
工作表恢复和虚构的测试失败
完成 SendPulse 共享域工作表（使用此处描述的字段创建单独的审阅记录），每个经过身份验证的域有一个行组，每个电子邮件或SMTP路由有一个证据条目。记录计划限额、现有选择器依赖性、 DNS结果、发件人配置和接收消息结果。明确标记未知数。
虚构的书面案例 SP-01：假设来自courses@example.org活动已通过d=example.org,但课程申请从lessons@old.example提交， DKIM / SPF结果未知。 example.org的连接状态未建立old.example的身份验证。应用程序所有者应确认批准的发件人、比较共享域库存并测试课程路线，而无需轮换工作密钥。没有访问任何帐户或消息，也没有执行更正或测试。
在更改之前，决定如何暂停每个受影响的流并恢复上次批准的发送器配置。协调所有共享密钥的服务的密钥更换。停用后，请在删除身份验证记录之前停止每个相关应用程序和活动。计划更改、帐户迁移、 DNS托管更改或新应用程序路由后重新测试。
仅关闭测试范围
接受需要正确的域名权利、帐户颁发的记录、有效的公共DNS 、连接的提供商状态、预期的发件人选择以及每个材料路由的可信接收者证据。经过验证的活动不会关闭未经测试的SMTP集成。真实账户、 DNS和消息检查、独立技术审查、目视审查和 SME 人工批准仍在等待中；该草案尚未发布，也没有声称已完成部署。
将传递的消息与执行准备情况分开
RFC 9989 第 7.4 节要求有效的DKIM才能进行域发布 p=reject 并对间接邮件互操作性提出警告。单个对齐的SPF结果本身并不能证明拒绝策略的推出是合理的。与此提供商设置分开审查所有合法路由和策略所有权。