将此工作流程范围限定为 Spotler Mail+
Spotler 是一个产品系列，而不是单一的通用发送配置。本指南涵盖了其帮助中心中记录的 Mail+ 域身份验证工作流程。它不能替代 SendPro、MailPro 或其他 Spotler 产品的相同说明。在获取DNS说明之前，确定帐户的确切产品和预期发送域。目录标题被保留，而实施接受仍然仅限于有证据的 Mail+ 路由。
Mail+需要正确的 DMARC 通过产品发送的身份验证。其设置页面描述了检查域状态、请求身份验证以及让域管理员实施提供的记录。该产品先决条件不得简化为可选建议。它也不能扩展到声称身份验证可以保证递送或每个邮箱提供商都有相同的规则。 Spotler Mail+ 设置说明
从回复地址和DNS责任开始
提供商表示，在此设置之前，Mail+ 中必须存在回复地址，并且必须有人能够修改域的DNS设置。记录这两项责任。 Mail+帐户操作员可以获得申请说明，而DNS管理员必须评估并批准实际的记录更改。两个角色都不应该假设对方已经检查了共享该域的每个发送系统。 Spotler Mail+ 设置说明
盘点预期回复域及其业务用途。记录的设置视图将回复地址与回复域相关联，提供商会指导具有多个域的用户配置每个域。成功设置公司根域并不能证明已配置单独使用的子域或其他品牌域。识别每个实际的域字符串并避免将看起来相关的名称折叠到一个接受行中。
请勿在此清单中收集DNS密码、私人签名密钥或不相关的邮箱内容。变更请求需要公共记录详细信息、帐户上下文、批准者和预期结果。它不需要广泛访问域管理员的凭据。本指南描述了准备和审查；未进行身份验证请求或DNS修改。
正确解释三个初始状态
记录的导航是左下角的帐户菜单、设置、安全性和可交付性。 Mail+ 显示回复地址、域和DMARC状态列。该页面区分“活动”、“发生问题”和“无DMARC身份验证”。如果配置已存在，但 Mail+ 未完全授权，则说明页面会为域管理员标识缺失的记录。没有身份验证的域将继续执行请求步骤。 Spotler Mail+ 设置说明
在提出更改之前保留初始状态和时间戳。 “发生问题”是检查特定缺失授权的原因，而不是删除现有组织DMARC策略的原因。同样，空白或非活动产品状态并不表明该域根本没有DNS记录。应用程序视图和权威DNS视图回答相关但不同的问题。
请求正确的帐户说明
在交付能力中，提供商描述了如何使用域的上下文菜单来请求DMARC身份验证。该对话框要求输入 DKIM 密钥格式和建议 2048 位，并由域管理员确认兼容性。然后状态更改为请求身份验证，并且请求用户收到一封说明电子邮件。使用特定于账户的指令集，而不是借用其他客户的价值观或猜测 选择器. Spotler Mail+ 设置说明
提供商的单独密钥大小故障排除答案涉及支持在请求不同配置之前删除当前身份验证。请勿将其解释为在不评估其依赖关系的情况下删除实时密钥或降级现有部署的权限。签名配置的更改可能会影响仍在生成或等待传递的消息。与负责的帐户和DNS所有者一起规划任何过渡；这份手稿没有进行这样的转变。
对于多个 Mail+ 帐户中使用的域，提供商建议配置一个帐户并联系支持人员。这是一个特定的跨账户协调要求，并不能证明将记录独立复制到每个账户是安全的。让帐户及其所有者在工作表中可见。尚未发送针对此草案的支持通信。 Spotler Mail+ 设置说明
在DMARC政策之前审查SPF和DKIM
管理员指令将DKIM和 SPF 首先说包括其他发送服务器。将提供的值视为完整策略审查的输入。添加新服务时，现有SPF授权不应消失。在相关所有者处保留一项适用的SPF策略，并根据协议限制评估完整的嵌套路径。这些是DNS和SPF要求，而不仅仅是产品屏幕中的目视检查。 Spotler Mail+ 设置说明 RFC 7208 ，多记录和查找限制
对于DKIM ，保留为帐户提供的完整所有者名称、记录类型和公共值。确认DNS编辑器如何解释所有者名称和长TXT内容。一个 TXT记录 可以包含多个字符串；这不是创建多个不相关的密钥记录的指令。拆分演示文稿时，请勿向关键材料添加空格。 RFC 1035 ， TXT格式 RFC 6376 ，密钥存储
提供商提供说明性DMARC策略，包括监控和报告字段。不要将其解释性地址占位符粘贴到生产中，自动降低现有的执行策略，或者在没有批准的收件人和数据处理目的的情况下启用故障报告。检查组织的现有政策和其他合法发件人。消息来源建议合并现有配置意味着将预期设置协调为有效策略，而不是连接两个完整的配置 DMARC记录.
DMARC评估可见作者域和合格的经过身份验证的标识符之间的关系。通过对齐的SPF或DKIM路径可以支持DMARC ；应用程序配置这两种机制的请求是产品工作流程要求，而不是对该协议规则的更改。在验收记录中保留这两种区别。 RFC 9989 ，标识符对齐
绿色支票不是最终验收测试
管理员完成记录后，提供商会指导用户检查“送达能力”中的DMARC身份验证是否处于活动状态。但是，同一页面警告绿色检查可能与发送失败共存，因为其预检查并不总是捕获格式错误的输入，包括意外的空格。这种资格比保证交付的广泛承诺更重要。将产品状态记录为一次观察，而不是每个消息路由的结论。 Spotler Mail+ 设置说明
发布所有者应要求获得授权的公共DNS观察以及预期域和帐户的实际接收消息身份。证据表应区分可见的作者、信封身份、签名域、选择器、接收者身份验证结果和观察时间。配置屏幕无法确定其他服务器对特定消息的评估内容。身份验证也不能证明内容安全或收件人会将其放入收件箱。 RFC 9989 ，范围和接收器操作
虚构诊断：一个域名，两个账户
虚构组织 Juniper Arts 对不同的团队使用两个 Mail+ 帐户。一个团队看到一个活动域并告诉另一个团队复制其指令，而不协调帐户所有权。审阅者注意到第二个帐户从未包含在设置决策中。这是一个发明的规划场景，而不是观察到的事件或执行的测试。
审核者遵循记录的跨账户支持边界，保留当前有效配置并在请求任何更改之前收集两个账户上下文。每个团队仍需要其实际消息路由的证据。教训不是第二个帐户一定需要重复的DNS记录；而是第二个帐户必须需要重复的 DNS 记录。问题是共享域需要明确的支持帐户关系。
空白验收工作表
- 准确的 Spotler 产品和帐户标识符：______
- 回复地址先决条件已确认：______
- 向企业主发送和回复域名：______
- 共享域的其他 Mail+ 帐户：______
- 初始产品状态和时间戳：______
- 账户特定指令集和密钥格式：______
- DNS批准者、完整记录所有者和值：______
- 现有SPF和DMARC协调：______
- 批准的报告接收人和处理目的：______
- 最终产品状态和输入格式审核：______
- 实际收到的消息身份证明：______
- 回滚、主题审查和发布批准：______
所有操作领域仍未解决。原始目录证据、人工审查、来源适用性、生产路线、视觉可访问性和所有者发布大门仍然开放。未执行支持请求、身份验证请求、 DNS编辑或消息测试。