编辑DNS之前选择发件人身份
Quentn 提供两种不同的发件人选择：组织控制的域中的地址，或使用 Quentn 域的地址。本指南涵盖了组织拥有的域的验证，并解释了提供商域路由的不同之处。在写入DNS更改之前，决定活动应使用哪个可见的身份。访问公共电子邮件服务中的个人邮箱并不提供对该服务域的权限。
在记录的发件人工作流程中，打开“电子邮件”，然后打开“发件人”，然后添加发件人电子邮件。默认类型适用于拥有的域；保存会发送一封地址确认电子邮件。相反，Quentn 域类型提供提供商域地址并请求必须确认的转发目的地。这些是不同的路线，而不是公共邮箱提供商发布记录的两种方式。 Quentn 发送器设置
记录所选地址、发件人类型、活动所有者和回复目的地。更改默认值可能会影响人们在未来的活动中选择的身份，因此请检查已经准备好的活动，而不是假设每个草稿都会自动匹配新的意图。在验收计划中保留受控回复测试。身份验证成功并不表明受访者的回复已到达预期的团队。
将地址确认和域验证分开
发件人确认建立了对收件箱的控制。域验证是一项单独的DNS任务。 Quentn 的验证指南将用户引导至电子邮件、已验证的域，然后是创建域。创建域名后，打开其验证信息，将显示的DNS条目发布到域名托管服务商处，并查看结果验证指示。使用往来账户的发行记录；该指南并未为每种安装提供一套通用值。 Quentn 域名验证
DNS所有者应首先确认哪个 名称服务器 是权威的。旧托管帐户中可见的区域可能不再提供公共答案。对于每个生成的指令，捕获记录类型、完整所有者名称、目标或公共值以及该所有者的现有值。阅读DNS编辑器的相对名称约定，以便它不会两次附加域。
不要推断一个 TXT记录 或者 选择器 从屏幕截图文件名。如果租户发出 CNAME，保留其目标并检查是否没有不兼容的记录已占用相同的所有者。如果它发布TXT记录，请保留完整的公共价值。升级所有者名称冲突而不是删除现有服务的记录以使验证通过。在批准更换之前，变更票应识别受影响的服务和所有者。
Quentn 的指南称域验证是可选的。该措辞不应被翻译为承诺未经验证的组织拥有的发件人地址满足收件人当前的身份验证要求。将其视为对记录的产品工作流程的描述，并且仍然需要用于预期身份的消息证据。 Quentn 域名验证
根据真实的发送库存构建SPF
Quentn 的身份验证介绍告诉客户在更改域策略之前要考虑其他系统，包括会员资格和网站邮件。它还显示了一个 SPF 例子和 DMARC 例子。这些示例不能替代租户发布的配置和组织的实际邮件库存。 Quentn认证介绍
列出常规邮箱服务、Quentn 活动、网站提交、密码重置、计费邮件以及同一发件人域的任何其他已知使用。对于每个，确定其真实的SMTP路由。网站的公开 一个记录 不能证明该网站直接从该地址发送电子邮件。它可以通过不同的提供商提交。在不检查路由的情况下授权网站地址可能会添加不必要的权限，同时使实际的邮件路径不固定。
SPF属于接收服务器评估的SMTP身份。在给定所有者维护一项SPF策略，仅合并所需的授权，并评估 DNS查找限制 更改后。不要在现有记录旁边创建第二个v=spf1记录。不要假设提供商控制的信封域的SPF通行证与可见组织拥有的发件人域一致。 SPF RFC 7208
记录添加的内容、保留的内容以及原因。如果提供商发布的SPF指令不清楚或与公开示例不同，请在发布之前获取该帐户的说明。该草案没有规定通用 Quentn 包含主机名。
在实际营销活动中验证DKIM和DMARC
使用代表生产活动路线的小型受控测试。从接收者的可信身份验证评估中，捕获发件人域、信封域、 DKIM 签名域、选择器和结果。这 DKIM签名'sd= 和 s= 值标识公钥查找；猜测选择器的一般DNS扫描并不能提供足够的证据。 DKIM RFC 6376
对于DMARC ，确定哪个传递机制与可见的 From 域一致，以及哪个传递机制与可见的 From 域一致 结盟 模式适用。通过对齐的SPF结果或通过对齐的DKIM签名可以满足DMARC 。仅存在三种类型的DNS记录并不能确定特定消息已通过身份验证。必须使用实际域来检查严格对齐，而不是假设每个子域都是等效的。 DMARC RFC 9989
调查时保留现有DMARC策略，除非授权域所有者批准更改。监控策略和执行策略服务于不同的目的。不要粘贴示例 p=reject 在验证其合法路由之前，将策略引入共享组织域。报告目的地还需要所有者、访问控制以及对他们可能收到的数据的适当审查。
使用组织批准的DNS工作访问流程。管理员可以发布公共记录，而无需通过电子邮件将域名托管服务商密码或会话令牌发送给任何人。对支持票证、屏幕截图和文章证据保密。提供商支持对话应从安全记录名称、公共值、相关时间戳和确切错误开始。
昆顿验收工作表
以下是建议的工作表，未完成的客户证据。为所属域和 Quentn 域发送保留单独的条目。
- 身份选择：发件人类型、可见地址、活动、企业所有者、回复目的地以及默认选择是否更改。
- 地址控制：确认收件人、完成状态、回复测试结果，不存储确认链接。
- 域控制：输入的域、权威DNS所有者、当前租户指令和验证状态。
- 公共DNS ：每个生成的所有者、类型、值或目标、先前状态、TTL、查询时间和观察到的答案。
- 其他发件人：邮箱、网站、会员资格、交易以及使用域的剩余路由。
- 收到的活动：安全测试标识符、接收者、时间戳、发件人、信封域、 DKIM d= 和s=,以及可信身份验证结果。
- 验收：一致的机制、未经测试的路线、支持问题、回滚所有者和人工批准状态。
对已确认但未经身份验证的邮件进行虚构诊断
这个例子是虚构的。活动所有者确认新的发件人收件箱并看到 Quentn 中可用的地址。测试到达收件人时， DMARC结果失败。团队最初假设确认电子邮件已完成身份验证。
调查将地址确认与域验证分开。 DNS管理员发现记录已添加到非活动托管区域，而权威区域仍然缺少所需的公共配置。建议的修复是在活动主机上发布当前帐户的发行值，检查 Quentn 的验证状态，并重复相同的活动测试。还会重复回复测试，因为正确的发件人身份不会验证回复路由。此场景记录的是诊断方法，而不是观察到的事件。
范围保留和审查门
未检查任何实时 Quentn 帐户、已发布的DNS集、客户区域或收到的活动。确切的记录类型、目标、选择器值和签名行为仍然是特定于帐户的证据要求。候选人故意避免通用SPF包含，并且不采用来自源的不安全的凭证共享指令。人类 SME 审查、视觉阅读器审查、实时身份验证测试和出版批准仍在等待中。
标记虚构案例中的未知数
在虚构的非活动区域情况下，活动DMARC失败是假设的输入。确切的SPF和DKIM结果、签名选择器和租户发布的记录故意未指定。不要将该场景转变为特定 Quentn 选择器失败的声明。下一个证据是由授权所有者收集的当前发布的记录集、权威响应和新的接收结果。
将消息接受与策略推出分开
通过对齐的SPF结果可以满足邮件评估的要求，但并不能单独证明将整个域移至拒绝。 RFC 9989第 7.4 节要求发布p=reject域具有有效的DKIM ，并警告间接邮件互操作性。在策略所有者批准执行之前，清点所有合法发件人和间接路由。本文未执行任何DNS更改、租户操作或接收消息测试。