确认报价产品及寄件路线
本指南适用于quotientapp.com上的 Quotient 报价应用程序及其客户报价电子邮件。它不描述具有相同名称的不相关产品。在进行更改之前，记录企业帐户、报价工作流程、预期发件人地址、团队成员和DNS所有者。帐户自身的配置是必须发布的记录的权限。
Quotient 支持通过电子邮件的自定义域从自有域电子邮件地址发送。其当前的帮助路径是“帐户设置”、“电子邮件”、“电子邮件的自定义域”。该服务提供DNS指令。已记录的 SPF MX条目使用单独的子域，例如quotient-mail.yourdomain.com ，并且MX支持退回邮件和投诉处理。不替换现有邮箱 MX记录. 商自定义域帮助
示例子域并不是粘贴到每个客户的DNS中的字面值。复制帐户中显示的实际所有者和目标。在更改之前，解释哪些客户电子邮件应携带自有域以及哪些路由在此范围之外。报价电子邮件、员工邮箱消息和不相关的营销活动可以在使用不同的身份验证系统时共享可见的品牌。
Quotient 的 2021 年公告还描述了默认提供商域发送者和 CNAME用于自定义域身份验证的 、 TXT和MX记录。使用该公告作为历史产品背景，而不是作为当前定价或菜单保证；当前的帮助页面和真实账户应确定设置。 商自定义域公告
收集当前记录集而不更改接收邮件
打开帐户当前的电子邮件自定义域说明并捕获每个已发布的记录类型、所有者以及公共值或目标。指定可以编辑权威区域的管理员。注册商的计费页面或旧的托管面板并不能证明DNS的服务位置。
编辑前导出现有记录。标记每个提议的条目是新的、修改的还是与现有服务冲突。检查生成的子域是否已存在。 一个记录 在产品说明中可能是“新的”，但在客户环境中已经被占用。解决与受影响的服务所有者的冲突，而不是覆盖它。
使邮箱域的MX记录与专用退回处理子域区分开来。在改签单上写上两个名字，而不仅仅是“ MX ”。操作员应该能够解释哪些记录影响员工邮件以及哪些属于报价传递。如果说明似乎需要更改主邮箱MX ，请停止并澄清当前租户配置，然后再继续。
发布后，在活动的权威服务和独立的解析器中查询每个完整的所有者名称。检查DNS编辑器是否未复制区域后缀。检查委托的公钥记录时遵循CNAME目标，并保留确切的目标而不是用猜测的密钥替换它。记录 TTL 和收集时间，以便以后的测试可以与发布的状态进行比较。
检查已停用的SPF包含作为迁移
Quotient 的专用旧版 SPF 文章表示不再需要include:_spf.quotientapp.com并将用户指向电子邮件的自定义域。它建议不要删除其他服务所需的授权。这是明确的第一方停用通知，因此全新部署不应将旧包含恢复为当前配置。 商传统SPF通知
对于现有域，将删除视为经过审核的迁移步骤，而不是自动清理。首先记录现有的SPF策略，识别任何已批准的遗留依赖性，并获取当前使用的报价发送路由的确认。在安排删除之前验证新的自定义域记录和代表收到的消息。如果客户特定的依赖关系未解决，请将问题保留在变更单中，并要求提供商将其与停用通知进行核对。
当删除获得批准后，仅从适用的单一SPF策略中删除过时的机制。保留不相关的授权和其余预期策略。重新检查完整的结果，而不是孤立地判断编辑过的片段。回滚记录应包含确切的先前值、所有者、时间和负责的操作员。
SPF允许所有者执行一项策略，并对依赖于 DNS 的评估施加限制。添加第二条记录或不断增长的历史包含列表并不是安全的迁移策略。评估的身份是邮件的SMTP身份，因此区分主要 组织域 在评估实际使用的策略时，来自专用信封子域。 SPF RFC 7208
确认发件人地址和真实报价消息
Quotient 指出，域身份验证后可能还需要电子邮件地址验证。记录哪些团队成员的地址已确认以及实际为受控报价选择了哪个地址。域DNS更改不会自动建立对每个邮箱的控制。 商自定义域帮助
通过真实报价工作流程将无害的测试内容发送给批准的收件人。如果企业使用后续或其他客户电子邮件路径，请将它们包含在单独的测试行中，而不是假设它们继承成功的初始发送。捕获发送的发件人地址、回复地址、信封域、 DKIM 签名域和选择器，以及接收者的可信身份验证结果。
DKIM使用签名的签名域并且 选择器 找到公钥。 DMARC 需要相对于可见的发件人域传递对齐的SPF或DKIM机制。提供商签名的消息可以传递DKIM而无需证明组织的自定义发件人身份是否一致。检查实际域并 结盟 设置。 DKIM RFC 6376 DMARC RFC 9989
将身份验证结果与商业交付结果分开。邮件可以通过身份验证，但仍然会遇到收件人规则、信誉不佳或无效地址。成功的测试也并不能证明过去的每个报价或预定的后续行动都使用了新路线。记录配置切换时间并保留该时间点之后的代表性证据。
商数验收工作表
使用此建议的工作表来处理当前的报价-电子邮件路径。未观察到任何客户配置。
- 产品和帐户： quotientapp.com帐户、授权管理员、团队成员、工作流程和所需的发件人身份。
- 域设置：实时功能可用性、生成的记录集、当前验证状态和发件人地址确认。
- DNS分离：主邮箱MX所有者和值、生成的退回子域、其SPF和MX记录以及任何委托签名记录。
- 公开检查：所有者完整姓名、实际答案或CNAME链、权威 名称服务器、TTL、时间戳和记录冲突。
- 遗留审查：退休人员的存在，包括批准的依赖评估、提供者澄清（如果需要）、移除批准和保留的先前政策。
- 消息测试：引用或后续、接收者、时间戳、发件人、信封、 DKIM域和选择器、可信结果和对齐机制。
- 决策：未经测试的路由、回滚触发器、 DNS运营商、企业主以及剩余的人工批准。
不安全MX变更的虚构诊断
这个例子是虚构的。企业希望报价来自自己的领域。操作员看到MX指令并准备替换域的现有邮箱MX记录。变更审核者注意到该指令属于用于退回处理的生成的子域。
建议的更正是在其确切的发布所有者处发布记录，同时保留员工邮件路由。然后，团队验证自定义域并发送受控报价。在清查期间发现了旧的商数SPF包含，但在检查现有路由和批准的依赖关系后单独计划将其删除。这种情况说明了两种不同的风险；它不是已执行的迁移或对真实账户的保证。
证据和释放门
当前的帮助页面支持自定义域工作流程和停用通知。它们不提供实际客户生成的选择器、目标或签名行为。这些仍然是特定于租户的证据要求。当前功能可用性和任何商业承诺必须在激活之前在帐户中确认。实时DNS 、收到的标头、旧版依赖性审查、视觉审查、SME 人工批准和发布批准仍待处理。
将两个DNS决策分开
使用单独的批准行来添加生成的退回子域记录并停用历史根策略包含。第一个决定需要对确切生成的所有者进行碰撞检查。第二个需要现有的发件人库存和回收价值。一份成功的报价无法建立所有计划的后续身份或授权不相关的SPF删除。
将消息接受与策略推出分开
通过对齐的SPF结果可以满足邮件评估的要求，但并不能单独证明将整个域移至拒绝。 RFC 9989 第 7.4 节要求有效的DKIM进行域发布 p=reject 并警告间接邮件互操作性。在策略所有者批准执行之前，清点所有合法发件人和间接路由。本文未执行任何DNS更改、租户操作或接收消息测试。