区分系统邮件和营销邮件
Spektrix 的系统电子邮件身份验证文档涵盖了操作消息，例如订单确认、在家打印门票、密码重置和会员通知。它将这些电子邮件与 Dotdigital 处理的营销电子邮件区分开来。因此，经过身份验证的营销域不足以证明系统通知使用预期身份。
清点 Spektrix 系统、消息类别、预期发送者和负责团队。仅在实际范围内包含预定报告或列表；不要假设组织已启用所有可能的功能。客户支持和票房团队应就哪些可见地址收件人将看到以及哪个邮箱将收到回复达成一致。
该文档支持配置计划，而不是租户已配置的断言。本稿件不执行任何支持通信、 DNS查询、记录更改或测试发送。最初的实施和帐户适用性要求仍然开放。 系统邮箱认证
特意选择专用发送子域
Spektrix 指示客户端使用系统邮件的子域并将相关配置放置在那里，而不是放置在根目录中。它还建议不要使用与 Spektrix 自定义域 Web 集成相同的子域。记录所选边界并检查该名称是否已用于其他目的。
专用子域可以帮助分离操作依赖性，但这并不能保证声誉或安全影响永远不会影响到更广泛的组织。实际好处是所有权更清晰，并减少与根域基础设施的重叠。保留这种区别而不是承诺完全隔离。
在提议记录之前，确定现有的权威区域、当前MX使用以及继承的或显式的 DMARC 政策。在电子表格中显示为未使用的名称可能仍支持某项服务。不要仅仅为了方便的示例而替换生产网站或邮箱记录。与授权域所有者和 Spektrix 记录的支持工作流程确认预期的子域。 发送子域
将SPF 、 DKIM和MX作为不同的依赖项进行审查
系统电子邮件指南名称 SPF, DKIM 和 MX记录 对于选定的发送子域。其SPF示例包括mailgun.org 。如果该名称已存在SPF策略，请检查一个完整的策略，而不是添加第二条记录或将整个示例粘贴到现有值内。保留合法来源并审查依赖于 DNS 的评估限制。
DKIM是支持辅助的：指南要求客户通过 Spektrix 支持确认发送域，这有助于生成域密钥。它描述了 2048 位 键。保留实际发布的密钥名称和公开值；不发明 选择器 或重复使用其他组织的密钥。
MX记录涉及邮件路由，而不是替代 DKIM签名。该指南为英国/爱尔兰/加拿大和美国客户提供了不同的Mailgun MX目的地。使用提供商确认的帐户区域和完整说明，包括未通过复制摘录确定的任何值。切勿仅仅因为系统邮件子域需要MX配置而更改根域的现有邮件服务。 设置SPF 、 DKIM和MX记录; RFC 7208 ，第 3.2 节; RFC 7208 ，第 4.6.4 节
将日志记录和回复路由与身份验证分开
该指南描述了可选的电子邮件日志依赖项，使用发送子域下方的电子邮件标签和适合区域的 CNAME。它表示客户不会直接访问生成的日志记录，它有助于支持调查交付。这与DKIM密钥或收件人阅读邮件的证据不同。
在启用跟踪或记录功能之前，请根据组织的隐私和通信要求审查这些功能。本稿件不创建跟踪记录或收集收件人交互数据。提出的证据包可以识别该功能是否在范围内，而无需假设打开或点击能够可靠地衡量人类注意力。
该提供商还描述了当发送地址没有受监控的邮箱时通过支持设置回复地址。与票房团队一起审查该目的地。成功到达的回复证明了工作流程结果，而不是 结盟 原始通知的内容。 电子邮件记录；回复地址
保留父域DMARC意图
Spektrix 警告说，基本子域 DMARC记录 可能与组织现有的父域配置冲突。将任何提供的监控策略视为提议的策略决策，而不是无害的验证令牌。发布显式子域策略可能会更改适用的策略关系，因此域所有者必须在批准之前对其进行审核。
使用当前的DMARC语义，而不是宽泛的声明，即身份验证始终确保交付或策略值决定每个收件人的结果。 DMARC评估与传递的身份验证身份的一致性，而接收者保留自己的处理策略。不能仅仅因为邮件继续离开应用程序就假定后备发送域对不相关的作者域进行身份验证。
提议的最终检查是授权代表系统消息及其作者域、签名身份、选择器、相关信封身份和可信接收者结果。将营销信息证据分开。请勿降低策略来隐藏未解析的系统路由，或声称绿色DNS检查证明客户收到了票证。 DMARC ；冲突；后备域; RFC 9989 ，第 4.4 节; RFC 9989 ，第 5.3 节
票房和 IT 团队的验收工作表
使用这个最初提议的工作表来协调操作邮件，而不用假设代替证据。
- 消息范围：系统标识符、操作类别和单独的 Dotdigital 营销职责。
- 发送边界：批准的子域、现有DNS使用以及与自定义 Web 集成的区别。
- 提供商请求：支持确认的区域、发布的DKIM密钥详细信息和完整的记录说明。
- 政策审查：单一一致的SPF政策、明确或继承的DMARC意图以及域所有者的批准。
- 邮件路由：子域MX配置并确认根域邮箱服务不受影响。
- 可选功能：记录或跟踪决策、隐私所有者和受监控的回复目的地。
- 接受：提供者状态（如果可用）、授权的接收消息身份和可信的身份验证结果。
- 连续性：回滚所有者、计划消息依赖性和未解决的生产发布问题。
工作表是空白的。它不记录实际的客户地址、门票购买、私钥、 DNS更改或支持操作。
虚构诊断：营销域名被误认为是系统邮件
一家虚构的剧院发起了一项经过身份验证的 Dotdigital 活动，并假设其门票确认采用相同的设置。稍后的系统消息示例显示了不同的发送路径。票房团队建议更改根域的MX记录，因为系统邮件指南提到了MX 。
拟议的审查会阻止该不相关的变更。它将营销和运营路线分开，识别专用的系统邮件子域，并要求正确的帐户区域说明和支持颁发的密钥。现有的公司邮箱基础结构将被保留，同时审查新的依赖项集。
在接受建议的子域记录之前，剧院还会检查父域策略。在存在适当的操作证据之前，不能声称成功。此场景是虚构的，并不描述实际的 Spektrix 事件、客户消息或执行的测试。