确定当前 SendPro 域模型的范围
本指南使用当前 Spotler SendPro 帮助中心工作流程来处理与 SendPro 和 Flowmailer 关联的商品。它并不假设每个旧的界面、集成或帐户都公开相同的控件。在准备更改之前记录帐户、版本、源应用程序和发件人域。
域指南区分了三个身份：与作者地址关联的发件人域、 返回路径 用于退回处理的域和用于点击跟踪的 Web 域。源应用程序通常确定发送者，而专用流程步骤可以更改它。因此，配置审查必须包括处理流程，而不是假设原始应用程序的发件人地址保持不变。
本稿件未访问或更改任何帐户、API 凭证、流程或DNS设置。其实施和当前适用性要求仍然开放。 域名
复制记录之前选择返回路径和跟踪布局
提供商描述了一种标准设置，其中 Web 域最初使用与返回路径域相同的名称。它还支持将它们分开。分域场景下，指南要求使用MX和 SPF 在返回路径域和一个单独的 CNAME 对于网络域。收件箱域源引入了另一个接收邮件依赖性。
这些替代方案解释了为什么三个别名的屏幕截图不是通用记录列表。获取所选布局的生成计划并记录每个所有者名称的用途。不要仅仅为了重现示例而配置收件箱域，并且当某个名称已服务于另一个系统时，不要覆盖现有的邮件路由。
该指南规定了其返回路径配置的严格对齐约束。将其视为特定于提供商的设计条件，需要根据帐户的实际政策进行澄清。不要将其概括为这样的断言： DMARC 协议总是禁止严格的 结盟 或者默默地从共享域中删除严格的标签。 返回路径域；不同的设置
区分验证和保存
域指南对预览和提交更改进行了重要区分。验证检查当前输入值，并可以显示编辑值所需的记录，而不保存这些编辑。保存更改配置的域值并更新所需的记录和状态。
建议的操作流程是在批准保存的更改之前准备和审查布局。记录屏幕截图是反映预览还是提交的配置。显示预期记录的预览并不能确定该帐户当前正在使用它们。同样，保存的更改并不证明DNS已更新。
该提供商警告说，生产域的更改可能会影响传入和传出的电子邮件。保留之前的状态，识别活动源和流，并同意回滚所有者。域删除还会产生生命周期后果，应与常规状态检查分开进行审查。本手稿不执行任何这些操作。 编辑、保存、验证和删除域
准确读取必要记录和DMARC指标
合规性指南将用户引导至“设置”>“域”。对于其图示的标准布局，它描述了三种 CNAME：一种用于退回处理和跟踪，两种用于 DKIM。使用当前帐户生成的记录，而不是假设这些精确计数涵盖了每个替代布局。
该指南需要有效的 DMARC记录 用于发送，但将缺少有效策略与 rua 不包含 SendPro 报告地址的警告区分开来。它表示后者就足够了，同时建议报告集成。不要将共享报告的建议视为添加新数据收件人的自动许可。保留现有的报告安排，除非域所有者批准更改。
建议的DMARC记录是一个策略示例，而不是组织当前配置的强制替换。在接受之前查看适用的域策略和对齐要求。批准发布后重新检查具体发件人域名；一个成功的域不会建立所有其他域或子域。 发件人域合规性指南
将SPF和源提交与域身份分开
设置指南描述了用于手动检查和可见性的可选SPF项目，名称include:spf.flowmailer.net.该接口描述不得被解释为允许忽略不同返回路径布局所需的SPF策略。首先映射相关身份和生成的记录。
SPF的评估限制涉及依赖于 DNS 的术语，包括嵌套处理，而不是简单地计算输入到可见记录中的包含内容。查看受影响所有者名称的一份完整政策并保留其他合法来源。不要添加第二个SPF策略来满足独立的仪表板项目。
SendPro 还支持通过 API 和SMTP等选项提交源代码。来源凭据授权提交；它们本身并不证明最终消息的域对齐。本指南不会创建或公开这些凭据。提议的接受必须连接所选的来源、任何发件人更改流程步骤以及最终观察到的作者和签名身份。 设置指南; RFC 7208 ，第 3.2 节; RFC 7208 ，第 4.6.4 节; RFC 9989 ，第 4.4 节
应用程序和DNS所有者的验收工作表
使用这个最初建议的工作表可以防止预览状态、提交授权和消息身份验证混淆。
- 申请范围：账号、版本、申请来源、提交协议及相关流程步骤。
- 身份布局：发送域、返回路径域和Web域分别记录。
- 预览证据：生成的记录计划以及它是否反映未保存的输入或已提交的设置。
- DNS审核：每个别名、 TXT或 MX记录、现有依赖项和批准的变更所有者。
- 政策决策：适用的DMARC调整、 SPF审查和单独授权的报告接收者。
- 产品状态：实际的每个域验证结果和批准发布后的时间戳。
- 消息接受：最小化授权样本，显示作者、信封和签名身份以及可信接收者结果。
- 生命周期：未使用域的活动源依赖项、回滚计划和停用批准。
这是空白对照设计。它不是完整的 API 集成、 DNS检查、保存的配置更改或测试传输。
虚构诊断：预览被误认为是部署
虚构的应用程序团队编辑其返回路径和 Web 域字段，选择“验证”并将结果记录列表转发给审阅者。另一个团队假设预览代表帐户的实时配置并标记迁移完成。保存的设置仍然描述以前的布局。
提议的更正是将预览证据与已批准的已提交变更区分开来。在安排任何部署之前，团队会协调实际保存的配置、 DNS计划和相关应用程序流程。他们还保留当前的DMARC报告收件人，而不是复制示例中的每个字段。
经过适当授权的更改后，仍然需要消息级证据。预览本身并不能证明身份验证或交付。这个虚构的示例没有描述任何执行的 SendPro 操作，并且没有对真实帐户做出任何指控。