慎重选择发件人验证模型
对于组织自己的域，SMTP2GO 发件人域验证是记录的客户域身份验证路径。单一电子邮件验证是一个不同的选项，并且不提供相同的功能 SPF 和 DKIM 结盟。从应用程序将使用的域和地址开始，而不是选择最快的验证屏幕。 SMTP2GO 验证选项、发件人域和单个发件人电子邮件.
列出实际来源：应用程序 API 调用、 SMTP中继客户端、设备和集成。记录每个帐户或子帐户，来自域和操作所有者。共享域并不意味着每个路由都使用相同的凭据或配置。明确包含后备路由，并且不要将其成功交付视为对主要路由的测试。
SMTP2GO 文档根据需要验证发件人，并将未经验证的发件人的尝试记录为拒绝。它的推出公告也解释了它的 返回路径 子域模型以及为什么存在根 SPF记录 不需要扩展。 SMTP2GO 验证发件人公告.
捕获发布到帐户的三个记录
在“发送”>“已验证的发件人”>“发件人域”中，添加目标域并捕获三个 CNAME 记录。文档集涵盖返回路径/ SPF功能、 DKIM和跟踪。发布当前发布的值而不是通用示例。该指南提供手动DNS更改或自动DNS流程。 SMTP2GO 验证发件人，步骤一和二.
发件人域指南允许现有DNS子域在经过验证的顶级域下发送。这是发送许可，而不是每个子域严格对齐的证明。如果政策禁止 CNAME，指南将根据要求提供TXT / MX配置；获取受支持的替代方案，而不是自己翻译记录。
通过组织的变革流程选择方法。自动化流程可能会请求访问DNS ，因此在授予之前准确检查其建议的访问权限和更改。手动发布仍应使用相同的已审核记录集。不要仅仅为了避免理解命名冲突而授予更广泛的访问权限。
对于每条记录，保存完整的所有者、目标和 TTL。检查建议名称的现有使用情况，包括其他 CNAME、证书、跟踪服务和邮件处理。发生冲突时，请向帐户管理员询问受支持的备用主机名；不要发明新目标或覆盖现有服务。
保持SPF和追踪的不同
SMTP2GO 的客户域返回路径是相关的SPF身份。将包含添加到公司根策略并不能替代已发布的返回路径CNAME 。当根策略已授权多个不相关的服务时，这种区别特别有用。保持这些现有权限不变，除非单独审核的更改需要它。
SPF检查事务中使用的SMTP身份。其评估规则不会自动将策略从可见的发件人域传输到不同的信封域。 RFC 7208 ，第 2.4 节和第 4 节.
跟踪CNAME有一个单独的目的。 SMTP2GO 在验证后记录该跟踪名称的 HTTPS 证书配置。跟踪问题应根据其本身的条件进行调查，而不是解释为DKIM密钥丢失的证据。 SMTP2GO 已验证发件人，跟踪域.
在工作表中单独记录跟踪验证和证书状态。如果隐私或通信政策限制跟踪，请让相应的所有者检查这些应用程序设置。身份验证工作不应默默地激活不相关的分析功能。
验证公共DNS和帐户访问权限
检查来自权威DNS服务的公共CNAME答案，并将其与发布的记录进行比较。确认DNS编辑器未两次附加域或更改目标。当权威服务器之间的结果不同时，请解决该不一致问题，而不是在 SMTP2GO 中重复重新创建域。
提供商指南支持授予选定子账户对主账户中验证的域的访问权限。确认实际发送子账户具有该访问权限。不要假设主帐户中出现的域在任何地方都可以自动使用。该指南通过不可编辑的主标签识别子帐户中分配的域；记录实际发送帐户的证据。 SMTP2GO 验证发件人、子帐户访问.
记录哪个帐户拥有该域、哪些子帐户被授权以及谁可以更改这些权限。对于客户端或多品牌使用，请保留对特定域和发件人目的的授权。 DNS控制不会决定是否允许特定应用程序作为该品牌发送。
在使用时单独测试SMTP和 API 路径
API 文档将 API 密钥身份验证和发件人验证视为单独的要求。仅凭有效密钥并不能授权未经验证的发件人身份。 SMTP2GO API 指南、身份验证和发件人验证.
使用无害的内容控制外部邮箱并通过每个材料路径发送。保留应用程序标识符、UTC 时间、消息 ID 和相应的提供商活动记录。对于设备或集成，从该设备或集成进行测试，而不是仅从开发人员的单独测试脚本进行测试。即使应用程序预期使用其他内容，也保留观察到的 From。
在接收方，记录Return-Path 、可信SPF身份和结果、每个DKIM d 和 s 值以及 DMARC 结果。检查公钥的 选择器 实际使用过；已验证但未使用的选择器并不能证明消息是用它签名的。 RFC 6376 ，第 3.5 和 6.1 节.
确定哪个经过身份验证的域与可见的发件人一致。子域返回路径可以满足宽松的SPF对齐，而不满足严格的精确域对齐。对于DMARC来说，一种通过的对齐机制就足够了，尽管单独的提供商或组织要求可能需要这两种机制。 RFC 9989 ，标识符对齐解释和DMARC评估.
将DMARC策略保留在域所有权之下
SMTP2GO 的DMARC设置页面将策略发布放置在域的DNS中而不是发送平台中。将此视为也会影响其他发件人的单独域级别更改。 SMTP2GO DMARC指南，如何设置DMARC.
使用当前协议定义进行通过决策。一些提供商的解释性措辞将身份验证和交付压缩为更简单的故事；它不应该超越对齐、策略和接收者独立过滤之间的区别。不要仅仅为了使未经验证的单一电子邮件路由可用而降低现有的强制策略。
如果邮件在提交完成之前被拒绝，请检查发件人验证、帐户范围和实际发件人地址。如果消息以意外身份传送，请检查集成的覆盖和帐户选择。如果身份验证通过，但垃圾邮件放置情况仍然很差，请分别调查声誉、收件人期望和内容。反复更改 CNAME 并不是一般的可交付性补救措施。
记录推出和恢复路线
使用 SMTP2GO 域和应用程序工作表（使用此处描述的字段创建单独的审核记录）。它将三个DNS功能、子账户权限和特定路由的接收者证据分开。记录任何验收检查失败的确切原因，而不仅仅是红色或绿色状态。
如果部署失败，则通过已批准的、先前测试的路径暂停或重新路由受影响的应用程序流量。保留排队邮件和工作集成所需的记录。在停用域之前，请验证是否没有任何设备、客户帐户或后备路由仍依赖于该域。更改DNS主机、应用程序身份或子帐户访问后重新测试。
涉及错误账户的虚构诊断案例
仅虚构的书面案例：S2G-01 假设主帐户已验证service.example ，但发送alerts@service.example的应用程序使用没有所需域分配的子帐户并收到提交拒绝。对于该被拒绝的尝试，不存在收件人SPF 、 DKIM或DMARC结果。应用程序所有者必须验证帐户选择并获得小范围域分配的批准，然后测试相同的路由。主账户示例并不能解决子账户问题。未使用 API 密钥、租户权限或消息。
仍在等待接受
仅当实际路由使用批准的域、发出的DNS记录解析、相关帐户范围验证以及可信接收器结果建立所需的对齐时才接受。对于此未发布的草案，实时租户、 DNS和消息检查、原始范围验收、独立技术审查、目视审查和 SME 人工批准仍有待完成。
将传递的消息与执行准备情况分开
RFC 9989 第 7.4 节要求有效的DKIM才能进行域发布 p=reject 并对间接邮件互操作性提出警告。单个对齐的SPF结果本身并不能证明拒绝策略的推出是合理的。与此提供商设置分开审查所有合法路由和策略所有权。