从 Smaily 产品和帐户开始
Smaily 身份验证需要决定发送域和有权使用它的帐户。首先列出使用该域的活动、自动化和 API 触发的营销消息。记录其企业所有者和DNS管理员。多个品牌或机构使用的域名在所有权验证更改之前需要共享更改计划。
Smaily 还提供一个单独的交易平台，具有不同的界面和发送 IP，包括SMTP和 API 选项。不要假设营销帐户检查可以验证交易发票或应用程序警报。经过审查的产品页面建立了这种分离，但不是特定于帐户的交易DNS配方。保持该路由开放，以获取其自己的设置说明和收到的消息证据。 Smaily 交易产品描述、为什么使用交易电子邮件以及针对开发人员.
本指南开发记录的帐户域工作流程，同时保留该边界。它并不声称任何租户、域或消息已经通过。如果原始需求包括事务服务，则在对该服务也进行测试之前，无法接受实施。
在身份验证之前查看所有权变更
所有权指南将域验证置于“首选项”>“域”中。它支持电子邮件链接和 DNS 令牌验证。电子邮件验证链接持续 7 天。 DNS验证是首选，并且其令牌必须保持发布状态，因为 Smaily 会重新检查它。转向DNS验证会撤销其他帐户中先前的电子邮件链接所有权批准；每个授权帐户都需要自己的令牌。 Smaily域名归属指南、 DNS验证.
在批准更改之前，请识别合法使用该域的每个帐户，包括可能很容易错过的代理帐户。从目标账户获取当前代币。仅记录实施票所需的信息，并适当限制访问。不要复制另一个帐户的所有权令牌或删除不熟悉的令牌，因为它看起来多余。
保留技术通知的所有者和备用联系人。初始设置期间使用的邮箱在人员变动后可能会变得无人值守。查看谁可以请求新的发件人身份以及谁可以发布DNS 。所有权批准和消息身份验证是单独的证据行：传递一个证据永远不应该默默地关闭另一个证据行。
认真公布认证记录
Smaily的身份验证指南指定include:_spf.smaily.com和两个CNAME：blue.smly。 _domainkey为blue._dkim.smaily.com和 green.smly。 _domainkey为green._dkim.smaily.com 。这些是记录在案的公共记录，而不是对该帐户的DNS的观察结果。两个都 DKIM 需要输入条目。然后，它将管理员引导至“域”选项卡并进行身份验证；未解决的状态可以暴露哪些记录丢失。在更改DNS之前，请从该官方指南和帐户获取当前值。 Smaily 身份验证指南、 SPF 、 DKIM和记录检查.
保存现有区域并准备逐条记录的差异。确认DNS编辑器是否需要相对所有者或完全限定名称。保存后，检查生成的完整所有者名称，以便自动附加的域不会创建重复的后缀。 一个记录 如果管理屏幕不服务于权威区域，则在管理屏幕中可见是不够的。
为了 SPF，将其他授权发件人保留在相关所有者的一项策略中。不要将新的完整策略粘贴到现有的公司邮件策略上。评估限制包括嵌套的 DNS 查询术语，因此计算完整的依赖关系链，而不是仅计算可见的包含项。 RFC 7208 ，第 4.5 节和 4.6.4 节.
不要从示例中复制可选机制，除非域所有者实际上打算授权他们识别的主机。根据稍后在真实邮件中看到的信封域检查精确的SPF所有者。提供商请求的配置检查和接收者的SPF身份回答了不同的操作问题。
确认两条DKIM记录，无需猜测轮换
解析两个已颁发的DKIM所有者并按照他们的 CNAME 找到公钥答案。保存答案和观察时间。如果其中一个失败，请调查该记录，而不是假设另一个记录完成配置。保留不相关系统使用的现有选择器。
公共指南没有规定哪一个 选择器 特定消息将使用或承诺的密钥轮换时间表。测试实际存在的签名。一个 DKIM签名 通过 d 标识其签名域并通过 s 标识选择器；他们一起找到了钥匙。 RFC 6376 ，第 3.5 和 6.1 节.
如果帐户检查仍然不成功，请在再次编辑之前将预期的DNS值与权威答案进行比较。记录提供者的当前状态以及任何缺失记录的解释。当缓存仍保留先前版本时，避免重复更改。与记录所有者和定时观察升级可重现的差异，而无需发送帐户凭据。
测试将发送生产邮件的工作流程
使用无害的活动和代表性自动化来控制外部邮箱。如果 API 触发的消息使用其他发送方配置，请单独测试该配置。为每个测试提供一个可识别的主题并保留其消息 ID 和 UTC 时间。预览或来自员工邮箱的直接消息不能替代生产发送路径。
保留接收邮箱的原始标头。记录显示的From域， Return-Path、SPF 验证的域、所有DKIM d 和 s 值以及可信接收器结果。确定哪个传递身份与域策略下的可见发件人一致。 DMARC 需要通过对齐的SPF或DKIM路径；不相关的提供者签名不能确定该结果。 RFC 9989 ，标识符对齐解释和DMARC评估.
自定义信封域支持尚未经过审查的 Smaily 设置页面确认。不要发明反弹 CNAME 或承诺一致的SPF 。如果对齐的DKIM提供了通行证，请明确识别它。如果组织单独需要特定的信封域，请获取受支持的 Smaily 配置并在关闭该要求之前对其进行测试。
分别诊断所有权和交付
所有权失败首先指向已批准的帐户、验证方法和保留的令牌。 DNS 身份验证失败需要将发布的记录与公共答案进行比较。收到的消息的发件人身份错误，要求进行工作流配置审核。这些是不同的问题，不应通过添加其他SPF来解决所有问题。
如果DKIM通过但邮件落入垃圾邮件，请分别检查声誉、收件人期望和内容。身份验证不保证收件箱的放置。如果DMARC失败，请比较实际域和 结盟 考虑政策变化之前的模式。削弱组织现有的策略来交付一项测试并不是一个完整的实施。
记录移交和恢复计划
使用 Smaily 所有权和路线工作表（使用此处描述的字段创建单独的审核记录）。维护帐户所有权、两个DKIM记录、 SPF政策、活动证据、自动化证据和任何交易路径的不同行。指定将批准每个未解决的需求的人员。
如果测试失败，请使用批准的操作计划暂停受影响的工作流程。仅在检查其所有权和记录是否仍然有效后才能恢复之前测试的发件人配置。当其他授权帐户或排队消息依赖于所有权令牌或身份验证记录时，请勿删除它们。 DNS迁移、帐户转移或更改发送产品后重新测试。
涉及代理账户的虚构诊断案例
仅虚构的书面案例：SM-02 假设品牌帐户将books.example从电子邮件链接切换为DNS所有权，而授权机构仍需要发送offers@books.example 。该机构自己的DNS令牌尚未发布；其消息认证结果未知。品牌所有者必须确认持续的代理授权、获取该帐户的单独令牌并在受控活动测试之前验证所有权。如果后来通过了品牌帐户测试，则不会获得该机构的许可。未访问任何令牌、帐户、 DNS或活动。
仍在等待接受
仅在所有权、身份验证检查和接收者证据一致后才接受记录的路线。对于任何未经验证的交易或定制信封要求，原始范围的接受仍然悬而未决。对于此未发布的草案，实时租户访问、 DNS和消息测试、独立技术审查、目视审查和 SME 人工批准仍有待完成。
将传递的消息与执行准备情况分开
RFC 9989 第 7.4 节要求有效的DKIM才能进行域发布 p=reject 并对间接邮件互操作性提出警告。单个对齐的SPF结果本身并不能证明拒绝策略的推出是合理的。与此提供商设置分开审查所有合法路由和策略所有权。